Realigning the Azimuth

Whilst I’m continuing to hunt contract work down – I’ve also been looking into some more of my own projects to hack on (to both kill time, and to potentially sell). One of those is a basic game prototype based on some ideas I’ve had lying around.

The basic idea is that you’re controlling a fighter (the blue block) and need to defend the giant spaceship (the white block) from the approaching enemies (the red blocks – yes there are multiple!).

I’m putting this out there mainly as a way to solicit some feedback from across the interwebs. I’m not the most original game designer out there, and I’m hoping by doing this, I can get some feedback on both whether this is viable (in particular for the iPhone, but even as a web game or something), and on where I could go with it – I have some of my own ideas, but I’m interested in what others have to say.

So, if you’re interested, download it – either for Windows or for Mac OS X.

A few months ago, I wrote a post on how I’d run into a bit of a dilemma in terms of what I wanted to do my indie games development with. I’d done a fair chunk with Microsoft’s XNA stack, but after losing my Windows box (a gaming laptop which had a video-hardware burnout), I needed to pick a new set of tools to work with.

Besides being cross-platform, I’m also after something which would allow me to get a prototype game up and running incredibly quickly. My first target was GarageGames’ Torque Game Builder (or TGB) – their 2D focused engine. My interest was peaked for two reasons in particular – the first being that it’s a GUI based tool, which helps reduce the amount of code necessary to get a small game up and running.

The second reason was a short course which covered using it for iPhone games development. Overall, the course was great – it helped plug in some of the larger holes one has when starting out (as reflected in some of the points I make later on), and after completing, I certainly learned a great deal and have a lot of fun building my prototype game – for which there’s some footage here. If its re-run next year, and you’ve got interest in that area, I’d recommend looking into it :)

The model TGB uses is a GUI editor which allows you to add objects (players, enemies, pick-ups or UI elements) onto a Scene (or Level), and do a significant amount of configuration by editing properties from the editor.

If you require more complex behaviour upon your entities (and you likely will), then you delve down into writing scripts with TorqueScript, a C-like scripting language which is processed at runtime

Sounds like a good combination? If you’re not from a coding background, then certainly. TorqueScript isn’t a big pain to deal with, and the model they’ve employed with the scripting means you don’t need to be a low-level coder to succeed. On the flip-side, if you have that low-level experience, you might feel incredibly restrained by what the scripting offers. Though I’m not an expert at game engine design, and of rather average competency as a developer, I admit there were times I felt limited by the scripting facilities, but wasn’t up to the level where I could work with the raw C++ code (which is available when buying the full engine) to improve things for myself.

I guess I’m wanting a bit more control on building a production game – I have some frustrations with the event/callback model which TGB relies upon. I find that the model makes it difficult to logically structure your code – in particular, due to how objects are added to the editor, you can’t setup a chain of prerequisites. If, at any stage you want to take advantage of publishing beyond the desktop environments, you need to be prepared to junk a lot of existing code for the sake of performance.

Which for me, is enough for me to question using it for a production project. As a prototyping tool, I’m totally sold (unless I want to make a 3D game) – TGB is an incredibly fast way to get something up for when I want to experiment with ideas, but for a more complex project, it’s not quite the way I want to work.