Dev Blog

CrossBlast turned out to be an excellent test of the Catharsis engine, tools and development process. I finished the tools just before CrossBlast development began. Except for a build fix early on, they worked wonderfully throughout the entire process. The engine was a similar story, I only added a color render state during development. There were no show stopping bugs in either the engine or tools. I spent most of the development time helping out with the various aspects of releasing CrossBlast, and waiting for critical bugs which never came.

Much of the engine and game architecture was validated as CrossBlast was developed. Specifically, the way the event system and scripts work turned out to be a great choice. Scripts can be attached to any node and will process the events sent to that node. Scripts can be swapped effortlessly, making prototyping very easy and modular.

Another smart decision was in the scene system. The files that define the scenes are XML. This allows easy processing using standard XML parser libraries. There are also a lot of very nice XML editors that we can use. In the XML scene files arbitrary properties can be added to nodes. All properties are automatically available to the scripts in the game. This avoids hardcoding magic numbers into the game scripts. This keeps the data in the XML files and the logic in the game scripts. Eventually these properties will be able to be defined generically in maya.

CrossBlast helped us to realize what can be done with our current codebase. It has also shown what we need to do next.

I have finally gotten to a point where I am very happy with the design of the exporter, from a software-engineering standpoint. The past few days were spent simply staring at every part of the exporter code and asking, “Is this well designed? Can this break? Is this modular?”

When I first started programming I thought it was pointless to ask these questions. Instead I would dive blindly into writing some code thinking, arrogantly, that I was such an awesome programmer that I would just end up with fantastic code in the end. I’d come back to it later and it would be a mysterious piece of crap that I no longer understood and was unnecessarily complicated and inflexible.

It may occur to you that my about page says I have a degree in Computer Science, that I probably learned these lessons at the University of Wisconsin Madison. I’m sorry to say they don’t actually teach that, they don’t even acknowledge it. If you are serious about programming I would suggest, highly, that you actually go beyond your class work and read a few books on software engineering and architecture. The best book I found on this subject is Large Scale C++ Software Desgin. And don’t think your above these things, unless you’ve had lots of experience developing lots of software.

Anyway, new node types can be added and handled very elegantly by the exporter. It took a little work to get the Maya API to do exactly what I wanted, but it’s turned out extremely well. Right now geometry, bounding volumes, and scene nodes are exported. Maya transform nodes are handled properly as well. They only modify the transformation of the nodes in the scene but are not exported. This allows a user to group together things in maya for convenience while not having these unnecessary nodes export to the final scene. Many new nodes will be eventually added, Lights, Sounds, etc. All very soon.

At the Stolen Notebook quasi-weekly meeting Tony and I discussed using ODE for collision. He had written the standard bounding volume tests (OBB, Sphere, etc) already so there was an infrastructure in place. Adding ODE would be a simple task of replacing the low level collision code of these Bounding Volume objects with some ODE code. There would be no outward differences. Besides the advantage of using a mature and stable collision library ODE will allow us to easily add physics, which I am very excited about. So, while Tony did this I left for the weekend, and did nothing (well, I finished Lunar Park and started Neuromancer). Now that I’m back, it seems it turned out pretty well. Now, we have to figure out how the collision system is going to notify the game code.

On my side of things I didn’t get much done because I was gone. I’m taking a second pass on the maya exporter, getting it separated and streamlined. It should take another day or two to get it to the point I want it.

When I arrived at work today, a package of Huggies “Cruisers” was laying at the entrance to the neightboring office complex. The package did not have proper key-card clearance to get into the office. When I left, the package remained. I felt a slight sadness, and wondered if I’d see them tomorrow…

I picked up Metal Gear Solid: Digital Graphic Novel last week but didn’t have a chance to play it until this weekend. I really enjoyed it. A lot of people complain that it has no voice work. I think that would detract from the experience. I don’t want to watch a movie. It works for me better as a interactive book.

The game mainly consists of a story mode. You can stop the story and search for memories anywhere in the game. A graph tells you if there are any memories in nearby pages, and the cursor spins faster when it gets close to a memory on the screen. Once you find memories you can go into the memory building matrix and connect them together. Putting together certain memories triggers a flashback that adds more memories to be found in story mode. Each memory has a brief explanation and it’s interesting to see how various people and organizations relate. It’s nice to be able to visualize the many agendas of the various characters and who is really working for what organization. It was also interesting that some of the memories started to spill over into Metal Gear Solid 2: Sons of Liberty. Some of these memories started appearing outside the matrix itself and had dangling links. Perhaps a MGS2:DGN is in development and will interact with this one?

I finished the game completely. I found all the memories and completed the memory matrix. This was no small feat. I would play the game around 12:00am and then I would look up and it would be 4am! I think it took about 10-12 hours! And I loved every minute.

I also got a copy of Gran Turismo 4 (which is now only $20, so go buy it!). I have GT3 and I played a great deal through it. I remember the menus were very awkward at times. Having to click through a lot of extra buttons to get into and out of races. Gran Turismo 4 is a dream compared to this. The interface is extremely clean and efficient. There are also a host of new features, and everything looks much better.

I started out with a 1983 Toyota Corrola and have been tearing up the beginner circuit. I also took some time to pickup my class B license. It’s nice to have a game with no easy outs, you actually have to be able to drive in order to get anywhere.

I refactored the exporter a little bit and simplified it in general. Meshes now export perfectly with their proper transforms.

The meshes have to export to obj files relative to their parent SceneNode. The easiest way to do this is to just put the scene node exactly at the origin and call maya’s export obj function. Unfortunately, it’s actually pretty difficult to do this from Maya’s C++ API.

The solution?

Use the Maya API to call MEL commands. I burned most of a day trying to get meshes to export properly using only the C++ Api. Once I remembered I could use MEL, everything was working perfectly within 20 minutes. I don’t know why, but when I work in C++ I completely forget that MEL even exists.

In all, the exporter can handle just about any scene that can be made in maya.  I exported one of Denrei’s maps blindly and there were no problems.  Further, the exporter is architected in a way that makes it dead simple to add handlers for exporting new node types.  So, when we want to add a new node, perhaps a sound node, a handler is added and it is exported with the scene.

I’ve been upgrading the Maya exporter to handle the new custom Maya nodes I created. The custom node SceneNode gets exported directly to SceneNodes in the engine. So, engine-side, these SceneNodes form most of the scene graph, with meshes and whatnot as leaves. In Maya, however, SceneNodes aren’t the only heirarchical node. The standard Maya Transform node is still used to organize the scene for convenience when editing the scene. For instance, a static mesh could be made of many separate meshes, each with their own transform. The meshes can be manipulated individually easily, and when it’s time to export, they get merged into one mesh (because they aren’t separated by SceneNodes). It remains easily editable in Maya yet comes out as one optimized object in the engine.

The exporter works by propagating transformation information down the scene graph, pretty much like a standard scene graph does. The one difference is at a SceneNode. When a SceneNode is encountered the accumulated transform is stored in the SceneNode and then reset before traversing the children. This produces the correct transformation for a SceneNode relative to it’s parent SceneNode. The same is done when known leaf node types are encountered.

Right now it’s dumping the transformation information while traversing the scene. The current node is checked against a table of known types and if it is found to be exportable it is written out. This is much more flexible than the previous exporter, which had no custom nodes. Previously I had to make a lot of assumptions about what various scene structures become into when they export. Now it’s all very explicit. I should be able to drop a few hundred lines of code and add new node types with no problems.

I tried playing Bush’s Glycerine on Gavin’s guitar for about 7 minutes…my hand is now numb.