Today was the first day of tsumea in a week or two if you’re interested in the content. I’ll mainly be posting my reactions, given the notes I took are barely indecipherable.

Overall I enjoyed the day. I probably didn’t speak to as many people as I should have; my shy nature means I’m not a natural networker, doubly so when I haven’t had much coffee and it’s been a long day. And I probably didn’t learn anything groundbreakingly new. But for methe day did help do what I hope it would, which is to fire my brain up again about game development and remind me what I should be doing. It’s given me a few pointers on how to tweak my work approach that I suspect will be more likely to result in good games.

The sessions I saw:

The New iKid on the Block: A discussion panel on the practicality of developing on the iPhone. I’m starting to lean more towards the iPhone, although alongside other desktop games. Basically, the advice was to develop to the specific iPhone strengths (touch screen, accelerometers, connectivity, camera, maybe the compass?) and try not to directly compete with the big boys now coming into the market.

Agile Development: I think the speaker was a late fill-in, so this workshop was a bit freeform. I’m most likely not going to be working on a large team in my projects (and if so, probably not in the same building), so I’m not sure if any formal processes, even ones as freeform as agile development, are strictly needed. But still, I liked hearing a wave of software engineering speak. It helped reawaken some long dormant neurons.

Case Study – Imperial League: This wasn’t so much a case study of Imperial League as the whole of Primal Clarity, a group that focuses on the business of Unreal mods. They can win contracts for prototyping ideas in Unreal engine, send in game submissions to government initatives and other interesting ideas.

Weapons of Mass Cosntruction: A talk on procedural generation to make artists lives easier, mostly consisting of videos showing what they can do. Pretty interesting. I’m not sure how useful they’ll be to me if I work in 2D, but it’s nice to know they’re there. It’s an area I’d like to play around with myself.

The art of getting things done: A good pep talk on how to, well, get things done. It did tend to veer more towards team management than solo, but it had useful tidbits like The Cult of Done Manifesto. I’ll read through this in more depth on the weekend, as I need to, bluntly, get more stuff done.

International Keynote: Petri Purho (Crayon Physics Deluxe): A really good keynote. If the video goes up at tsumea, I highly recommend watching it, despite how Petri says he’ll play Spelunky throughout the whole talk. Petri explains creativity in games, and how to brainstorm creativty via prototypes (or as he calls it: “making shit in games, and making shit games”).

I spent most of today’s programming inadvertently proving Andrew Russell’s points against C/C++ (see the comments to Don’t bring C to a string fight).

I’m up to porting across the wrapper code I’ve written for SDL and OpenGLs graphics. The code base consists about half-and-half of initialisation/deinitialisation code and a sprite management system. The sprite management system is possibly over-engineered and so I might leave it for now, but the base wrapper code for all that initialisation stuff should in theory be reusable for any app. It’s just the basics for setting up windows, swapping buffers and telling code when it needs to hurry up and render something if it wants it be up on the screen this frame. It’s mostly a mess of cryptic library calls to SDL and OpenGL, but if it works it works.

At least that what I thought so. However the call to the SDL function that sets the video mode just refused to run on my Mac system. It would just crash – not even returning a null value for my error checking to deal with. My gut instinct was that I had to be doing something boneheaded, like forgetting to initialise something obvious, but it seems like I was doing everything I should be doing. I spent hours tracing it through, running it in different release builds (which caught an unrelated but also nasty string bug in the file initialisation code, C really is evil in that regard). It turns out SDL was also throwing a whole bunch of memory leak errors in the console that were either new or I’d missed, as my own output is to an HTML log file. This was weird, because I’d never noticed errors like this before in previous SDL apps.

It turns out my instinct was right, and I had done something stupid. On the Mac, SDL needs to run under an Objective-C wrapper. They helpfully provide you with a sample one, but I’d somehow removed it from the build path. Consequently SDL’s threads were disintegrating spectacularly into a whole raft of error messages. I’d probably missed this kind of problem in my previous little games because I’ve never developed a C based game on one before; I’d written them in Windows first then ported it across.

It’s not a good start to the trial of a C with scripting language game base. Admittedly it’s a very OS specific error. Once I get all the wrapper functions working and tested then I should be dealing mainly with my own code, and at least then I should have a fair idea where the trouble spots may lie. But the thing about unexpected difficulties is they act in unexpected ways. I’m fairly sure there’ll be similar challenges when I’m working in a language like C, and whether the time I lose to solving these problems is worth the fact that I like working and thinking in the language. I’m a bit behind schedule as it is, despite C being my strongest language. My feeling is that I should still slog on with my plan for now, but if I hit an alarming frequency of this kinds of bug stoppers I should start strongly considering a different course involving a higher level language.

