Ultima Game Developer: Milestones

One of the first things a novice game developer asks is, “When should I release my game?”

A serious game developer knows that there is only one real answer, “When it is done.”

Done, unfortunately, means different things to different people. Most game developers are artists, designers, programmers, scripters, and writers. They are perfectionists, always wanting to change a few things to make the game perfect. Perfection is impossible, so they are always seeking and never finding. “Done” is never “done”.

How do you know when the game is “done enough”, however? Most often, you set milestones for your progress, points where you will show off what you’ve done to some select few. Once you’ve reached some arbitrary point, you must decide whether it is worth putting off release for some minor changes, or if you are content with allowing the public to see the “final” work. Even then, however, as game designers, you have the luxury of releasing updates that add content, fix flaws, and polishing your masterpiece: the wonder of “the patch”.

White Book

Before you can begin your game, you need to decide on the engine you will use to create it, and determine its capabilities. Even if you are using an existing game engine, like Unreal, or developing a new game for an existing engine, such as Exult Studio, numerous modifications will need to be made to the engine to incorporate your vision. Modifying the engine itself may not be possible, but it is surprising how much versatility can be found within a single game engine. UDK, for example, is designed as a 3D first-person shooter engine. However, the powerful backend also allows the entire engine to be rescripted, changing default camera angles, weapon types, mouse actions, even rewriting how characters are handled on a very low level. Entire systems will need to be developed in order to make a 3rd-person, isometric overhead roleplaying game such as Ultima, but it is entirely possible to do so.

Determining the capabilities of the engine often comes first, before you can plan your game. Some developers create an engine, and they write the game to fit the engine. Others modify an engine to fit their game. Either way, it is always wise to overshoot your expectations. An engine that can do more than you need it to is far more powerful and adaptable than one that can do only what you expect you will need. For example, say you want a system for NPCs to move from one location to another. It may require you to create a combination of AI, pathfinding and scheduling that allows the character to move from one point to another. However, if you also add the capability for that same system to handle stopping at multiple, mutable points along that path, your engine is more capable than it might have been. Later, when adding a NPC, you might decide you’d like this character to stop and chat with other NPCs along their path. You can then link those NPCs to the pathfinding script, and the NPC will wander along a (slightly broken) path between them, on the way to their destination. You’ve solved an issue that didn’t even exist, because your engine already had the capability.

Your “white book” is likely to take the form of a final development environment in this day and age. Talented scripters and programmers can use just the engine modifications, be it source code or UnrealScript, as part of their resume. Remember that this step can be far too easily overlooked by assuming that whatever game engine you already have will do everything you want, right out of the box. It will not. Making the engine “yours” will require a lot of time and effort, but is what makes truly wonderful games possible.

Technical Demo

The earliest “release” is often simply a demonstration that the engine can do what you expect it to do, and that your basic concepts all work in concert. You test your character, motion, inventory, magic, skills, save, load, combat, AI, conversation, and various other systems function. Your goal with this milestone is not to make a masterpiece, but to simply show “I can do it”. This piece will also often be the one you present to your potential employer, showing them the same thing and allowing them to put their faith, name and financing behind you.

Obviously, this step is very important.

Black Book

It is difficult to thing of this as a concrete step, but creating your “game bible” is probably the most critical thing you can do. This is often done without the creation of any material assets: no models, music or scripts. Instead, you plan the overarching plot of the game, the major side plots, crucial NPCs, and so on. The bible, or black book, is what you will use whenever something comes up in the development process; if it is in the black book, it MUST be completed because it is part of the important pieces of the game.

Also in this phase will be the binder, which contains all of the pieces of the game that you WANT to add, but are not crucial pieces of the main plot. These are all compiled, and fleshed out enough to give a good lead in for development, but are not detailed as critically as any piece in the game bible.

It is easy to get lost during this phase. Designers like to design. If you find yourself pouring over details about NPCs and quests, but realize that only the most persistent player will realize the intricacy of its implementation, it’s probably time to stop. Focus on the main plot, and finalize it to the point where any reasonable question should be answered, then move on.

Pre-Alpha

The next milestone is a long way from the previous. Pre-alpha is a stage where an entire series of plot points has been developed, and the game is stable enough to play through without major issues. At this point, your alpha testers can begin their jobs.

Pre-Alpha is internal only; although you might take screenshots and machinima videos to pump up hype for your game, no playable demo should be released. Your alpha testers need time to find all the break points in the systems before anyone else touches the game. Additionally, this is the time when limitations tend to start creeping into the scene, showing that some of the great ideas in your binder just will not function in your engine, or you were overly ambitious when it came to side quests and NPC schedules. Pare down what is unnecessary, and focus on the main plot.

