OC Development Methodology (part 1)

You will find that I blog mostly to get ideas out of my head. Writing tends to be therapeutic for me, a way to hash out ideas or concepts floating around in my head into some sort of concrete form that I can work with or ignore. It also helps me remember and find focus. This is one such post (of many to come).

My software design and development approach always starts with the end goal, which in this case would be to create my dream game – a massive multiplayer online role playing game – Omega Connection Online. I know my limitations though, both in time, money and experience. I have, after all, never created such a massive online game, nor do I have the finances to fund the required server farm, support team, internet connection, etc. Instead we’ll take steps to get there through sub goals. That isn’t to say that I won’t throw up the random idea for OCO, but I will be doing so with the thought of shaping those sub goals so that it is in line with the end goal.

What are those sub goals? The first step back from the end goal of OCO would be a multiplayer version on a smaller scale. Perhaps 4-6 players on a LAN through client-server style setup. I’ve created such programs before so it is not out of the realm of possibilities at this point. A little custom udp/ip data transmission between client/server and Bob’s your uncle. Except for that whole client piece of course, the game itself. A tiny step back then would be the single player game Omega Connection. And that is what I have started creating.

The goal of creating OC requires breaking it up into smaller bits and those into even smaller bits. This is my design style for software, a top-down approach. Mapping everything out in this manner allows a bottom-up approach for development, a concept I hope most developers are familiar with and make use of to some degree. To start with, on the single player game there needs to be a definition of the overall game, in this case a 3D first person medieval fantasy style adventure game. This actually comes from Omega Connection Online via inheritance (see, all those words you learned programming come in handy elsewhere).

The game definition requires a story line, or else why would you be playing it in the first place? I covered that in my elevator pitch introducing the game. The story line requires sub stories and/or quests. Both of which require actors (npc characters), events and places. These things require screen writing, artwork, sound effects and voices.

The game definition arc of creating the video game leads to the software side of things. In order for a person to wander a land, meet strange and exotic beings and kill them there needs to be a method to make all this happen programmatically and present this on computer screen. This is called the game engine by many developers. We obviously need a game engine. This is where things get a little tricky because the first rule of creating a game engine is to NEVER create a game engine. Instead, continue with the top-down approach and create the programs and algorithms that are needed for your game.

At its simplest the game engine takes user input and displays corresponding output on the screen. This is the basis of any piece of software. In the case of OC, the user input corresponds to movement and actions taken on the land, objects and denizens of the world and displays the results, whether it is day turning to night or a creature coming into view, on the screen. We’ll call these parts the user interface and the rendering engine. For the time being we will say the user interface consists of keyboard and mouse. For various reasons I have decided to code the rendering engine using OpenGL which will display onto a screen.

Wait! We mentioned land, objects and denizens. Where do these come from? As denizens and objects require land to inhabit, that seems like a good starting point. In smaller “world” games the landscape is often created by hand from grassy fields to forests to villages. In games utilizing larger areas the landscape development could take longer for a team than creating the entirety of the rest of the game. For that reason, many game devs use some sort of terrain creation engine to dynamically layout all the hills, fields, mountains, forests, etc. A few lucky people get to go back into this computer generated map and tweak everything to ensure it conforms to what they need as well as to add in many other locations such as buildings or landmarks.

By the very nature of Omega Connection, this tedious task of tweaking landscapes is not desirable or even feasible. Omega Connection needs a generation engine because the computer MUST create the land from the largest mountain to the tiniest flower, as well as flattening terrains and dropping in buildings, towns and cities plus roadways to connect some of it together. While this is definitely feasible, there is one big gotcha that the manual tweaking is designed to try to catch: landscape traps. If you have ever played a 3D game and got stuck in a spot where no matter how much you jump, duck, crawl or run you cannot escape, you have seen such a landscape trap that was missed by the terrain tweakers. The generation engine could be written to look for these traps, but it will become a development decision based on the tradeoff of processor cycles (and thus slower gameplay) versus the annoyance of loading a saved game. Only time will tell on that front.

Now that we have land, we need inhabitants. We throw in a scattering of random characters, animals and creatures all of whom stand there dormant and are effectively fleshy trees. Fun game, eh? This is where Artificial Intelligences comes into play. For video games, AI ranges from simple path-finding algorithms to flocking algorithms to learning algorithms, all with the goal of making the denizens seem more real. Some things are relatively easy, such as portraying the realism of a school of fish utilizing flocking, while others are much more difficult, such as portraying humanistic behavior and combat actions. Humans are of course the most difficult for any game, as no one really knows how a dragon behaves, but everyone has some idea of what is human action and what is not.

That is not to say that all humans in a virtual world would require the same level of AI complexity. A tavern keeper really does not require the dynamic range of actions as a warlord. Additionally, not all entities require the same level of AI all the time. A warlord moving across the plains only requires a minimally processor intensive path finding algorithm, while one moving with army in-tow might use flocking, but in combat you should expect that warlord to behave a bit more intelligently. Alternatively, a ranger tracking across those same plains should behave more deliberately than the warlord. To bring this level of realism to life, without bringing processor cycles to its knees, Omega Connection will require multiple AI programs, each limiting the number of entities it controls based on a cost and priority system, and all sharing data between one another as needed to create a single AI engine.

This seems like a good overview level for breaking down the goal of creating the game, as any further along this track starts into tasks. It also seems a good spot to break up this post. Up next: plots and quests…