Just a heads-up: Freeplay 2009 is on next week in Melbourne, on Friday and Saturday (Aug. 14 – 15). I should be there for both days. Tickets still seem to be available until Thursday, so there’s still time to attend.

I’ve never been to Freeplay before, so I’m not sure what to expect. At a bare minimum I’ll just drift around the panels, soaking in game related thoughts to both learn from and be inspired. But if anyone has any recommendations about what to see, please tell me.

A programmer oriented blog post today:

I’m still tinkering around with the guts of my old system, remembering how it all works. Rewriting the code concerns me a bit that I am technically reinventing the wheel, possibly wasting time. But it’s being invaluable in revising my old coding habits and getting back up to speed. I am worried that I am running a few days over where I’d like to be; I was hoping to have a bare bones functional wrapper for the basics done by the start of August.

The biggest change is I’m moving my code from C++ back to C, partly because I want to move to a scripting language for the bulk of the work, partly because I want to see how it looks. Mostly this isn’t much of a change. There used to be a delegate based signal system for passing events through the system that formed the core of the message loop. The code was elegant on the outside but a nightmare on the inside; it heavily used templates and the types the debugger would throw up were horrendous. For now I’ve replaced it with a simpler message passing system somewhat modelled off the interfaces to SDL (which incidentally I’m still using for cross-platform functionality). My simple unit tests seem to suggest it’s working nicely.

But man, does C suck for anything involving strings. I spent all of yesterday just writing the code for reading in a config file (the original used TinyXML, a C++ library). True, that’s partly because I’m a bit rusty and was making boneheaded design errors. But it’s somewhat understandable when you don’t have the usual C++ string library to work with, or a higher language like Python to handle all the ugliness. The stupid thing is I only wanted a fill-in module to handle the early prototypes, as I want to explore using Lua as scripting language; reading config files is (almost literally) what Lua was made to do.

Still, I did get some really good C practice out of it. And it was good practice with Xcode’s debugger, hunting for pointer errors.

It does make me question a bit whether the decision to roll back to C was wise. It does mean I lose a lot of C++ only libraries – admittedly the ones that come precompiled tend to be a pain to use, as you have to have the right compiler, but the ones you can compile yourself are useful. And I lose out on the standard library – which may or may not be an issue, depending on how much I can farm off to Lua. But on the plus side I find C easier to debug, and there’s less of a push to use clever C++ features just because they’re there. I’m also getting a feel it works better for the message passing design paradigm I’m going for; C++ tends to lean towards using objects for everything, even when they’re not really needed. I do miss namespaces; really useful things, namespaces.

A brief update on what I’ve been up to in the last few weeks:

I’ve been having trouble getting started, what with all the various options transfixing me and being cause for much procrastination, so I spend a bit of time reviewing my plan and getting my priorities straight. I think I was aiming too hard to make things near perfect, which is too hard in my current position, hence cause for anguish and feet dragging. Many people suggest it’s better and quicker to throw something together and then refine it, and I think they’re right – at the least, it gets me over the road block of getting things started.

Another issue is that I’m trying to run a few different projects at once, and I’ve been putting off some hard decisions for all of them. I’m reaching the point where I have to pull the trigger for some of them, and I’ve been putting that off for a bit too long. This is a nice timely reminder to myself that if you have to decide between two reasonable options, both decent but hard to tell which is better, havering indecisively between the two is actually taking the third, worse option. Your choices are actually A) good option B) good, different option and C) do nothing but build up stress between making the wrong choice between A and B. Memo to self: if in that situation, just flip a coin and go with A or B; don’t pick C by default.

Programming-wise, I’ve put Python aside for a while. I don’t know why, but I’m finding it hard to go beyond simple demos. It could just be that I’ve thought of the C family of languages as my game programming language for so long I’ve hard-wired it in there.

Instead, I’m in the process of resurrecting the code I was using for my hobby games a couple of years ago and reworking it into a new framework. I’m keeping the original framework name of “Diagonal”, because I like it, although I’ll give different version names to each iteration (the current one is “Scalene”). My main aim at the moment is to get the framework working while also refresh my memory as to how the system is put together and refreshing my programming skills, all in one swoop. Looking through the code at first glance it isn’t actually that bad.. I guess after several iterations I’d ironed out most of the kinks.

