Ron Hiler:
March 4th, 2000
March 8th, 2000
March 14th, 2000
March 26th, 2000
April 9th, 2000
April 15th, 2000
April 29th, 2000
May 15th, 2000
July 14th, 2000
March 25th, 2001
January 22nd, 2004

The Preparation of an Alpha List

The question has come up a couple of times as to how I organize my work. What is the process under which the games are designed and implemented? How do I keep things on track? I'm in the process of designing the next alpha list for Sovereignty now, so I thought I might spend some time and talk about it. Since I'm am working on the next Sovereignty list, I'll probably primarily use examples from that game, but the methodology I will be talking about applies equally to any game I would work on.

I'll tell you right up front (and many of you already know this about me) I rarely used design documents. This is not a methodology I would necessarily recommend unless you have a very clear view of the game you want to build and have particular nature (you have to be well organized, willing to work through mistakes, and I think stubbornness must be a big part of it, heh). A design doc is meant to be a roadmap that you follow in the course of programming your project. They go over in detail every aspect of a project as far as the code work goes (what classes you'll use, what functions belong in those classes, what the important member variables are going to be, and so on). I actually do use them for contract projects, but never for games (well, almost never, I sometimes will design doc a particular subsystem if it's very complex). There are many programmers who will tell you that you must design doc to completion before writing a single line of code. For some people, this is true I suppose, but for me, it's bunk.

The thing about design docs is that they assume you know how to do a task from start to finish before you even start the programming. This is certainly possible to with my contract work, which tends to be much, much easier than the games. However, for games, if you don't learn new stuff while programming them, what's the point? I had no idea how to code a model animation system three months ago. A year ago I was pretty clueless on socket programming (that part of the code that controls our networking). Just to name two of many.

In order for me to have design docked Sovereignty, I would have had to have intimate knowledge of both those systems, as well as a whole host of others. To me, it's the height of arrogance to assume you can, on paper, completely design the code base for a game before writing any actual code. I often have to be able to see what works and what doesn't in practice to figure out how some class or other gets organized. There is no way I could do that on paper with any level of accuracy. But that's just me.

Now some would call it foolish to start a major project if you're not sure you intimately know all the code systems you're going to use. However, I have no fear on that respect. I've never met a system yet I couldn't study and research my way into learning when I need to, and I've researched some pretty damn complex ones (Winsock IOCP for instance, or Direct3D for another). There are those who would call this equally arrogant, the idea that I can learn any system I need to on demand while coding a complex game, but it works for me just fine. Sure I stumble around a bit at first, but I have a firm belief that both the systems coded and the knowledge to code them build upon each other in successive layers, and you can only get to the point of expertise by jumping in and using them. By the time I'm finished learning a system, I have it working in game exactly as I first intended. This won't be efficient for everyone, but it's the way I code, and it works for me! Besides, I think I've probably learned all the really complex ones I will ever need for games at this point (until they come up with new ones anyway), with the rest being relatively easy (I'll exempt AI from that statement though, which is another tough nut to crack, but I've had some luck with neural nets in the past, so I've got a pretty good start there already).

There is a downside, however. Without a design doc, it's easy to get lost in the complexities of the details. You have to keep in mind your original game intent. While it's okay to let a game evolve in some respects, you have to keep to your initial vision, or you're never going to get anywhere. And you should always strive to keep moving relentlessly toward that vision with every build.

For that reason, I do put together lists. They're not design docs in the traditional sense, but they do allow me to stay on track and advance forward toward the vision of the game. They don't go to the end of the game coding, but rather go to a certain point (they accomplish a set of specific goals). I guess you could call them milestones (programmers have a term for everything, hehe). When designing such a list, you keep in the very front of your mind the game vision. Then, when implementing the list, you can lose yourself in the details without worrying about straying from the vision path, because a properly designed list will keep you on this path despite yourself.

So how does such a list get created? I have a process for this, which has evolved over time. I wouldn't exactly call it a formal process, but its close. It goes in a series of stages, which I'll categorize here. In reality, the timing of these tend to overlap a little bit with each other, but they certainly don't have to.

