One issue that needs to be solved during game development is how to get the art from the modeling tool into the game.
The answer might seem to be trivial: "Just export the model in a file format that can be read by the graphics engine!" Unfortunately this is not as simple, even when both the modeling software and your graphics engine support the same file format.
Content, content, metadata
Many non-graphical pieces of information (metadata) need to be provided. In our racing game SuperTuxKart (STK) for example, map models need further detail:
- Kart starting positions.
- Mesh of the driveway.
- Position of items boxes (powerups) and bananas (traps).
- Type of track (arena or racing).
- Name of the map designer.
- Can the map be driven in reverse?
- What music should be played?
- How to handle animated objects?
- What graphical effects (particles, animated textures, snow) and what sounds should be used and where?
- Optimizations like backface culling.
Re-inventing the wheel... not!
Usualy, the answer to these questions is to create a separate editor which allows 3D modeling and exports the additional data necessary to actually use a level or object (or kart) in the game.
Creating and maintaining such a piece of content pipleline requires resources and can slow down or even halt other development, depending on the team size. With the three free-time programmers on our team, we couldn't afford this investment.
A track editor has been developed by a community member years ago, but it was never even close to being able to design track of sufficient quality and eventually was abandoned. Instead of restarting such an effort, we chose a slightly different approach.
Extending the modelling tool
We extended the existing modeling tool commonly used for creating tracks: Blender (a tool used for example by the renowned indie game creators Wolfire), so that the necessary options can be set in Blender's GUI. Our scripts for exporting tracks and karts make these options available in game.
This method reduces development time and allowed a tool, that is already known to many artists out there and has tons of documentation available, to create content that is perfectly fit four our game. We only need to document our specific extensions.
The magic behind the scene that makes it possible to take a map in Blender and run it in SuperTuxKart is made up by several Python plugins. The first plugin, which can be seen in the screenshot, is the “Panel” plugin. Once this plugin is added to Blender, a few game-specific panels appear in the properties view (one for object properties, one for scene properties, one for material properties).
With a few clicks in the properties panel, you can change the sky, make it snow or rain, add fog, make a water surface animated or specify that particles or sound effects are emitted from a point!
There is first the track export script, which reads these properties and exports them to XML files for the game core to read (which includes support for moving/animated objects). The “B3D” script also exports the mesh to the B3D file format (which also supports skeletal animation, as well as vertex colors and multiple UV maps for lightmaps and normal maps).
None of this would have been possible had Blender not been so scriptable. Our panel script can serve as example documentation for anyone who wants to make a custom Blender panel. The scripts actually load the description of the contents of the panel from declarative XML files, making it easy to change the contents of the panel. Interested? All of our scripts are open-source and available for both private and commercial use under the GNU GPL license.
The materials panel automatically lists all textures in the blend file, and allows specifying several properties, for example:
- Surface properties, when player is in contact with it:
- Is a particle or sound effect emitted?
- Does it slow down or speed up the player or have a non-standard tire grip?
- Do players pass right through it?
- Viewable texture properties
- Transparency/opaque value
- Transparency effect (Alpha Testing, Alpha To Coverage or Alpha Blending)
- Shaders (for example normal maps, splatting, water reflections, lightmaps, sphere mapping)
Powerups and traps (goodies and baddies)
It's nice to have the static model, but after all this is a game so we need to give the player some goodies and baddies! Fortunately there is an easy way to add them : our plugins extend the global "Add" menu of blender with new object types specific to SuperTuxKart, like gift boxes, nitro or bananas.
Drivelines and checklines
Finally, how does the AI know where to drive, and how do we check that human players do not cheat? We chose to use a set of simple meshes, called drivelines, to indicate where players may drive.
These simple meshes are then processed by the exporter into something that is easy to import in the game and to follow by AIs. Checklines are added in addition to that to prevent cheating.
As a bonus, drivelines do not need to be linear, but may be exported as a graph, allowing for quite complex structures to be constructed directly inside Blender.
While the Python API documentation is not always optimal, and while a few API changes broke everything and made us swear loudly in the past, Blender's Python API is very flexible and powerful and a vital part of our game development workflow, which will hopefully inspire others to design their tools with it.
Always on the lookout for content creators
We are always looking for modellers to help us improve our older, less impressive worlds. :) If you have experience in modelling and you feel like helping, you will be warmly welcomed on our forum, mailing list and IRC channel!
Further details of our map-making process can be found in the Track Maker's Guide.