Overview: This article is a summary of some of the things I learned about game development as a Game Design and Development Student at FullSail Real World Education. It is meant as an accompaniment to the Developer's Diaries found in the following pages. Though extensive, these diaries serve as a journal of the entire development of a game demo. For the speed-readers, the most significant dates are 11/24, 12/8 and 12/15; these are the Alpha, Beta, and Final presentation dates respectively.

As I browse the internet, it seems there is no shortage of people willing to share advice on game development. They cover how to break into the industry, how to stay in, and in the occasional post-mortem they even tell how the game was made. Of all the various ways to convey game knowledge, the developer's diary has become my favorite. It covers from start to finish—with a few holes in between—the entire process of a game's development. I created a dev diary of sorts of my own during my final project at FullSail. Originally, the entries were scrawls of scattered comments and expletives that I typed in between builds into Notepad. The version you'll read has been reviewed by MSWord and formalized into complete sentences.

Our game, Aeons of Strife is a cross between a MMORPG and a FPS. It takes the real-time action of the First Person Shooter with the setting and combat elements of the Role Playing Game. In the three months that the four of us we worked on the project we found a lot of things out about ourselves, as well as the game development process.

On Documentation

In the beginning there was the Design Document, and it was good. A good design document is the basis of a good game. For the veterans out there reading this article, that statement is probably nothing you haven't heard before. With that said, there are many people, newbies and oldbies alike that do not heed that advice. Our DD was not limited to just the look, but the feel of the game as well. In order to keep a game consistent, everyone's vision of the game has to be consistent from beginning to end. A game charter and a game vision will help remind you of what kind of team you were when you first started developing; before the arguments, before the unhandled exceptions (or segmentation faults for you Unix coders), and before everything in general became stressful.

Change is Constant

From day one, the game is always changing. It will continue to do so until the day you burn the Gold CD or start on the sequel. In my experience, there were two primary reasons for why that was known to happen.

Of the two, the first is technical realization. This is when the idea or concept for a certain module doesn't work, doesn't work as fast, or look as cool as it was supposed to do. The failure of one module does put a stop to an entire project if it has adequate technical and design documentation.

My second major reason for why games change is a term known as feature creep. It is a common term in gaming, used to denote how often additional gameplay elements creep their way into a project.

In my experience, "Wouldn't it be cool if…" is easily both the most ominous and auspicious phrase in all of game development. It can be the start of such sentences as "Wouldn't it be cool if Samus and Kirby fought to the death?", which is the premise Super Smash Bros. This is a game that breathed new life into the fading Fighting Games genre, and has spawned one sequel thus far. Contrastingly, "Wouldn't it be cool if we made a game about that new Spielberg movie with the alien?", is a phrase that I'm certain someone now regrets having said.

Feature Kill

On a related note, there is another term I have become accustomed to, and that is feature kill. It's what happens when you know you have a time limit for a project and want to keep it from getting bloated with unnecessary features. To elaborate, if feature creep were a creature named feep, feature kill would be the shotgun that shoots it dead. As a result of feature kill, you may end up killing off an exceptional feature that just might have made the game for your target audience.

In the case of our game, two of the three key gameplay features that we received the most praise for in our game were scheduled in after our Alpha milestone. In general, your first priority when developing a game is to maximize the funativity for the consumer. It is also your responsibility to know that with each new proposed feature the expected risks and rewards to both team and consumer must be weighed and a decision must be made.

There is a strange interdependent relationship between artists and programmers. Some people see them as the guys down the hall (in the case of FullSail, they were across the room), and I would imagine the inverse is true as well.

Two Different Worlds

Programmer types and artistic types are based in the left and right hemispheres respectively. Separately, the work of an artist is something that can be seen or heard but not interacted with, and the work of a programmer is a series of nonsensical words. In the game world, these two hemispheres come together to make a finalized product. The person that serves as the interface between the two worlds has to know that fact and reinforce it in the people he works with accordingly.

A Good Team is Hard to Find

Finally, a good game is nothing without a good team to develop it. Codus Vivendi was a very balanced team of four. We each had a specific interest in a different part of the game (Engine Mechanics, Physics, Networking, etc.); for that reason, when it came down to handing out responsibilities for the game there was little think about. Working on something you believe in makes you work that much harder. That applies to both the code we wrote as individuals, and the game as a whole.

Diary: To Alpha