April 27, 2012

Using Blender as a 3d map editor, rather than programming your own from scratch

From Blender to the game: a significant step


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.

SuperTuxKart map and extended panels in Blender


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!
Models
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.
Materials
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.

Driveline mesh in Blender


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.

Conclusion

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.
This post was written as a collaborative effort by Arthur, Auria, hiker and qubodup.

April 1, 2012

[April's Fools Joke] New version numbering scheme

The SuperTuxKart development team has decided to change version numbering to keep up with the times and make it easier for people to know if they are using the latest version or not. So the upcoming 0.8 release will not be named 0.8. Inspired by Mozilla, we'll simply call it 8. But inspiration comes seldom alone, so since Ubuntu's version scheme makes it easy to know when the latest release got out, we'll adopt it as well and call it 8 followed by year and month. So for example 8.12.08. Then it dawned upon us: why not include revision number? Then there will be no doubt as to what version you're using, especially if we release a newer version in the same month. So the upcoming version will be named something like 8.12.08.13337. You get to choose what number you want to refer; either you say you're using version 8, 12.08 or 13337, or you might choose any combination of two or more of those.

We also like the idea of giving names to releases. So next version will be nicknamed SuperTuxKart Gutsy Gnu, or maybe Nasty Nolok or Silly Suzanne, we're not sure yet

We look forward to the release of version 8.12.something.something, and hope you'll find it easier to get the right version number when reporting bugs or otherwise talking about the game.