Pre-alpha is generally a series of milestones, rather than a single one. You will have pre-alpha releases for each “chain” of your plot, often without linking them. Remember that even once this stage is complete, the game is far from finished.

Alpha

After each of the pre-alpha stages have completed, the main plot is basically intact. It is time to compile them all together, into a single playable alpha. During alpha, your testers will first play through the entire plot chain, making sure there are no gaps. Your developers will spend this time fleshing out the world, adding side quests and fixing bugs that invariably pop up. This is probably the longest phase, as you are going from a basic model of the game, to a full working model, with a full world to enjoy.

Bug fixes are the critical theme here. Your internal alpha testers will be finding large numbers of potential issues, and these must be addressed before continuing into beta.

Alpha often generates a lot of media for public consumption; images and videos, music and interviews, are all things that fans will want to see soon. While it is a good idea to advertise yourself and your game, be sure not to reveal anything of your major plot points prior to release.

Beta

The first beta test is an important milestone. Beta testers represent a larger group of preselected individuals, often volunteers, who will be the first people outside your organization to play your game. The larger number of testers will bring in much larger volumes of reports, most often with issues and bugs to address, but valuable feedback as well. Make sure to fix the bugs, but also listen to the people you have selected when they find issue with things in the game. Their opinions are among the most valuable contribution you can receive at this phase.

You may find some things at this point that need to be rewritten, or new side plots that require attention. As you add these, perform a brief internal alpha-style test before adding them into the next beta build. It is important to not release completely untested code “into the wild”, so to speak, as you could potentially cause issues to be missed that otherwise could be caught early.

Beta is also the stage where you may want to consider creating a playable demo for public release. This should be some small portion of the game, either at the very beginning, or created especially for this demonstration, that shows off your game’s capabilities. Consider very carefully what users will see, and how they will relate this content to the final game. If it is too redundant, they will skip forward when they get to the actual game, potentially missing important content. If it is completely unrelated, they may feel cheated, either that they played a meaningless demo or that the full game is not what they expected from their demo playthrough. The best solution could be to release a single level that is either optional, or would be considered “additional content”, for the final game. If your engine gives you the flexibility, adding the content to the final game if both are installed can increase hype for the demo, even after your game is released.

Pre-release

Once beta is done, there will be a cleanup period where programmers and scripters work far too many hours polishing the game before release. Last minute bugs will be found, and last minute assignments complete that require retesting by your alpha team. This is crunch time for developers, and has come under attack by those that don’t understand the culture of the game developer. (That being said, pay your employees people)

The “gold” copy of the game is the version that has been tested through all of the other phases, has as many bugs fixed as is possible, and has met whatever deadline you’ve been assigned. By this stage, you should be content that what is in the game is as close to your vision as possible. If it is not, you have to face a tough decision: press for more time in order to fix the game, or accept that your vision will not happen (at least in this rendition) and press on.

Large development studios will often have a release party scheduled, where they can announce that the game is complete and will be shipping soon. This can be as simple as an interview, or as complex as a stage at GenCon. We most likely will fall toward the former, but we can always hope BioWare Mythic leans to the later!

Release

The release is what you ship on d-day, through your website, Steam, iTunes or in a box. I won’t get into marketing, distribution or advertising in this post, but this is it. Everything you’ve done has led up to this. If you reach this point, congratulations! You have now outdid every effort that failed along the way, which is a significant feat. Be proud, be happy, and celebrate.

Versioning

Also known as “patching”, each milestone in this phase allows you to do a little more fixing, tweaking, and even adding, of content that you didn’t get into release. Many games now feature downloadable content (DLC), which is, essentially, the same thing except that some studios get to charge extra for it. The point, however, is that developers get to continue to improve the game for as long as users are willing to consume it. For those of you still enjoying Ultima VII under Exult, you know that can be a good long time.

That is all for the milestones of game development, at least my take on them. I’m sure many people will contend that my specifics are wrong, but I think it gives you the gist. Each milestone is important, as it marks one more step along the path of creating a game that you want; that you’ve lived, breathed and slept for months, or even years. Each one you obtain marks a point that you succeeded where others have failed, for the sad truth is that most games, most indy developers in general, never succeed. Let’s make our community one that fosters success, by helping one another reach our milestones.

Don’t you have development you should be doing?