In Stage 1, I take a careful look at the game at the state it is currently in. I ask myself what can be added at this point to get us closer to the game vision. This is, you understand, in a very broad sense, and always with a keen eye on the game vision (this is very important, especially at this stage, which is why I keep stressing it). Very often these come in the form of "It would be cool if we could do "x" by the end of the next phase". In the Alpha 6 list for Sovereignty, for instance, adding a persistent inventory (that is to say, items that would stay on your character when you left the game and would come back with your character when you logged back in) was on this broad list, as well as item generators, a number of interface screens, access to all five of the character slots, and a fair number of others. At this stage, no thought is given to how these are implemented or how they are ordered, other than in very generally to make sure we are ready for them (things we are not ready for are rejected at this stage, such as combat in A6, which had too many systems it needed to build upon which haven't been put in yet). Some items are added that sometimes aren't immediately useful but which will be in later phases (a particle system is in the works for A6 for instance, which will be used for magic and other special effects later on). In such cases, I often try to find some way to use them anyway, even if it's temporary or trivial. It's nice to have all our working systems in actual use at the end of a coding phase. Usually at this stage I will also ask for feedback from the testers on what they'd like to see on the list, and where I can, I'll add those requests on. Generally speaking, the size of this stage 1 list is roughly 40 items. I can do this part of the list in two or three days, although I will allow much longer than that for tester feedback before moving on to stage 2. This part of the list is typed, because I actually type faster than I can write, and there's not really much in the way of thinking involved. These are more gut reactions to what the game needs in terms of broad goals, not well thought out step by step items.

Once I know the general things that need doing in next phase, we move on to stage 2. Here, I take each item from the first stage and break them up into specific steps. Interface screens are actually designed, and the individual steps needed to get that screen up and running are written down. For instance, the character creation screen for Sov's A6 was designed (graphics – male and female buttons, add male/female buttons to window, make them mutually exclusive, add name input box, add characteristics, graphics – up/down buttons, add up/down buttons for each characteristic, add characteristic pool, set starting level of characteristics, and so on). As you see, I start to get a general idea of the graphics I will need for the build, as well as the order that we need to go in for each item from the phase 1 list. This phase 2 list is always written by hand, so I can scribble notes and add arrows and even draw rough versions of the interface screens. Also, usually, each item from the phase 1 list gets its own separate page so I have plenty of room to add list items and make all my notes. Sometimes I'll group some of the more trivial items from the phase 1 list onto one page, but usually the phase 2 list runs a good 30 pages or so, although often many of them are nowhere near full. This is the stage where I tend to take a long time, because it is here where you want the steps to be as trivial to program as possible, and that's often not very easy to accomplish. It is in this stage where I do a lot of preliminary research (as another for instance from the list I am doing, we are getting a skydome in A6, and I've already done some research into how to tessellate the dome). By the time this list is done, it is getting close to its final size, which lately has been around 300 items or so (my last list A5 was almost 281 items, and the A6 list looks like it will surpass that). Allowing for the growth to be expected in the next three phases, if at this point we are around the 200-250 mark, it's about the right size.

Although the list at this point is pretty close in content to what it will be in its final form, it's still not of much use to me. The next step, phase 3, is to start breaking down the list items by program (Sovereignty) or possibly by class (Manifest Destiny). In Sov, there are already in A5 a fair number of different programs. There is the Launcher, the Client, and the Server, of course, but also the World Editor, the various databases and a few supplementary programs to help organize the data within the databases into useful information. I go through the scribbled phase 2 notes and make notations as to which program a particular item belongs to. Sometimes this will result in the list growing a bit, as (for instance) a list item could affect both the Server and Client code base. Hopefully this doesn't happen too often if I've done my job properly in phase 2, but from time to time this categorization exposes places where the steps haven't been properly dissected. I can generally expect the list to grow by as much as 10% in this phase. I also take note of the 2D and 3D graphics that will be needed for the build.

Once that's done, we move into phase 4, which is ordering. You'll remember in phase 2 we ordered on a "per phase 1 item" sort of way, which is a rough ordering. However, in many instances, even items on the phase 1 list depend on previous phase 1 items. Hopefully by the time we hit phase 4, it is very obvious where the dependencies lie, and we can start ordering the phase 3 list into its final form. I do this one on the computer because this is where I start putting together the final list form (which very definitely needs to be typed). First I divide the page into its categories (server, client, launcher, world editor, 2D graphics, 3D graphics, Databases, other admin programs, and three packet types (general, launcher, and client, more on these in the final phase). Then, every item in the phase two list gets enumerated under this "filing" system. They are listed in the order they are meant to be implemented under that heading, with dependents being listed after dependees. Now, very often, an item in the client will depend on something being done in the server first (for instance). I don't make any particular notation for this. If I'm working through the client list and hit a point where I can't do the next list item for lack of something being done in the server, I'll just switch over to start working on the server code. Quite often, the lacking item will be the next thing to do done in that category anyway, or at least close (if I've done the ordering properly anyway it should be near the top). Usually the various categories are being worked through in an interleaved fashion in any event. Again, from time to time, I will see an item that could be further broken down as I'm doing the ordering, and I'll add in the extra items. This is relatively rare though by this stage and the list should grow by less than 5%.

There is one final stage, which are the packets (this part only applies to real time networked games, of which Sov is the only one I've done, so we're now specific to that game only). Now that we have a complete and ordered list of everything to be done, it's pretty easy to pull out where the Launcher and Client need to communicate with the Server (or visa versa) and add a list item in the packets section describing the new packet type. I don't list packets under the Server (since both the receiving and sending program have to deal with the same packet, it's redundant to list them both, so I only list them by Launcher or Client (or sometimes General)). Now our major packet handling was done in A5, so I don't expect to have nearly the same level of new or modified packets in future builds that we had there (there were over 50 packet types in total in A5). Even so, another 30 is not unreasonable to expect under A6, with it dropping off more after that. So the list grows again by another 10% or so.

And that's our final list! I probably will go over it one more time with a fine tooth comb, perhaps add one or two things, or shift some orders here and there. Once I'm happy with it, it gets saved and printed and that's the list I work from. The list for A5 was 4 pages (two columns per page). I expect A6 will be similar, maybe 5 pages. This is not to say the list can't change during development (the A5 list was revised a couple of times during its life span), but no extra work should ever be added. Revisions should be limited to changing ordering or further decomposition of list items into more items (e.g. break them down into more trivial steps). If you want to add work, do it in your next list. Otherwise you run the risk of losing focus again.

At the end of the coding phase of the list, what you should end up with is a program which is much more game-like than it was at the end of the previous coding phase, and much closer to the original game vision. Of course at that point, you move away from detail oriented and go back into general vision mode and start the process all over again making your next phase list.

Ron Hiler
January 22nd, 2004