Project Kickoff and requirements

1K minigame 2006

Entry posted by Robert M April 14, 2006

446 views

Okay, so I have less than a month to complete an entry for the 2006 minigame contest in the 1K category. They sure set that deadline early this year. Oh well, If I miss it, then I guess I'll just have to enter it next year. My game idea is a sword fighting themed game with a top down interface. The player myst kill all enemy warriors in the current room and then proceed to the next. There are 8 rooms with progressively harder enemies to defeat. The backstory is the player was betrayed and left for dead. Now he is back seeking revenge. I have drawn up a software requirements document for the game. It is not great, but I think it will be adequate to get through the design stage and most of the coding in short order. The main point of writing the requirements down was to clarify my thoughts on the game and list all the key aspects of the engine that I need to take in to account so that I don't need to do much backtracking later on. I have including my requirements below if you are curious.

Cheers!

Rob

Software Requirements Document

This document shall capture the requirements for a simple atari 2600 video game.

Backstory Summary:

You are a warrior, betrayed by your best friend and left for dead.  Now you
have returned for revenge.  Fight your way through 8 rooms of enemies to face
the traitor in mortal combat.


1.0 Title:
The name of the game shall be limited to six characters to allow it to be 
drawn on the screen with 3 sprites.

1.1	Proposed working titles include "Grudge, "Hatred", "Return", "Animus".

1.2 OPTIONAL:  The opening screen of the game shall display the title using
	the 3 sprites normally allocated for enemy warriors.
	1.2.1 OPTIONAL: If there is ROM space left, consider doing somehting 
		with the missles to spruce up the title screen.

2.0 The game shall fit into 1K of ROM memory to meet the requirements of the
2006 minigame contest.

2.1 To meet this tight memory requirement, several requirements in this 
	document will be prefaced with [OPTIONAL] to indicate that they can be
	eliminated to meet requirment 2.0

3.0 Description of display.
3.1 All screens in the game shall use the same display engine/kernel.
	3.1.1 The display is divided into 2 regions.
		3.1.1.1	The larger region on top is where gameplay action is
				drawn, and shall be refered to as the room.
		3.1.1.2	The smaller region shall display a life bar for the player,
				and shall be referred to as the status bar.
	3.1.2 Symetrical PF graphics shall be used throughout.
		3.1.2.1 The room region of the screen may contain obstacles made of
				PF graphics.
	3.1.3 Draw sprites P0 and P1 once per frame to any height which is a power of 2. 
		3.1.3.1	The display engine shall use a bit mask to determine if the
				sprite should be rendered such that a staggered rendering of 	
				a sprite is possible to create an explosive death animation.
	3.1.4 The M0, M1 and Ball objects shall:
		3.1.4.1 Be drawn once per frame.
		3.1.4.2 The height may be 1, 2, 4, or 8.
		3.1.4.3	The width may be 1, 2, 4, or 8.
		3.1.4.4	The object may be skewed 0, .5 or 1 pixel every scanlines
				to create a line segment at 0, 22.5, 45, 57.5, 90, 112.5,
				135, or 157.5 degrees.  Where, 0 degrees is a vertical line.
				These angles (when reflected) map to 16 compass directions
							   used for control throughout the game.  Skewed missles and ball 
				will be used to draw the swords in the game.
				
	3.1.5 The room region shall have an outline of a rectangle made with PF
		  graphics.  The top and bottom lines of the room rectangle shall
		  show the suggestion of a doorway.  
		3.1.5.1 [OPTIONAL] The doorways are made with recycled sprites
					  to allow a different color door than the wall.
		3.1.5.2 The top door shall have the ability to be rendered as being
				either open or closed.  The bottom door is always rendered as
				closed. 
			3.1.5.2.1 The top and bottom wall bands shall be 6 scanlines high,
					  and the door shall be drawn in the 2 middle  scanlines.
		3.1.5.3 The open interior of the room rectangle shall be no more than
				128 pixels wide, and 160 scanlines tall.
	3.1.6 The status bar shall be 128 pixels long. and shall have an indicator
		  object in the form of a sprite or missle to indicate the present
		  health of the player.
			  3.1.6.1 The status bar region shall be 16 scanlines high.
			  3.1.6.2 The bar shall be red in color and shall occupy the middle
					  eight scanlines of the region.
	3.1.7 The game play shall run at 30Hz allowing up to 4 sprites and 6 missles/ball
		  instances to be active at the same time. 
					  
4.0	Game flow:
4.1 On power up the game shall initialize and play will begin in Room 0.
	(see room descriptions below)
