Ron Hiler's Plan File

April 9th, 2000

Such is the case for today's topic. I've been asked to write something about how Manifest Destiny came into being, how it has evolved into the game that it is today, what some of the interesting coding issues were, and what advice I might have for others who are in our position (independent game developers). I was going to write something up about neural nets, but this subject seems to have caught some people's attention, and it seems more interesing anyway.

That's a lot of stuff to write about, so I'm going to split it up into three articles. Today I will write about the beginnings of Manifest Destiny. Next week I'll talk about the major coding benchmarks, and finally, in week three, I'll go over what I feel are the important things for independents to know.

Chapter 1: Genisis
It might seem a bit premature to start waxing all nostalgic over MD at this point. The game hasn't even been finished yet! But it's been over two years since the idea for the game first crossed our minds, and already the details begin to fade. So if you want to know what happened, I better get it down now!

The inspiration for Manifest Destiny came from a few different places. The seed of the idea came from a conversation with a friend of mine. He is a big history buff, especially when it comes to the old wooden ship naval battles, and we were talking about various interesting naval battles that had happened (I have something of an interest in history myself). One other thing we have in common is computer games. At the time, both of us were playing Stars!. If you've ever played Stars!, you will see it had quite a bit impact on the initial design of MD. The unit design stuff in MD is quite similar to the system that is used in that game. Anyway, we got to talking about the design of those old wooden ships, how many cannon they had, how some of them began to use metal armor, that sort of thing. In my mind, the two things clicked. "If I were designing those ships, what sort of things would I have put on them to insure they'd beat the enemy ships into splinters, given the technology available at the time?".

"Wouldn't it be cool if there was a game where you could recreate history using units you designed yourself.". Thus, the idea was implanted in my head, and once it was there, it just wouldn't let go. Wouldn't it be cool if.... I'm going to talk about that phrase in a little more detail in just a bit.

At the time, R&J Cyberware was much like any other independent game design house, which is to say we'd never output a thing, but were bound and determined to produce an astounding game. We were in the process of creating a Role Playing Game, and were a fair way along creating the display engine, a 3D first person perspective affair (much like the Might and Magic games use, that I am playing now). But then two things occured to us. The first was that, RPGs were beginning to make a comeback from the major game designers (after a long absence), a bunch of good ones were coming out, and we'd likely to have been lost in the crowd if we continued with our project. The other realization was that we didn't really have the resources to do a great game, not the one we envisioned, anyway. To do such a game, we needed more people, and more money.

We decided to scrap that project (or at least, put it on the back burner). Well, now what? After some discussion, I pitched the idea of MD to our team (there were three of us at the time). It was a good project for several reasons. First and foremost, it was a great game proposal. Second, it would be simple to write, taking, at most six months to have a working game put together. And third, we had plenty of resources to do it at the time.

Chapter 2: The History of Warfare
Six months. There is a rule in program design. Take your worst case estimate, multiply it by two, and consider that your best case estimate. So, in one year or so, we ought to have had a working game. Looking back at my notes for the game, that estimate, I think, is pretty realistic.

The initial game design was mostly a database game. It's not so different from the game design we have now, but much simpler in a lot of respects. There is no mention of a spherical world. Cities were much more basic. The most difficult part of the game would be programming the database handler.

The database handler had to keep track of what techs were available to which players, what unit designs belonged to whom, and how they were designed. Where fleets were located. What the landscape looked like. Where cities were located, and what was in them. What was in the production queues, the research queues. What messages were sent to which players, and what to do with them when the player hit the "goto" button. Player to player message sending. Resource locations, and which players were getting what resources each turn. Just to name a few.

All that sort of thing is database work. We still need it in our current game, of course, but I no longer consider it the hardest part of the programming. Indeed, it's just about the easiest part!

Anyway, the working title at the time was "The History of Warfare". A fairly simple game. And then we hit feature creep.

Chapter 3: Wouldn't it be cool if....
The bane of all game programmers is that statement. "Wouldn't it be cool if". There's a time and a place for it, and different people have different ideas about how it should be used, and when you should call "feature lock", meaning no one is allowed to use that statement anymore, until the next project.

I have a somewhat different idea than most other game writers about how to use feature creep. It's a bit more risky approach. Many game writers create something known as a desgin document, which, in great detail, discusses all the play features of the game. While this document is in production, the phrase "Wouldn't it be cool if" is actively used and even sought after. But once the document is finished, they declare feature lock. Many programmers will not begin to write a single piece of code unless they have feature lock in place. There is some logic to that approach. It's safe. You know exactly what your goals are. You can program some complex stuff without fear you will have to rip it all back out again when something changes. You can create still boards, and hire your voice actors, and shoot film, if you need to, for you know you are not wasting your budget on stuff that won't be included.

My philosophy, on the other hand, is to never use a design document, as such. Rather, I let the game evolve into being. If I had design docked MD at the start, it would be a much different game than it is now. Not nearly as good, in fact. But, like I said, this is risky. You have to know when to lock down a particular bit in the game and say, "this is done, I'm not going to change it". There is a fine line you have to walk between remaining flexible and progressing with the project toward completion. In addition, this will double or even triple the time it takes to finish your game. Given that most independent game projects are abandoned long before being completed, even when thouroughly design docked, it's not for the faint of heart. To be honest, for anyone else who is not as driven as I am, I would recommend the design doc approach.

Okay, enough from me for now. Next week, the perils and pitfalls of programming MD.

- Ron Hiler (Lead Programmer)