I’m also converting the framework from C++ to C, which is I admit a fairly retrograde action. I’ve never been that comfortable with C++, sticking mainly towards the C side of things in my own code save for a classes and the odd template. In my current framework code, I don’t actually use the C++ features that often. There’s very few classes and I rarely had the need to use the standard library. The bulk of memory management is handled within critical modules which guard it jealously. Really, the biggest thing I lose is namespaces, which is a bit of a bummer but I can live with. In return, I’m hoping to avoid all those pesky annoyances I’ve had working with C++ code, such as easier debugging, profiling and no error messages that go for fifteen pages due to compound templates.

The other justification for a lower level language like C is that I am planning soon to integrate my framework with a scripting language of choice. Admittedly that can be done with C++ and many other languages as well, but I like the contrast between scripting languages and C. Lua and Python are the two choices I’ve flagged, and while I’m stronger in Python I’m leaning towards Lua; I find its simplicity to be appealing, and it’s been designed for embedding. Python is going to be my tool language.

All this said, things are going a bit too slowly for my tastes, and I’m a bit worried. It’s taking me a while to switch from postgraduate algorithm prototyper to game engineer/programmer, remembering some aspects of C, how to use Xcode etc. I do have a few years of my own code to crib off, so I know that what I have should fundamentally work as a starting point. If I don’t have a screenshot of a basic prototype up by the end of the month, then something must have gone seriously wrong.

I apologise for neglecting the blog again. I have been trying to kickstart a few of the activities I need to get running to kick this Trazoi show going, but I don’t think I’ve done a good job on any of them thus far. I’m currently taking a step back, staring at the diagrams pinned to my corkboard, reading informative books and coming up with a new approach for next week. I will try to factor in more blogging into the plan, if only to push myself to get to the point where I’ve got pretty pictures to share.

My absense from blogging over the last fortnight is partly due to me settling a few mental hang-ups from finishing my thesis. The mid-year milestone triggered off a little voice in my head that said “Hey, remember all that cool stuff you were drooling over last year but said you couldn’t get until your disseration was handed in? Well, it’s been three months already. Where’s the presents?” So I decided to open my piggy-bank and go shopping.

I considered getting a new desktop PC, a usual thing I salivate over, but I couldn’t justify the purchase. My iMac is good enough for work. My secondary WinXP machine might be completely outdated and sounds like a sick leaf blower, but it’s good enough for older games and watching the occasional DVD – which is all I really need it for. So instead I split the purchase money and got a netbook for more mobile productivity, plus an Xbox 360 for current-gen console gaming that doesn’t involve waggling a remote.

I’m pretty happy with the netbook. I got a Dell Inspiron Mini 9, as reviews said the model was quite sturdy and it would be easier to service the parts myself if need be. This model also has the neat benefit that it has no moving parts; the hard disk is solid state and as it’s low power there’s no cooling fan. I’ve installed Ubuntu Netbook Remix on it and it works rather well; it’s no powerhouse with an Intel Atom but it does what I need it to do. Currently I’m using the netbook as a digital notepad, taking notes in WikidPad as I read books, and it does that very well. And unlike expensive laptops which always seem so fragile to me, I don’t mind so much if a netbook breaks down in a couple of years because they’re not so expensive.

The Xbox 360 is an Xbox 360 – there’s not much more to say. I’ve used it a little bit and it seems good. I’m a bit miffed that the wireless adapter is an expensive add-on – hey, it came already installed in the Wii and the netbook – but I can rig up a wired connection when I need to go on-line. I’m not big on multiplayer gaming that doesn’t involve all players being within Nerf ball range.

It also twigged that since I now have an internet connection that isn’t completely pants, I can now use services like Steam and Good Old Games – great for both catching up on games I missed on playing the last few years and for researching games in themes I’d like to explore myself. I got Half Life 2: Orange Box, Psychonauts, the X-COM pack and Fallout Tactics – all combined for less than the standard full price shrink-wrapped game. I’m still downloading them a week after ordering them – my connection isn’t great – but it’s nice to experience the buzz that Steam has caused for myself.

The big downside to all these great priced game packages is that 1) I already have a back catalog of games I want to play, and 2) I’m currently finishing a game every two months. It’s going to take me until 2012 to actually play them all. Sigh. Well, a few Game Appreciation evenings a week won’t hurt to help work through my playlist and to eventually figure out why everyone on the internet keeps claiming the cake is a lie.

