The Light - It s Not a Train After All


The Light—It's Not a Train After All

It's a day you'll remember for every project. At some point, there will be a single approved bug in your bug database. It will be assigned to someone on the team, and likely it will be fixed in a crowded office with every team member watching. Someone will start the build machine, and after a short while the new game will be sent to the testing folks. Then the wait begins for the final word the game has been signed off, and sent to manufacturing. You may have to go through this process two or three times—something I find unnerving but inevitable. Eventually though, the phone will ring and the lead tester will give you the good news.

Your game is done. There will likely be a free flow of appropriate beverages. I keep a bottle of nice tequila or maybe a good single malt scotch in my office for just such an occasion. You have a few weeks to wait for the channel to push your game into every store and online site, so what do you do in the meantime?

Test the Archive

The first thing you do is take a snapshot of the build machine and the media files on your network. Your job is to rebuild the game from scratch, using all your build scripts, to make sure that if you ever need to you can restore a backup of the game source and rebuild your game. Start with a completely clean machine, and install the build machine backup. It should include all the build tools such as your compiler, and special tools that you used to create your game.

Restore a backup of the network files to a clean spot on your network. This may take some doing, since your network might be pretty full. It's a good idea to buy some extra hard drives to perform this task, since it is the only way you can be 100% sure your project backup will work.

Once you have a duplicate of your build machine and a second copy of the network files, build your game again and compare it to the image that is signed off. If they compare bit for bit, make some copies of the backups and store them in a cool dark place, safe for all eternity. It is quite likely that your publisher will want a copy of the backup too, so don't forget to make enough copies. If the files don't match, do your best to figure out why. It wouldn't be completely unusual for a few bits to be mysteriously different on the first attempt. The existence of a completely automated build process usually makes the archive perfectly accurate, which is a great reason to have it in the first place.

As a last resort, if your files don't match the best thing you can do is document the delta and have your testers run the rebuilt archive through the testing process once more. This will ensure that at least the game is still in a shippable state, even though some of the bits are different.

Best Practice

Don't forget to backup the bug database in some readable format, such as an Excel spreadsheet or even a CSV file. Store it along with your project archive and if you ever want to start a sequel, the first thing you'll do is figure out which postponed bugs you'll fix.

The Patch Build or the Product Demo

It's not crazy to start working on a patch build or downloadable demo immediately after the project signs off. The patch build is something PC developers are somewhat well known for, and if you know you need to build one there's no reason to wait. A downloadable demo is always a good idea, and many game industry magazines can also place a demo in an included CD.

I suggest you leave the patch build in your main line of development in your source code repository. The patch build should simply be the next minor version of your game, and is exactly what you've been doing since your zero bug date. You can release the thumbscrews a little, and consider some slightly more radical solutions to problems that you wouldn't have considered just a few days ago—it all depends on your schedule for the patch.

It wouldn't be uncommon to wait for initial customer feedback for finalizing the features and fixes that you'll include in your patch. Your customer base can be tens of thousands if not hundreds of thousands of people. They will likely find something your testers missed, or you may discover that a known problem is a much bigger deal than anyone expected.

The downloadable demo should exist in a separate branch in your source code repository. This is especially true if you code the demo with #ifdef _DEMO blocks or some such mechanism to cut your game down to a tiny version of itself. It wouldn't be crazy for some programmers to work on the demo and the patch simultaneously, and a separate code branch will help keep everything organized.

The Post Mortem

A good post-mortem should be held a few weeks after you sign off your game. There are tons of ways to handle it, but there are a few common goals. Every project is a chance to learn about game development, and the post mortem is a mechanism that formalizes those lessons, which will ultimately change the way you work. It isn't a forum to complain about things that went wrong and leave it at that. Instead, your post mortem should identify opportunities to improve your craft. It is a forum to recognize a job well done, whether on the part of individuals or as a group.

In post-mortems, it's really easy to get off track because everyone on the team wants to say their piece about nearly everything. That's good but it can degenerate into a chaotic meeting. It's also not a crazy idea to split the team into their areas of expertise, and have them conduct mini-post mortems in detail. For example, the programmers might get together to talk about aspects of the technology or their methodologies, surely stuff that will bore the artists to the point of chewing their own limbs off to escape the meeting. Each group: programmers, artists, designers, producers, and whomever can submit their detailed report for any other similar group who wants to learn their lessons.

The team post-mortem should focus on the game design, the project schedule, lines of communication, and team process. If someone believes they have a good idea of how to improve things, they should speak up and if the group thinks the idea has merit, then they should act on the idea.

One thing that isn't immediately obvious is the fact that you won't learn everything in a public meeting. Some of the most important information might be better discussed in private, in the hopes that someone's feelings won't be bruised. If you get the chance to run a post-mortem, don't forget to follow the public meeting with private interviews with the team. It will take a long time, but it's a good idea.

What to Do with Your Time

When I reached the end of my longest project to date, Ultima VIII, my first act was to walk outside Origin's offices, sit down at a picnic table, and enjoy the light, smells, and sounds of a springtime Texas afternoon. I had been in a dark office working overtime for two years, and I'd forgotten what daytime was like. I went home and found a person there. After introductions, and reviewing surprising evidence in the form of a photo album, I realized that the person in my apartment was actually my wife of over three years. I asked her out on a date, and she accepted. Then I asked her to accompany me on a diving trip to Cozumel. She accepted that too.

I suggest you follow my lead. If you don't have a spouse go somewhere fun with a friend. See the world. Get away from your computer at all costs. It will do you some good, and may give you some fun ideas.

You won't be able to stay away from work forever. The paycheck is nice but the desire to make another great game will soon overwhelm you. You may embark on a sequel to the game you just shipped or you might get to do something entirely new. Either way, you'll be surprised at the energy level. People on the team who looked like the living dead just a few weeks ago will be ready to go around again.

There's nothing quite like starting a new project. You feel renewed, smarter, and if you're really lucky you'll get to work with the same team. After what you've just been through, it's likely you'll have a good portion of mental telepathy worked out, and you won't need quite so many meetings.

One thing everyone will quietly do is make excuses to walk into computer game stores looking for the box. Eventually you'll see it for the first time. There's nothing like it, holding a shrink-wrapped version of your game in your own hands. I sincerely hope you get the chance to do that someday. Everybody deserves that kind of reward for such mammoth effort.

The game industry is a wacky place. The hours are long and the money sucks. I know because I've been in it up to my neck since games ran on floppy disks. Somehow I find the energy to stay in the game. Am I just a glutton for punishment?

I guess there's a lot to be said for a profession that has one goal—fun. I learned in scouting that you should always leave a campsite better than you found it. I guess that working on computer games is a way to do that for much more than a campsite. My work in the computer game industry has hopefully had an effect on the people that enjoyed the games with my name somewhere in the credits. My work on this book has hopefully made working on the games themselves more fun and more enjoyable.

Only time will tell, eh?




Game Coding Complete
Game Coding Complete
ISBN: 1932111751
EAN: 2147483647
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net