So, about that GDD…

I’m skipping creating a game design document for several reasons. The primary one is that I can already see in my initial attempts at it that I would spend more time detailing a working game than outlining what needs to be done in order to simply make a game that works. I may end up regretting this decision later, but I think I have a reasonable alternative to go with.

A design document’s main purposes are to lock down the vision of the project and provide the details of the project so that all parties involved have one, central, evolving resource to refer to. Since I’m flying this plane solo for now*, I need to just assess what the vision is and what features to commit to.

The vision is the easy part.

Create a functioning game that meets the requirements of the challenge:

• Gameplay must revolve around shooting things.
• The game must be represented from the eyes of the player character

The features and commitment were the challenge.

I decided to make a list of what I want/need in the game and then spent a good amount of time prioritizing it. The list completely lacks detail because the depth of what we are doing here is, well.. actually, it’s an insult to the word ‘depth’ to use it in any shape, form or manner related to this project.

• original code, no copypasta served here!
• a dungeon or zone to play in
• a projectile
• a launcher
• an intro
• in-game instructions
• a user interface (UI)
• a final goal or endgame condition
• a plausible story as to why the player is doing this
• a visual gauge of progress
• basic controls to move and shoot
• music
• original models/art

To organize the list, I set up a board with four columns and labeled them – Must Do, Should Do, Could Do and Want to Do.  I then wrote each item on a Post-it and started putting them on the board, arranging them in the appropriate columns.Below is the breakdown that I came up with.

MoSCoW Chart

MUST DO:Basic move and shoot controls, launcher, projectile, dungeon/zone, all original code

SHOULD DO:final goal, original models/art, plausible story, original art

COULD DO:music, UI, gauge of progress

WANT TO DO: intro, in-game instructions

The process is my very simplified and time-pressed adaptation of what is known as “MoSCoW Prioritization.” The next step would be to assess the time it would take to accomplish each task on the board. That’s really an important step and if I had the slightest clue how long half of these steps would take, I would at least make some wild guesses here. Unfortunately, I won’t know how long each step will take until DarkBASIC and I spend some quality time together and get to know each other.

I know there’s a few items there that may cause one to quirk a brow, but there actually is a method to my madness.One of the glaring ones is UI. The User Interface is normally extremely important. Having a friendly user interface is even better. In this case, considering the email to the judges/reviewers can simply have “Arrows move, Mouse targets and fires,” the user interface can fall into the Could Do category.

Atari 2600 - Adventure

Plausible Story could probably have a much lower priority but this is just a ‘button’ of mine. Actions without context are meaningless and boring. Making a ball move to the cursor location to hit the square leaves the user asking “Why?” Firing your cannons at crates to destroy the enemy’s supplies before they get to them is more enjoyable because there is a reason for why the user is being asked to do these actions. A classic example would be Atari’s Adventure game. Moving a dot around obstacles to find keys and fight ducks doesn’t make the slightest bit of sense, but venturing out from a castle to collect treasures and fight dragons suddenly makes piloting a little square a whole lot more fun!

Anyway, tomorrow we venture out into 3D space and see what we can build. Til then… cheers!