Fighting Game: Working Title

Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Fighting Game: Working Title
Detailed System Design Document
Programming Notes in Red
Created By:
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
Høgskolen i Østfold – DMPro – Game Programming – Halden 01-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
Fighting Game: Working Title
1. FRONT END
Title Screen
We will use an animation movie clip (time dependent) as the introductory cinematic. Clicking the
mouse on the game window with a MouseEvent.CLICK anywhere on the stage forces the Title Screen
forward to the Start Screen. No action by the player allows the cinematic to play through to
completion, then shows the Start Screen. The easiest method to achieve this would be to place the Start
Screen as the final frame of the starting cinematic, and have the mouse event click cause the animation
to gotoAndStop at the Start Screen.
Start Screen
This screen will be the final frame in the opening cinematic movie clip. It will have several clickable
elements utilizing MouseEvent.CLICK, primarily being Start Game and Level Selection.
•
Start Game
Selecting this option begins the player on the first level. This can be accomplished by calling
the first level's movie clip animation with a gotoAndStop and then a play along that portion of
the timeline.
•
Level Selection
Selecting this option brings the player to a new frame with a dynamic text box. Upon
completion of a level the player will be granted a code to later continue their progress. Entering
that code correctly into the text box places the player along the timeline according to the code
they entered.
•
Character Selection
Upon selecting Start Game or Level Selection the player will be prompted to choose a character
they wish to play during the gaming session. Each character will be selectable via a
MouseEvent.CLICK, then the player will proceed to the previously selected level. The order of
Level Selection and Character selection may end up being reversed if it becomes logical to do
so.
2. GAMEFLOW
1. Front End
2. Start Game
3. Levels
• Defeat your opponent before they defeat you.
◦ Pressing an attack key causes the animation to play with a key event. While the
animation is playing a hit test occurs to check whether or not the opponent was hit by
the attack. Upon a successful hit, the opponent's health bar is reduced. The first player
or computer player to reach an empty health bar loses.
• Each level must be completed to move on to the next. (Optional: best 2 out of 3 fights wins
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
the match.)
4. After successful completion of a level a code for level progression will be provided should the
player wish to continue playing at a later date. Completion of a level allows progression to the
next level.
5. Boss Fight
• Upon completion of all the levels in a world or zone, the player will face the “boss” of the
zone who also must be defeated before moving on to the next zone via the in game map.
◦ The boss should be more difficult to defeat, by tweaking its movement, the power of its
attacks, etc.
◦ The map's progression is linear, showing the player they're progressing but not allowing
for selection between fights.
6. Completion of all levels presents the player with a congratulatory message and credits.
3. GAMEPLAY
The player plays through Single Player progressive levels with increasing difficulty, each with a time
limit of approximately 2-3 minutes. The goal is to defeat the computer controlled opponent before the
player is defeated. If the timer runs out before a knockout is achieved, the character with the highest
health will be considered the winner.
•
Pressing an attack key causes the animation to play with a key event. While the animation
is playing a hit test occurs to check whether or not the opponent was hit by the attack. Upon
a successful hit, the opponent's health bar is reduced. The first player or computer player to
reach an empty health bar loses.
The player plays as one of 12 selectable characters (dependent upon time) through the game world,
attempting to prove themselves the best fighter by winning each match. The opposing characters will
consist of every character that could have been selected by the player, plus 3 additional bosses. The
goal is to defeat every character in the game, thus proving yourself to be the best fighter.
4. GAME WORLD
The Character
The Character is the conduit with which the player interacts with the game world. The player may
select which character they would like to use upon selecting a new game or Level Selection.
•
•
Each character will have a set of moves specific to that character, including a punch, kick, block
and a special move.
Time Dependent
◦ 12 characters are available for play.
◦ Whether or not the character can jump or crouch.
◦ Whether or not the character can dodge and cause the background to move (very unlikely
with time available).
◦ 12 opposing characters and 3 bosses.
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
◦ One character will be fully animated and programmed to begin with, facing his “evil twin”
basically a direct copy of the same character. Once that is in place, more characters can be
added into the mix for playability. This should allow for game scaling.
•
All characters will be developed in ¾ profile.
Figure 1:Example Character
The Fight Area
The Fight Area is a horizontal ¾ top view section of the background. The characters move back and
forth along that horizontal plane, never leaving the plane. Jumping or crouching will not move the
character off of the single horizontal fight area plane.
(This may be expanded to a more Super Smash Brothers style of play, with platforms and double
jumping. In this case jumping will have a velocity and a varying start and end points.)
Background
The background is designed to be mildly dynamic (with enough time). Ideally when the player moves
to the left the background should shift slightly to the right, giving the impression of three dimensions.
• This would be achieved by the movement button not only moving the character when the key
event is activated, but also shifting the background's x value in the opposite direction.
Despite this effect, the player will not actually be able to move past a predesignated stopping point,
they will run into an invisible wall preventing them from moving off the play screen.
• Walls will be put in place, and the player character and computer character will perform hit tests
on those walls, and be placed back into the previous position if they attempt to pass them or
move inside them.
With exceptional time management the illusion of 3D could be achieved by the player dodging the
opponent's move, and the background being created in a full 360 degree circle, shifting to either side
upon a dodge causing even more 3D illusion.
• This is only a viable scenario if we don't choose to change to a platform style gameplay. More
than likely this will be discarded.
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
Figure 2: Example Character and Fight Area / Background Concept
Opponents
The opponent is a computer controlled character, the game is single player only.
Each opponent will have the same base set of abilities as the player character, as they will be one of the
characters the player was able to choose from after selecting their game. More opponents may be
added into the game for scalability. Opponents will attempt to win the match by defeating the player
character before they themselves are defeated.
See AI section for more detailed information on opponent functionality.
5. POINT SYSTEM
As the player fights their opponent, successful attacks remove the opposing character's health. When a
character is reduced to zero health they're considered the victor of the match. If the time for the match
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
runs out and neither character has been reduced to no health, the character with the most health
remaining will be considered the victor of the match.
• Hit tests upon key event attack animations determine whether or not the hit was successful. A
successful hit removes a portion of the opponent's health bar, and does a check upon the
remaining points left in the health bar. Upon reaching zero health for either character, the
match is completed.
• The timer will be in a dynamic text box without the ability for player input. Upon reaching
zero, the two health bars will be tallied. Whichever is larger (checked by an “if” test) will be
announced as the winner of the match.
Time Dependent
• Multiple matches per opponent, best two out of three to decide the victor.
◦ Would be possible using another dynamic text box. If test of i <=2 in that box would be
checked prior to the ability to move on to the next fight, or the next frame in the
animation.
Power Ups / Combinations (Time Dependent)
A series of attacks in combination without interruption produce a special super attack dealing
significantly increased damage to the opponent.
• Not entirely sure how to implement this. Will probably be something we choose not to do
unless we're completely finished with all the other game aspects.
6. CONTROLS
The player uses the keyboard to control their character.
• Each key will be bound to a keyboard event. Attacks will be a one time press for full
animation, movement will be press to move, release to stop.
W – jump (Time Dependent)
A – moves the character left
S – crouch (Time Dependent)
D – moves the character right
F – block
J – punch
K – kick
L – special move
The game only recognizes one offensive keyboard activation at a time. Rapid sequential activations are
recognized, however simultaneous activations will not be recognized until the primary activation in the
sequence has been completed and is no longer activated on the keyboard.
• Should be able to create an “if” test to check whether another offensive button is being pressed,
if so, the moves cannot coexist.
The exception to this rule will be the addition of jumping and or crouching to the game, the player may
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
attack and crouch or jump, however they may not punch and kick at the same time, or block and attack
for example.
Players have the ability to strike their opposing targets along with missing entirely.
• A successful strike removes health from the opposing health bar, and causes the opponent to
“flash red” showing the player that a hit has been achieved.
◦ A final frame will be added to each animation with a red tint to the animation, which will be
played upon a successful hit.
Missing a target still causes the character to strike. Nothing positive or negative results from the
missed strike other than the player losing the time the attack animation takes to complete before the
next strike can be made.
Camera System
The camera is fixed in a third person view. The camera angle is not adjustable by the player, and will
remain in position despite the illusion of movement due to the background shifting.
7. USER INTERFACE AND IN-GAME MENUS
Figure 3: Example User Interface
Continue to Fight Map – available when a player wins a match against an opponent. Will bring the
player to the fight map and their next battle for supremacy. Will appear over the play area along with
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
Quit Game.
• Could either be a new frame with mouse event click elements leading to other frames, or some
sort of a pop up box appearing as it's own symbol.
• Will take the player to the correct frame of the fight map on the scene.
Retry – available when a player loses a match to an opponent. Will appear over the play area along
with Quit Game.
• Could either be a new frame with mouse event click elements leading to other frames, or some
sort of a pop up box appearing as it's own symbol.
• Will return the player to the same map they just fought with the same character.
Quit Game – available when a player completes a match, win or lose.
• Could either be a new frame with mouse event click elements leading to other frames, or some
sort of a pop up box appearing as it's own symbol.
• Will return the player to the beginning of the starting cinematic.
Time Remaining
Located in the bottom right corner. Displays the time remaining for the current level.
• Dynamic text box counting down. When the timer reaches zero (i <= 0) the match will end, and
the health bars will be tallied to determine the winner.
Current Health
Located in the top left and right corners of the screen. The Current Health updates as the player or
opponent manages to strike the opposing character.
• Hit tests will determine whether or not a character was successfully struck. Upon a successful
strike the opposing character's health bar will be reduced, replacing its value minus the amount
of the strike's worth.
Current Match (Time Dependent)
Located directly below Current Health. Displays the current match the player is participating in.
• Dynamic text box. i>=2 advances the character on to the next frame and the fight map.
8. MOVEMENT SYSTEM
The player is able to move their avatar horizontally inside the game. The movement is limited by the
play area, and while the player may be able to hop or crouch, the end position of such a move will be
on the same horizontal plane where the character began.
(This may be expanded to a more Super Smash Brothers style of play, with platforms and double
jumping. In this case jumping will have a velocity and a varying start and end points.)
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
9. DIFFICULTY LEVEL
The matches the player plays through will increase in difficulty as the character progresses. The
hardest fight of each zone will be the boss fight at the end of the zone, with each zone being
incrementally more difficult than the previous.
• Tweakable values with how hard the opponents attacks hit, and how quickly they move.
10. ARTIFICIAL INTELLIGENCE
The computer controlled opponent will attempt to defeat the player controlled character using the
moves allowed by the character it's representing. Adjustments will need to be perfected in order to
ensure that the difficulty level is appropriate and not too easy or difficult.
• The AI will follow the computer controlled character in a similar fashion to how the in class
example circle followed the mouse pointer.
• When the AI reaches a certain distance from the player character, 1-2 times the AI's own width,
it will begin to attack.
• The AI will use a random function to attack with one of its moves.
• If possible the AI will also detect if the same move has hit it several times in a row, and will
then block until a different move is used by the player character.
13. NPC SYSTEM
Result of Successful Strike
When a character is struck by an opposing character's ability it removes a pre-determined amount of
health from the struck character. These numbers will need to be tweaked for different abilities to
ensure the player feels the fight is fair, and not lopsided.
Attitude (Time Dependant)
The opponents may begin with certain statistics, and as the level continues become more angry and
agitated and thus gain in power, attacking more quickly or more strongly as the fight progresses.
• Could implement this by creating a “been hit” variable for the computer controlled characters.
For each successful strike i++ for example, and then the moves could be something like
“punchPower + i = damage”.
14. SAVING AND LOADING
Being a Flash game, there is no ability for the player to save their progress. Upon completion of a level
the player will be presented with a code, which allows them to skip to what would be the next level of
progression in Level Selection the next time they wish to play the game.
• As previously stated.
Battery Death
In the case of battery death the level in progress is not saved and must be restarted by the player the
next time he or she plays the game.
15. GRAPHICAL STYLE
Høgskolen i Østfold – DMPro – Game Programming – Halden 02-2013
Ole Andersen
Kristen Kytr
Patrik Svendsen
Mehrdad Taherifard
Fighting Game: Working Title is presented in 2D. The graphical style should be cartoonish in nature.
Environment Graphics
Each zone type may have a different background style, fiery, snow, desert, etc to denote a change in
location. Full background changes may be available dependent on time.
• Each different background will be a different frame or set of frames on the primary scene.
16. SOUND AND MUSIC STYLE
Sound
Each time the player or opponent takes an action a sound accompanies it.
• A successful strike has a sound.
◦ Add the sound to the same function that removes the opponent's health on a successful
strike.
• A missed strike has a different sound from a successful strike, a whooshing noise.
◦ Always occurs unless the “if” test for the hit test is successful, then the other sound plays.
• (Time Dependant)
◦ Jumps could cause the character to grunt or make some sort of noise when used.
▪ Bound to the same key as a jump, played the first time the jump is executed.
• A defeated character should make a “death” sound in addition to an animation of them falling to
the ground.
◦ When the health bar reaches zero (i<=0) the sound is played once along with an animation
for death.
The last 10 seconds (tweakable) in a level play sounds, alerting the player that the time limit is running
out. From 10-5 seconds (tweakable) remaining the sound is played quickly, from 5-0 (tweakable)
seconds remaining the sound is played twice as quickly as the previous 5 seconds (tweakable).
• This could be replaced with a countdown for the final few seconds of a match, alerting the
player the time is running out.
◦ Dynamic text box in a more prominent position on the scene, matching the time left in the
timer but with a flashier animation.
Music
The music should be a catchy repeatable score with the ability to be sped up as the difficulty increases.
Example scores are the music from Tetris and Super Mario.
Environment System Sounds
The environment does not play a part in the game's sounds. Game sounds are restricted to those
already listed along with the music score.
17. TARGET PLATFORM
Flash capable devices.