Dev Blog

The last few weeks I haven’t had much time for Stolen Notebook.

I am one of two programmers at a small startup software company near Madison. I have about 5 hours of free time a day to split up amongst things like eating, working out, reading, and Stolen Notebook. I have even less time if I want to get a reasonable amount of sleep. The last few weeks have been especially hectic since we are nearing a deadline for a second round of investment and need a solid product to show. We have had two rounds of beta testing in order to prepare, which meant extra time spent on the weekends fixing and supporting problems.

Luckily, at Stolen Notebook we have reached a point in development where the workload has started to spread out considerably. The basic engine design is now very solid. Denrei can push source assets through the tools and Tony can use them in the game. Tony has been able to develop game code with very little direct support from me. This means my time can be spent adding new features instead of constant debugging of tools and engine code.

What I am looking forward to is the possibility to further automate our development process.

Some time ago Tony setup buildbot. It automatically builds our engine, tools and documentation when anyone checks in code to subversion. This has freed up a lot of time for everyone. I don’t have to worry about building the latest tools for denrei, they’re automatically available. While this is great for code there has never been a solid process for building games assets.

A long time ago I created a automated game assets build system called SNax (Stolen Notebook Automated eXporter). It was useful…when it worked. It never worked very often. It was very difficult to maintain SNax because the engine was developing so quickly. SNax couldn’t keep up with the changing formats and features. It was eventually left by the wayside.

The next, shortlived, iteration of asset building was to store source assets in subversion. Let me just say this: SUBVERSION IS TERRIBLE FOR STORING LARGE BINARY FILES. Subversion stores two copies of all files it has under revision control. One copy is the one you work on, the other is hidden away in the .svn directory so that you can revert to the original at any point without copying the file from the subversion server. This means that everything takes up twice as much space, and takes twice as much time to checkout. A secondary problem is that diffing huge binary files is very time consuming, so checking in files you’ve changed takes even more time. Denrei tried this system for a short while, and spent all his time waiting upwards of 10 minutes while his work was checked in. The new asset system will have none of these problems.

The major inspiration for this asset building server is this article. The article describes a very simple way to use python to detect file changes in a directory. I’ve done something like this in C before. Doing it in python is much more sane. This script sits and waits for files to be modified in a directory on the server, which is shared on the network, then exports the source asset to the game asset if necessary.

This script fits very neatly into the existing tool set. Let’s consider snscene, the Maya scene exporter. Right now denrei or Tony has to use snscene manually. By associating the Maya file extension (.mb) with the ‘snscene’ command in the directory watching script assets are exported whenever denrei changes a Maya file on the server. The tools don’t have to be modified to support this since the script uses them the same way a user would. The tools can still be used manually and the tools and the automated build system are strictly separated, making maintanence easy.

Enhancing the benefit of this automated build system is out brand new Gigabit network. Denrei tells me that he can transfer files across the network about four times faster than on our old 100 MBit network. I believe him. Gigabit ethernet makes the asset server feasible. It should be almost unnoticible for denrei that he is working on source assets across the network. Combined with the automated asset builder, every time denrei saves everyone should have the latest games assets in a matter of seconds. And no one has to do a thing.

Things have finally settled down a bit after moving. The new apartment is fantastic. All of Stolen Notebook is now in the same place. We haven’t been able to get back into things though. We’ve been unpacking for the last few days. I just got my computer setup yesterday and internet should be hooked up today.

There is an investor beta-test at work this weekend. I have a lot of things that need to be finished before then. Hopefully by the weekend I’ll be able to spend some time doing Stolen Notebook work. I’ve been amassing a lengthly list of things to do…

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.