It took me a while due to my sporadic play schedule, but I finally finished Braid yesterday. I know I am extremely late to the party with Braid, what with me waiting for the Mac port, but as one of the big indie game names it’s something I had to play for a game design focused mini-review.

Braid is a 2D puzzle platformer, a genre where the challenge lies more in figuring out how to solve a problem rather than on twitch reactions (although there’s a bit of that in the game). The main theme of Braid’s puzzles are different variations on time manipulation, such as reversing time, replaying time, slowing time down, or variable time dependent on the movement of the player. The objective of all these puzzles is to collect puzzle pieces, which combine to form material for a rather surreal backstory (more on that later).

The time puzzles were, for the most part, extremely well done. They were at the right amount of difficulty to be rather challenging but not so much so that I felt permanently stuck. The variations on time manipulation were clever and led to great puzzle variations while still being tied to the same overall theme. The ability to reverse time to get out of deaths made many of the twitch puzzles and jumping less about reactions and muscle memory and more of a thought exercise.

There were however a few puzzles that were too frustrating, all of which involved a component that removed the inability to rewind time to reverse the mistake. The classic example would be in the scenarios where time direction depends on horizontal position and you are offered two doors leading to the same puzzle piece with a key that is unaffected by time. If you pick the wrong door, your movement will reverse time back to when the door was closed – and you’ve now lost your hard earned key and have to start allll the way back from the beginning again.

I also liked how the actions and interactions with the game were very clearly shown in the game. As shown in the screenshot (which also shows how pretty Braid is; very nice painterly style to the levels), the early tutorial levels make it very obvious how you are meant to interact with objects in the game. I think this style of tutorial is extremely good and something to learn from.

The main criticism I would have with the game is the story. The story is told mostly through books which display text on the screen, but also through the imagery in the jigsaw puzzles and through events in the last level. But it was all extremely surreal and I never put all the pieces together. Strangely, some of the story text is also a hidden secret that you have to work at to decipher – and even then it’s all still very confusing.

It seems designed that you have to work rather hard to piece together the story in Braid, and I’m not sure if it’s worth the effort. I wouldn’t mind so much if the story was just subtext, something you could happily ignore if you wanted to focus on the puzzles. However the game is called “Braid” – an entirely story related term – and the story elements seem to be treated as extremely important – but not important enough to be clear to the player. Unfortunately the impression I’ve got from Braid’s story was that it was trying too hard to be clever in structure rather than wanting to convey its message to me directly.

Braid is definitely worth picking up, especially if you’re a developer with an interest in puzzle games, platformers or both.

Today I pulled the final plug on my old blog at trazoi.net. It was a gradual process of shutting things down, but it’s now fully archived and shifted to my new server. You can access the archive at the old address, where it looks pretty much exactly like the old Wordpress blog just how I left it. However it’s now an archive in static HTML format; none of the dynamic features like searching or leaving comments will work.

The main features at that site that people who are not me might actually care about, such as the games and the Inkscape tutorial, should still be at the same addresses. Tell me if something looks wrong and I’ll try to fix it if it’s serious. Email to any old addresses may be a little screwy, but no-one seemed to email me at that address anyway. Or maybe they did and I never got it, in which case the change can hardly make it any worse!

I’ve also pulled the plug on my Dreamhost account where the old site was being hosted. Dreamhost was a pretty good hoster for starting out, and overall I liked using their services. But there’s little point paying for extra hosting for an old archive site when I’ve got plenty of space here on my self-administered Linode.

In the same vein as the last post, I’d like to make note of Flash MOD Player v1.2, written in haXe by Kostas Michalopoulos a.k.a. Bad Sector. I have been meaning to make a few retro arcade games in Flash, but the lack of support for a tracker format was bugging me. With a MOD player, this will help provide that old school feel while also keeping downloads small.

I haven’t yet played around much with this MOD player as I’ve put Flash aside for the moment, but I’ll be looking at this closer when I pick it up again. In the meantime, if you work in Flash and are interested in tracker music, this player might be handy.

I just stumbled across this in a link on the IndieGamer forums: sfxr – an old school sound effects generator. It’s perfect for quickly making simple wave form sound effects, and the GUI has some of the most common ones as presets. I’ve played around with the Mac port for a bit and it’s brilliant.