Dev Blog

I really enjoy using XML for game data.

I have been using XML for Stolen Notebook projects for a while and it has worked out extremely well. The syntax kind of sucks, but if you use any of the readily available XML editors like XMLpad or XMLShell, this isn’t so much of an issue.

There are actually a few ways of storing data in the XML format. However, there isn’t much information about using XML for defining game data. When I was adding XML support to our current engine I didn’t really have a good idea how to store the data or the benefits of the various possiblities. I ended up having all data defined as properties of tags. Mainly because it’s easier to parse with the XML library I was using.

I was browsing around the web the other day, and happened on MoonPod’s Development Diary and a post about using XML for game data. I used the second method described in the post. If you are thinking about storing your game data in XML — and I recommend you do — then you should definiately check it out. If you aren’t interested in XML for game data check out their development diary anyway, it’s very interesting.

EDIT:  If you decide to use XML I suggest you use an XML editor if you decide to edit XML by hand.  I was working with a shader and wondering why it wasn’t compiling, and it turned out that I was using a ‘<' which should be written as '<' in XML.  It sucks to look at and type, an XML editor would do this automatically and you wouldn't notice the difference.

It seems to me that game programming is viewed as distinct from software engineering. As though being a game programmer allows you to “pound out code” until it works and stop. Game programmers learn to program “on the street.” Why worry about good design, or even learn about it? Just make an awesome game, dude! You can get a game programming job with all your “street” skills. But this can be a trap for many aspiring game developers.

What worries me is that potentially talented people get sucked up by the industry right out of college, or even before, and never see light of day again. They are stuck fixing disperate pieces of game logic with no education in design (formal or otherwise). Game companies seem to prefer throwing money at people who have enough experience to push another proven money maker out the door. People can be lost for years in this process only to come out with nothing but the skill to hack code onto an existing codebase in order to ship a product. A company’s willingness to give you money doesn’t imply you are a good programmer. Money is just an easy way to brute force problems.

In my opinion, being a great game programmer means being a great software engineer. It takes a great deal of experience and willingness to learn. A lot of that experience has to be self-motivated and external to school and work. Unless you get a job that pays you to read instead of programming. It’s the kind of experience you won’t get when you are told to rewrite player spawn logic for an existing engine.

My personal plan to becoming a good game programmer is this: Make sure your first full-time programming job is NOT in the game industry. Read books about programming, design and software engineering. Personally, I’ve found that the education I paid for was sorely inadequate in this regard. If you really want a job in the industry, make sure it’s a very good opportunity where you can continue learning. If the company culture encourages continued learning, even better.

Game programming is HARD. It’s taken me years just to begin to see that I am capable make real game technology. As long as you keep learning how to become a better programmer you only become more capable of making a great game.

How inspirational.

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.

After finally coming up with a name we actually like for our first game, we started thinking about logos. Gavin sarcastically suggested making the O into a planet. I’m sure this has been done many times for space related games. For Homeworld for example:

This seemed a little obnoxious. The idea I had was to make the make the rim lit part of the planet opaque, and the dark side of the planet transparent, so you end up with an O instead of a filled in circle. I made a prototype to exemplify my idea. The black is transparent…

I’m not skilled enough to finish this to my liking. There needs to be a bit of rim lighting on the dark side of the planet so that it’s more O like. Hopefully, with Denrei’s help, we can develop this idea into a nice looking logo.

Edit:
Wow, this photoshop tutorial is amazing!

I’ve taken to getting headaches lately. It is likely caused by staring at LCD and CRT monitors at work and at home. It also could be because I get no more than 6 hours sleep a night. Could be both. I’m looking forward to having extra time over the holiday weekend coming up. Maybe I’ll go buy some granola bars, I’m running low.

All the blogs have been setup, Denrei and Tony have gotten to customizing them. I don’t know if Gavin knows he has a blog yet. A Stolen Notebook homepage blog was created where we’ll post news and the like.

Our goals for this week are to get bounding volumes and the new custom maya nodes exported to scene files. I’m hoping it will be relatively easy. The custom nodes should be easily detected. Once their found, it’s just a matter of exporting their position and rotation. I looked at SNTools, and had to fix some bugs in the option parser. Just some issues with the move to VS2005. Now I just have to figure out exactly how I tell what custom node I’m looking at. Then it’s a breeze from there. Maybe I’ll finish it tonight…

Edit:
I found out how to detect if a node is a custom node. Take your node, create a MFnDependencyNode, then call typeId() to get the node’s type identifier. Simple? yes.

I’ll be able to work on this full bore tomorrow now.