Robert M's Blog - Project Kickoff and requirements

[RSS Bot]

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

 

CODE

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.

 

 

http://www.atariage.com/forums/index.php?a...&showentry=1467