Friday, June 10, 2011

Game Design Document

As promised, I've spent some time working on a human-consumable design document for my game. Up until now, I've had a pile of Google documents and text files that provided a nearly complete picture of what I was building, but I'm not sure anyone would've made sense of it without some guidance.

What follows, then, is a sort of high-level summary of the major ideas for the game. It leans heavily towards gameplay rather than setting and plot, since I want to get that prototyped and start playtesting it before hanging too much set dressing on it. I have a lot of ideas cooked up for setting and plot too, but how that takes shape will depend on how the game plays.

So without further adieu, I present draft one of my game design, working title NEO Scavenger.

NEO Scavenger Design Document

Gameplay Activities
N.E.O. Scavenger is a game composed of five Gameplay Activities: Exploration, Inventory Management, Crafting, Solving Encounters, and Character Development. The player practices each of the above activities in the Game World until an Endgame State is reached.

Exploration works like the Civilization V early game/exploration phase. Players navigate a hex-based map of variable terrain types in a turn-based fashion. Each hex has a movement cost, and the player has a limited number of moves per turn. Unexplored areas are obscured by a fog of war, and the player reveals new hexes as they move, depending on vision range, elevation, and line of sight. Each turn causes time to pass in the game world, advancing various conditions such as player hunger, thirst, chance of random Encounter, fatigue, exposure to the elements, diseases, and injuries.

Inventory Management
Inventory Management is the process of deciding which loot is worth taking, and finding/making space for it in the player’s inventory. It behaves like the looting in games such as Silent Storm or S.T.A.L.K.E.R. Efficiently packing loot, in particular, feels a lot like Tetris.

Loot value is subjective, and depends on the player’s situation. Loot can be valuable due to immediate usefulness, as with binoculars. It can also be valuable due to indirect usefulness, such as an axe handle which can be later used to craft an axe. Finally, it could be valuable later in Solving Encounters, or as currency.

The amount of loot a player can carry is limited by both space and weight. Space is handled via a grid system, and each item requires a certain number of grid squares. In order to be carried, an item must fully fit into the available space, and must not increase the weight carried by the player beyond the player’s carrying capacity. If there is not enough space or carrying capacity, the loot must either be left behind, or else something in the player’s inventory discarded to make space.

Crafting works in a manner similar to Minecraft, where the player can combine various items they've collected to create other items. Items can be crafted by fulfilling recipes, which are combinations of the correct skills, abilities, and requisite material components. Recipes must be discovered by the player either via Encounters, or trial and error. Unlike Minecraft, the components will likely not need to be arranged in specific visual patterns to create objects.

Recipes will support substitutions, so that items, skills, or abilities with similar properties can be used as substitutes to create the same item. Items will support quality levels, dependent on the substitutions used, and these quality levels will affect item longevity and/or effectiveness.

Solving Encounters
Solving Encounters is a creative problem solving activity. It consists of the player being notified of an Encounter, after which the player must select a Response composed of character skills, abilities, and equipment to deal with the Encounter. The Response combined with the Encounter produces a Result, which can be a change to the game world or the player. Encounters can include people, places, and things. Encounters can also include situations, which might be conditions in the game world (e.g. snowfall) or in the player (e.g. hunger). Results are predetermined by the game designer, and encounters can have many valid Responses and Results.

For example, an Encounter might say “A lone figure approaches in the distance, but does not see you yet.” One valid Response is to choose the character’s “hiding” skill, combined with a “camouflaged blanket” from their inventory. The Result would say something like “You dash from the road and hide in the trees. The figure passes, oblivious to your presence.” If the player had included both “hiding” and the “blanket” from above, as well as “binoculars” from their inventory, they would see “You dash from the road and hide in the trees. The figure passes, oblivious to your presence. Through careful observation, you notice he is carrying the following items: spear, boots, cloak, satchel.”

Character Development
Character Development consists of creating the player’s character, and growing that character over time through Gameplay. When starting a game, the player may opt to customize which skills and abilities their character has, or choose a default character. Skills include proficiencies such as hiding, lockpicking, computers, and navigation, while abilities might include night vision, technology aptitude, or harmless looking. The skills and abilities a character has increases the chances that a certain Responses to an Encounter are successful.

Players will be able to add new skills and abilities to their characters through Solving Encounters. Each time a player Responds to an Encounter, there is a chance of gaining a new skill or ability. For example, if the player did not have lockpicking skills, and was confronted with a locked door, and Responded to the Encounter with a screwdriver, they might obtain the basic lockpicking skill.

Endgame States
Play in the game continues until an Endgame State is reached. Upon reaching an Endgame State, the player’s stats are recorded to the game’s records, and the player can choose to begin another game, or view the game’s records.

Failure States
Failure Endgame States include permanent incapacitation and death of the player. The former can occur through Results such as imprisonment or paralysis. The latter can occur through Results such as starvation, dehydration, violence, exposure, or disease.

Victory States
Victory Endgame States include a list of Results predetermined by the game designer. They typically revolve around the concept of achieving stability and relative safety. Victory States include such Results as finding refuge and acceptance in a stable community or escape from the world. There will be five or more Victory States, each a bit different, to allow for replay.

The setting for the game is a post-apocalyptic, near-future Earth where supernatural activity abounds. Technology is sufficiently advanced so as to allow for things such as powered armor, hover vehicles, and (once) commonplace intra-solar system space travel, but a combination of supernatural activity and human warfare have fragmented mankind into pockets of civilization struggling to survive in wild and dangerous lands.

So there you have it! It's a work in progress, obviously. A lot of the above sounds good in my head, but without building and playtesting it, I won't know for sure. The above is enough to guide me for now, and keep me busy for a while, and I'll make adjustments as necessary.

If you have any feedback about the doc, or notice any glaring omissions, let me know. And thanks again for the nudges to get this doc going!


  1. Sounds awesome! I would just move the timeline back a bit and set it in present day. Also, make it a first-person shooter. I hear people like those. :)

  2. But what about my dragons and robots? Me want dragons and robots!

  3. Sounds interesting. I'm especially keen to see how the encounter resolution mechanic works out, rare to see an RPG that doesn't involve a combination of a fleshed-out combat system + occasional skill checks. Your way sounds like it gives equal weight to a number of different approaches. :)

  4. Yeah, that's the one I think will need the most experimenting. The other systems have been realized to some degree in other games, so I have a fairly clear idea how they can work. Encounter solving, on the other hand, could be tricky to abstract while maintaining the appearance of depth.

  5. This sounds like everything I could ever want. Keep up the good work!

  6. Thanks! Here's hoping it comes out as good as it sounds!