4.2 Pressing and releasing reset shall cause the game to return to the power
	up initial state.
4.3 When all enemies in the current room are destroyed, the door at the top of
	room shall open.
		4.3.1 Should the player sprite touch the open doorway the gameplay 
		 	  will proceed to the next room.  
4.4	Room 0 and room 9 shall contain no enemies.  Exiting room 9 shall return
	player to room 0.  
	4.4.1 Room 0 is the title screen
	4.4.2 Room 9 is the victory screen.
4.5 Rooms 1 through 8 will have a set of 1 to 3 enemies of increasing strength
	for the player to defeat.  Details are to be explained below in section 6.0

5.0 Control
5.1 The player shall control a warrior sprite using a joystick plugged into
	the left joystick port.
	5.1.1 Pushing the joystick left or right shall cause the player to rotate left
	 	  or right through 16 facings.
	5.1.2 Pushing the joystick forward will cause the player to move in the direction
	 	  currently faced.
	5.1.3 Pulling the joystick backwards will cause the player to move opposite
		  the direction of facing.
	5.1.4 Pulling back and pushing the button shall place the player in the defensive
		  stance.
		  5.1.4.1 While in the defensive stance the player can not move forward or back,
					but rotation left and right is still enabled.
	5.1.5 Pushing the button without pulling back on the joystick will begin an attack
		  by the player.
	5.1.6 If the player is pushing diagonally, then the left or right action shall be
		  applied before the forward or backward motion.
5.2 All game objects will have a speed value.  This value will be added to a remainder.
	when the remainder overflows 8-bits, the object state is updated to reflect the current
	control input and previous state.
	5.2.1 Different speed constants will be applied for PAL and NTSC to create equivalent
		  gameplay velocity.

6.0 More Detailed rules of combat.
- The player's goal is to slay all enemies in each room.  The enemies become
  stronger and more numerous as play progresses.  The number and strength of
  enemies can be expressed as a binary number corresponding to current room
	
	Enemy  =  DCBA -> A set bit in the room number means that enemy is present.	
	Room 0 = %0000 -> Opening screen. no enemies
	Room 1 = %0001 -> Enemy A
	Room 2 = %0010 -> Enemy B
	Room 3 = %0011 -> Enemy A and Enemy B
	Room 4 = %0100 -> Enemy C
	Room 5 = %0101 -> Enemy A and Enemy C
	Room 6 = %0110 -> Enemy B and Enemy C
	Room 7 = %0111 -> Enemy A, Enemy B, and Enemy C
	Room 8 = %1000 -> Enemy D (Final Boss)
	Room 9 = n/a -> Victory screen (special case)
	
- The enemy and player warriors share common characteristics of Speed, Life, and 
  Power.
	  - Speed determines how often the warrior and corresponding sword are updated.
	  - Life, when life reaches zero the warrior dies and is removed from play.
	  - Power is the amount of damage the warrior does when an attack lands
	  
 - The table below is a proposed set of values for Speed, Life and Power
   for the player and the 4 enemy warrior types.  These numbers need to be
   fine tuned with actual play time, and they need to be made proportional
   for NTSC and PAL versions of the game.
   
   				Speed	Life	Power
   	Player		128		128		32			
   	Enemy A		96		64		8
   	Enemy B		112		96		16
   	Enemy C		128		112		24
   	Enemy D		144		128		32
	
- TBD (The action of swinging a sword, blocking an attack, and counter attacking
	shall need to occur over many frames with the time for each frame of action to 
	complete being controlled by the Speed attribute of the warrior.	We want
	the number of frames to make the game move at a good but manageable pace.  
	This work is slated to be done later once the main engine is up and running).
	
7.0 Scoring
7.1 There is no score except the life bar level of the player upon completion of the
	game.

8.0 Sound
8.1 The following sound FX shall be needed
	- A whooshing sound for the swinging of a sword.
	- A metallic ding sound for when an attack is canceled
	- A thud sound for when an attack hits.
	- A death sound when an enemy or the player dies.
		
9.0 End Game:
-	When the player defeats the boss in Room 8 and exits into room 9, then the 
	game is over and the player has one.  T
	- 	The game shall indicate victory with either a short message like "Victory"
		rendered in sprites and missles, or simply flash COLUPF.  
	- Room 9 shall have no door at the top.
	- The game shall remain in room 9 until reset is pressed.
- The game will end if the player's life bar falls to zero.  The player sprite
  will have an animated death.  The game will remain on the existing room until
  the player hits reset.