Wednesday, November 14, 2012

Generic European Driving World

Our most recent military project is a tank training simulation. As with most of our vehicle training simulations, we have built hardware that closely resembles the internal cabin of the real vehicle (to the point where it feels as if you're in the real tank). For this particular sim the driver compartment is mounted upon a three degree of freedom motion platform. Since we're simulating multiple episcopes, external cameras, thermal imaging, night vision etc, we use multiple 'nodes' (i.e. multiple PCs connected via a network), with different graphics nodes controlling the visuals of different screens, and a core dynamics node running the physics engine, controlling vehicle internal logics and general driving dynamics (this is common practice for us, our sim framework is geared toward this kind of distributed architecture).

I can't really provide too much information about the vehicle aspect of the simulation (to avoid non-disclosure clause issues, I prefer to be cautious when it comes to military projects). However, what I can talk about is the generic European world we have built for this project.

My role was lead software developer for the world team, as well as technical lead for implementing new sim features to meet the requirements of the world. This is the largest and most complex world we've built, and so getting started on the project was a daunting task initially. There were many new, high-risk features and a limited time frame, and so the beginning R&D phase required a fair bit of planning and brain-storming.

Some of the features and tasks required for this project were:
  • Taking fuller advantage of our dynamic time and weather system. I ported this code across from my own engine, Transcendence, a few years back, but we haven't been using it to its full capacity until now.
  • Support for season transitions. We now support summer and winter.
  • Support for snow precipitation. Previously the only precipitation model supported was rain. Besides the visual aspect (implemented via particle systems), this had repurcussions for our dynamics team (driving surfaces are affected by precipitation, for example, by becoming more slippery).

  • A procedural terrain texturing system. The clients wanted vast tracts of drivable terrain, and so we needed to provide high fidelity, detailed terrain throughout the world. The world was far too massive for the artists to texture it by hand in the given timeframe, and so I coded a terrain shader that did this procedurally (with some degree of user control via the use of what I call the 'control map'). We were very satisfied with the outcome, the terrain looks good.
  • Support for snow-covered terrain during winter. I modified the aforementioned terrain shader to dynamically alter the amount of snow on the terrain based on the surface normal of the landscape at any given point. This gives a more realistic look, with upward facing surfaces receiving more snow than steeply-sloped surfaces. So, for example, cliff faces are rocky rather than snowy, but plains and mountain peaks are covered in snow.
  • Support for dry snow, wet snow and icy roads.

  • A complete re-working of the way we construct pathing data. The world was just too massive for it to be feasible to manually construct pathing (this was the case for Durban driving world as well). For this particular project the art department used a 3rd-party city construction toolkit to build the roads. The framework allows the exporting of the spline information used to construct the roads, but unfortunately provides no documentation about the formatting of this information, and so I to figure it out (this entailed a fair bit of trial-and-error and guess-work). This turned out to be a success, and it allowed me to procedurally generate all pathing data from this spline information (I basically wrote a configurable command-line application to convert their splines to our pathing format).
  • The previous change (as well as the scope of the world) required various modifications to our traffic system (specifically, I needed to re-work the pathing algorithms to no longer rely on pre-computed paths).

  • Implementation of various miscellaneous world features (for example, see the train in the image below).
  • Implementation of a set of exercises and associated scoring checks (too many to discuss in any reasonable amount of space).

Sunday, September 30, 2012


I've been working on a casual game, targeted at iPhone and Android, called Shroomsters. I was initially inspired by an old game I loved as a kid, Wonder Boy 3: the Dragon's Trap (I re-played it again recently). However, as development progressed, it morphed into something quite different. At some stage I thought it would be interesting if we reversed the situation from Mario Brothers, and have mushrooms as the good guys against evil Italion plumbers. So the main protagonists are mushrooms, though the evil plumbers concept never materialized.

When I was in primary school and high school, I was spent a lot of time day-dreaming and drawing, though after school I focused on other things and neglected drawing / illustration altogether. For this project I decided to do the art myself, and so I picked up illustration again (this time in Photoshop, occasionally scanning in hand-drawn art and re-creating it on PC). Although the art style is very simplistic, but I'm quite happy with the style of the end result.

Similarly, musicianship is something that I was passionate about that I have neglected in recent years, so I decided to make the music myself. I deliberately went for an old-school chiptunes feel, inspired by the music of the old 8-bit and 16-bit platform games, and arcade games of that era. Examples of games whose music I particularly liked are Sonic the Hedgehog, Wonderboy 3 and Ghosts 'n Ghouls.

The game features four campaigns, each with its own theme. These are differentiated by their visual backdrops, audio tracks and play styles (for example, some favour puzzle-type play, others favour the good old-fashioned left-to-right platformer style). Additionally, each campaign features a different (though sometimes overlapping) set of enemy monsters. The campaigns are called 'Mushroom Dawn', 'Ice Crags', 'Enchanted Garden' and 'Apocalypse City'.

The game was developed using the Unity engine. All programming was done in C#.