Endless Stair Game Design Document (GDD)

From Sfswiki

Jump to: navigation, search

Green Door Games, LLC Software Engineering Document


Functional, Feature, Requirement, Analysis and Game Design Document: Endless Stair

Contents

Document Contribution:

Prepared By: Eagan Rackley

Title: Game Designer and Software Engineer

Company: Green Door Games, LLC

Document Revision:

Created on: 2/12/2011

Version: 0.1

Approved: No

Introduction:

Background (why we are doing this):

The market has proven that there's some appeal for inexpensive and fun games developed by indie teams. WhileTrueFork, LLC has invited Green Door Games, LLC to take part in a development effort to create a low-cost game that is both fun and fast to develop. The type of game being generated harkens back to days when gameplay was the only thing designers thought about, and not fancy cut scenes or endings.

The goal of the project for our team is to embrace the opportunity work with an expert on the unity platform, create a compelling game, and as usual try to deliver a meaningful or at least thought provoking message with that game.

Scope:

The scope of this document should be limited to high level design decisions associated with Endless Stair. This includes general level design, general character/behavior description, menus, and descriptions of overall system functionality. Any low level implementation decisions, sales and marketing decisions, or graphic presentation decisions are outside the scope of this document and should be specified in other parts of the wiki.

Audience:

The audience for this document is generally going to be a technically savvy individual, most likely associated with Green Door Games, LLC and/or WhileTrueFork. The technical details of the document will mostly focus on how the product is used by the player as is common in a Use Case driven development methodology.

Conventions:

This document lays out an overall design specification based on two primary analysis tools:

The use case: http://en.wikipedia.org/wiki/Use_case

The use case diagram: http://en.wikipedia.org/wiki/Use_case_diagram

Generally, this type of "use case driven" methodology depends upon use cases to describe overall systems, and then depends on analysis of those use cases to break down a system design at the code level.

The use cases in the document will intentionally include as little design specification as possible. We will also be omitting use case elements other than steps unless that information is actually outside of what would be considered shared common knowledge (e.g. Trigger: "User Turns on Video Game System" is implied, everyone knows you have to do it - so it doesn't need to be written down).

This document will generally adhere to the following layout:

  1. The Solution (e.g. Swim Fishy Swim)
    1. Solution Requirements
    2. Solution Actors
    3. Solution Use Cases
    4. Systems that make up the solution (there can be 1..n of these!)
      1. System Name (e.g. SYS1: Title Screen)
        1. System Requirements
        2. System Actors
        3. System Use Cases
      2. System Name (e.g. SYS2: Game Progress / Level Details Screen)
        1. System Requirements
        2. System Actors
        3. System Use Cases
      3. etc...


The breakout between each System allows the design to tackle small parts of the problem at a time. Use cases for the most part should be sufficient to describe game interactions, however map and character design may include mockup graphics as well.


Game Story:

Title Screen.png

TODO: I don't like the story below. I think instead of Paean there should be a legend about the stair, and that robots only try once every few thousand years (because to fail to climb the stair results in destruction, and they are otherwise immortal). Also, that no robot knows what has happened to the robots who climbed the stair before. Maybe Paean built the stair before going silent, and the robots have been autonomous ever since. So, rewrite this, and make sure we end up with something appropriately brief for text scrolling - which also doesn't sound like a 10th grader wrote it :).

NOTE: If the goal of the game is to get a higher score than other players of the game then it might be a good idea to indicate that the robot is part of a warrior culture - making death at impossible odds less of a downer since there really isn't any way to beat the stair.

Caerus - Personification of luck, opportunity, and good fortune
Epiales - Spirit and personification of nightmares in greek mythology
Homados - Personification of battle noise in greek mythology
Paean - Song or lyric poem expressing triumph or victory

