Skip to content
February 22, 2011 / racoonacoon

The Level Editor

Howdy, howdy everyone, glad to see that you could make it back! In my previous post I mentioned that more more details would be given about the current development process of The Sphere, and how we are aiming to improve it. This post will cover how we are building our levels, the problems we are currently facing, and the plans we have for resolving those problems.

In our first week of development, CJ and I asked ourselves one of the most fundamental aspects of any 3D game, how were we going to build the levels? We were going to need some sort of decent level editor to build any semblance of a fun game, but we didn’t want to spend the time (nor did we even have the time) crafting our own. After a bit of thought we decided to use Blender3D 2.49 (an opensource 3D modeling tool) as our level editor, and use its .obj exporter to export our scene. From there we could just build a couple of python files to further process the information into a format our game understands.

This worked out pretty well for the first level, when we didn’t have any textures, materials, or many effects going on, but we hit a wall as soon as we wanted more detailed information. One of the issues was a limitation with the .obj format itself. The .obj format can only express basic information about a model, such as its vertices, uv coords, and rudimentary material information. We needed at least a way to know the type of bounding volume surrounding the object, the effect it is using (normal mapped, reflective mapped, regular, etc.), and the properties of that effect. Ideally we would also have the data about the scene itself, such as the cameras, lights, particle systems, skybox, etc. An option would have been to hand edit the .obj files and include this information ourselves, but that seemed far too tedious, error-prone, and slow. The other option would have been place all this data in the Name field of an object in Blender, and parse it out in one of our python files, but this would have been equally messy and erroneous as the previous solution. There was only one realistic thing we could do at this point: write a custom exporter within Blender.

But how were we going to do something so audacious? We wanted our scope to remain small, and this task felt like it exceeded our limits. That is, until I recalled a video I had watched some time ago covering Blender 2.5 and its deep integration with python. From what I could recall everything in Blender 2.5 (including the interface) can be edited, in real-time, through python scripts! Not only that, but information about the entire scene could easily be extracted with a few lines of python code. Blender 2.5 is still in beta at the time of this writing, so it is a pretty risky move to began using a piece of potentially unstable software to build the levels for our game. If it turns out the API is solid enough however, than we can really get to making some awesome levels! If things go well, it shouldn’t be all that difficult to write a python script from within Blender 2.5 (and potentially a full-blown exporter) to export the file exactly as we need. Furthermore, it is also possible to actually extend Blender’s interface to accommodate our game’s needs specifically! I’m still looking into this to see if it is a possible move. I hope it is!

The exporter is only one end of things; we also need an importer to read all this data in.

This was actually completed just last night by CJ. He wrote a nice importer that can load in basic scene data from a .txt file, allowing our game to be much more data driven. The importer can read in multiple cameras, lights, and particle effects, so we can declare all that inside a text file rather than putting it directly in the code. The only thing left is for me to write a scene exporter in Blender. I am torn between playing around with that now and working on the internals of Claudius, as the recent addition of Dynamic Environment Mapping (which causes the game to be rendered six times more than usual) to our Sphere has significantly slowed down our game. Just a few days ago I added in per-object frustum culling, and that boosted us from 45fps to 70fps on my quite old 8800GTS, but that still doesn’t leave us a bunch of room to play around with. The next goal for Claudius is to implement dynamic mesh batching to reduce the huge number of draw calls our game is making (for those unawares, each draw call carries with it a great deal of cost, so too many will slow the game down pretty hard.) I’ll probably go ahead and mess around with dynamic batching, though I have to be careful not to overspend my time on it.

Over and out!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: