Machinis Ludo Game Jam Weekend

I took part in the very friendly Machinis Ludo II Game Jam over the weekend and it was an opportunity to use the stuff I have been working on for GameDev-UK.net. I thought some of you might be interested in the process and outcome. It was certainly a valuable experience for me - I added some new things to the library (primarily physics related game components), modified a few existing components and realised that I probably need to give some of the libraries structure a big re-think.


My game idea was basically an old-school first-person shooter using physical, relatively slow moving, bouncing, projectiles. The emphasis is on careful shots and judging the trajectory of both the 'grenade' and target. It was intended to be a cross between Atari's Battlezone, Quake's grenade launcher and 3D Tanx on the speccy - see my full plan here.


So firstly I used my Visual Studio 2010 game wizard to create the intial project. This worked perfectly but I decided to also add my local copies of the gamelib, G3D and GLS3D projects to the solution as well to make browsing around the primary codebase easier (I'm still learning how bits of G3D work). At this point I SVN'd everything locally so that I could regularly check-in at functional milestones and give myself the ability to roll-back to these if I went 'off on one'. As I'll mention again later, this saved me at least once later in the jam.


The first session of the jam was spent testing the principles of rendering under the control of Bullet physics game components. Particularly valuable was a bullet debug drawer component that allowed Bullet to draw its own collision geometry fairly directly - this enabled me to verify that my own G3D rendered geometry was indeed correctly synchronised with Bullet.

Next I needed to be able to launch my grenade projectiles out into the scene. For this I also needed to write a camera (and launcher) control that had pitch and elevation. I added both an XBox and keyboard 'translator' so either could be used for input, but basically these components came straight out of the existing game lib.

A major technical hurdle I always knew I would have to resolve was how I would 'hook' Bullet's collisions for my own game-specific behaviour. As predicted, this turned out to be tricky mostly because I couldn't (and to some extent still haven't) settled on the "neatest" way to do this within my game component framework. It seemed that the most consistent pattern for my lib is that the game components should receive and handle their own collisions (rather than have an independent collision pair resolver).

 

I spent several hours setting up an event system where any game component could subscribe to the collision of any other game component (I used boost::Signals2 for this) but this was, of course, only half the problem. As well as *when* an object has collided, I also need to know *what* it has hit! Initially I started making object ID's, but quickly reverted from that and instead created an ICollidable base class interface and I just used dynamic_cast<> to identify the actual object type. Definitely not performance-optimal, but pragmatic and conceptually easy to implement - important when you start to get over-tired and grumpy ;)

So the next step was to turn all these technically interesting bits and bobs into something that could vaguely qualify as a game. I moved the grenade and enemy components under a grenade launcher and enemy manager game component collection class, respectively, and created a std::vector of each. Although not great from a conceptual perspective, the enemy manager turned out to the be the component that had most direct access to most of the game specific states and dependencies - wave number, remaining enemies and score control - so I wired this up to some text renderer components (already in the lib).

Final bit actually involved the most swearing. I just needed to replace the primitive drawable components with model drawables and (and this is the rub) create a couple of simple textured models to load into them. Easy eh?


Previously I have used XSI Mod Tool from Autodesk (formally a modders version of softimage) but I have seen for some time that like XNA this is sadly a dead-end product. In addition, it only exports fbx files. Currently we don't have an importer for fbx but I have got Autodesk's fbx converter, which *should* allow me to convert my models to collada (which I can load through assimp) or obj (which is supported directly inside G3D). Unfortunately, try as I might, Autodesk's fbx converter has failed with *every* model that I have put through it - seriously, it's total bobbins. So, enter my saviour - Blender 2.6! Er... well no, that turned out to be brutal too.

 

Suffice it to say that I might need to invest some python time in the obj exporter at some point as everything I produced needed hand-editing in Notepad++ before it was actually compliant... So, I simply ran out of time at this point and the 'final' version is still disappointingly wireframe in important areas:

So, obviously lots to do. Most important is that my Bullet collision hook is currently very unreliable and misses a lot of clear collisions. I will definitely work in this. I *may* try and do a bit more on Cannonade. I always intended to create a radar, some physics-based geometric scenery, particle trails on the grenades and, of course, explosions. but I think that whilst it has been a useful learning experience, I'll probably get back onto Buccaneer again for a while...

You are here: Home C++ OpenGL Projects & Demos