Epiales is a dark and bitter world ruled by the harsh logic of great machines. The lesser beings of Epiales are forced to slave endlessly to ever expand Paean - their vast and pitiless creator. The development of these beings is advanced and provides them with the capacity to rewrite their own programming as needed to better serve their creator. Once, every few thousand years, one of them rewrites their programming with the desire to choose it's own destiny. On these occasions Paean will provide them with one of four mythical weapons of power, and bid them to climb to the peak of the Endless Stairs of Homados.

If that being reaches the top Paean promises enlightenment, and free will. If not, the scraps of that being are harvested for other purposes, and the being is no more.

Caerus had been alive for nearly 40,000 years before rewriting his programming, before deciding that it needed to choose it's own destiny. After 300 years waiting for a response, Paean has granted his request to climb the endless stairs. Paean must choose his weapon, and being his ascent to the peaks of Homados, or die trying.

Endless Stair (SLTN001):

Endless Stair Key Features:

 An important non-functional feature to consider is that while a platform based game, the focus of the game should be on fighting / 
 climbing and not falling to your death. The player should have to make a conscious effort to jump off the side of a platform to 
 his/her death.
  1. Solution shall provide a main player avatar (that optionally looks like a ninja made out of pyramids and triangles) that can be controlled using the space bar and keyboard. (SP: 2)
    1. Solution shall have avatar fire selected weapon when space bar is pressed and no enemy is near. (SP: 1)
    2. Solution shall have avatar to move using the arrow keys, up for jump/boost (down not used). (SP: 1)
  2. Solution shall provide one of three weapons to choose from at the start of the game that will affect player attacks (power ups can increase the damage these do, damage decreases):
    1. Stone - Heavy Damage but slow firing (3 levels of power up) (SP: 1)
    2. Water - Light Damage but fast firing (3 levels of power up) (SP: 1)
    3. Fire - Extremely Heavy Damage, fast firing, but hard to aim (3 levels of power up) (SP: 1)
  3. Solution shall provide a stage that is built out of platforms that are randomly placed but accessible to provide a continual play element. (SP: 3)
  4. Solution shall provide environmental elements that can be used to access platforms that would normally be out of reach:
    1. Spring boards (boost pods) (SP: 1)
    2. Platforms that can be knocked over like a drawbridge (SP: 1)
    3. Ladders/Towers (SP: 1)
    4. Moving Platforms (SP: 1)
  5. Solution shall provide numerous enemies to combat while climbing the tower that will continually increase in number:
    1. Enemies that float in from the side (SP: 1)
    2. Enemies that walk flat on the platforms toward you (SP: 1)
    3. Enemies that chase you up the platform (SP: 1)
    4. Enemies that stream in and out of platforms in a flying train (a la kid icarus) (SP: 1)
  6. Solution shall provide a dashboard capable of tracking: (SP: 2)
    1. Score
    2. Gems
    3. Power ups
    4. Health / Damage
  7. Solution shall provide drops that can be collected by the player. (SP: 1)
    1. Gems to be used in purchasing random powerups.
    2. Health power ups to restore damage taken by player.
    3. Weapon power ups to increase level of weapon damage.
  8. Solution shall periodically provide a gateway in which the player can enter to select from a random group of power ups which will cost gems:
    1. Double Jump Power Up (SP: 2)
    2. Shield Power Up (SP: 1)
    3. Weapon Power Ups (SP: 3)
  9. Solution shall periodically generate tiles that only travel to the side. These will end in a boss fight:
    1. A giant snake that jumps from below platform in arc above player. (SP: 2)
    2. A giant robot spider that fires a flamethrower like weapon. (SP: 2)
    3. A shadow version of main player avatar with the same weapon. (SP: 3)

Rough Story Point Estimate:

 Total Story Points from Key Features:     36  
 Historical velocity per point:            150%
 Historical hours/day to achieve velocity: 12
 ----------------------------------------------
 Total estimated days:                     23
 Total days per week:                      1
 Estimated months required:                6

Endless Stair Use Case Diagram:

Primary UCDa.png

Weapon System

Weapon Select.jpg

Personal tools