University of Portland
Donald P. Shiley School of Engineering
5000 N. Willamette Blvd.
Portland, OR 97203-5798
Final Report
Project XNA Game: A Look Into
Game Development
Team Members:
Cory Swanson(Spring Team Lead)
Fenton Radford(Fall Team Lead)
Tom Aaro
Faculty Advisors:
Andrew Nuxoll
Clients/Alpha Testers:
Andrew Graham
Billy Gibbs
Phone 503 943 7314
Fax 503 943 7316
.
.
.
.
.
Revision History
.
.
Rev.
Date.
0.1
4.9.2012 .
FINAL REPORT
TEAM DEADLY GAME
0.2
4.11.2012
0.3
4.18.2012
0.9
4.24.2012
1.0
4.24.2012
REV. 1.0
Author
T. Aaro
F. Radford
C. Swanson
T. Aaro
C.Swanson
T. Aaro
F. Radford
C. Swanson
T. Aaro
F. Radford
C. Swanson
F. Radford
PAGE II
Reason for Changes
Initial draft.
Began implementation of feedback
Continued feedback implementation,
inserted screenshots, introduction,
conclusion.
Implemented second round of
feedback from advisor.
Final proofreading and crossreferencing
.
.
.
.
.
Table of Contents
.
.
Introduction ...............................................................................................................................
7
.
.
Summary: ...........................................................................................................................
7
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE III
Highlights: ..........................................................................................................................7
Assessment: ........................................................................................................................7
Overview: ...........................................................................................................................8
Screenshots: ........................................................................................................................8
Technical Outcomes .............................................................................................................. 15
High Level Overview:..................................................................................................... 15
Major Components:......................................................................................................... 15
Foreword on Object Oriented Programming: ......................................................... 15
Game: ........................................................................................................................ 15
Player:........................................................................................................................ 16
GameObject: ............................................................................................................. 16
Skill: .......................................................................................................................... 17
Projectile: .................................................................................................................. 17
Condition:.................................................................................................................. 17
Block: ........................................................................................................................ 17
Process Outcomes .................................................................................................................. 18
Assumptions: ................................................................................................................... 18
Assumption: .............................................................................................................. 18
Result:........................................................................................................................ 18
Assumption: .............................................................................................................. 18
Result:........................................................................................................................ 18
Issues that arose during implementation: ................................................................ 19
.
.
.
.
Design Changes:............................................................................................................... 19
.
Milestones:.......................................................................................................................
19
.
.
Physics:......................................................................................................................
20
.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE IV
Basic Attack: ............................................................................................................. 20
Damage: .................................................................................................................... 21
Beta Test:................................................................................................................... 21
Remaining Highlighted Milestones: ........................................................................ 21
Risks:................................................................................................................................ 21
Art is not finished by Founder’s Day....................................................................... 21
Sound is not high enough quality............................................................................. 21
Sharing the School’s Xbox 360 with the Game Design class ................................ 22
Conflict between Senior Design, Game Design, and Compilers ........................... 22
Resource Requirements: ................................................................................................. 22
Time: ......................................................................................................................... 22
Budget: ...................................................................................................................... 22
Version Control: .............................................................................................................. 22
Project Additions:............................................................................................................ 23
Conclusions ............................................................................................................................ 23
Summary: ........................................................................................................................ 23
Improvements: ................................................................................................................. 23
Appendix A: List of Skills..................................................................................................... 24
Appendix B: List of Projectiles ............................................................................................. 25
Appendix C: List of Conditions ............................................................................................ 25
.
.
.
.
List of Figures.
.
.
Figure 1 . Title Screen .....................................................................................................................
8
.
. .........................................................................................................9
Figure 2 . Main Menu Screen
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE V
Figure 3 . Character Customization Screen ...................................................................................9
Figure 4. Game Options Screen................................................................................................... 10
Figure 5. Gameplay Screenshot 1................................................................................................ 11
Figure 6. Gameplay Screenshot 2................................................................................................ 12
Figure 7. Practice Mode Gameplay ............................................................................................. 12
Figure 8. Pause Menu................................................................................................................... 13
Figure 9. Post Game Screen......................................................................................................... 14
Figure 10. High Level Class Diagram......................................................................................... 15
.
.
.
.
List of Tables .
.
. By Weight Class ......................................................................... 16
Table 1. Attributes Modified
.
.
Table 2. Project Milestones..........................................................................................................
19
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE VI
.
.
.
.
Introduction .
.
.
Summary:
.
. we chose to create a game for the Xbox 360, Brawl Stars. All
For our senior design project
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 7
three of the members of our team are interested in and enjoy videogames and we felt that the
senior design project was an excellent opportunity to pursue this interest. The game we created
was based off of one of our favorite fighting games: Super Smash Bros. Like Super Smash
Bros. Brawl Stars features a knock back system of combat as opposed to the usual health bar
depletion system seen in many fighting games. Dissimilarly from Super Smash Bros. and
other fighting games we chose to have a high degree of character customization. Most fighting
games have a set roster of characters with character specific move sets. Brawl Stars features 3
separate weight classes (light, medium, and heavy) and allows players to pick a set of 4 skills
from a pool of 8 abilities. Additionally, Brawl Stars deviates from many fighting games in that
moves are executed via single button inputs as opposed to complex button combos.
Highlights:
Brawl Stars was a huge success. During design and implementation we were able to fulfill all
of our milestones, though not always by the expected date of completion. One of the largest
difficulties we faced during the implementation of our project was that of collision detection.
Collision detection is a complex problem and ended up require five times the time we
expected it would take to implement it. Another challenge we faced was working with an
outside artist. As the artist had less at stake the fear that he would not produce was always a
fear and at one point he even felt he had to leave the project. Luckily the artist was able to get
some help and completed all of the requested art in time for the game’s completion. One last
surprise we encountered during our project was the fact that a Creator's Club account (an
account required to run our game on the Xbox 360) was not included by default in the
school’s software lease from Microsoft like Word or Windows. With some help from Dr.
Tammy Vandergrift we were able to sort out this issue and get the game running on the
console.
Assessment:
As a team, we have been very pleased with our performance as a whole. All three members of
the team were able to contribute and work together on the project and still maintain a healthy
friendship at the same time. We are very proud of the fact that we were able to accomplish all
of our primary objectives and we are very pleased with the game.
One area we feel like we could have improved in was our version control system. We chose to
forgo a version control system like git or subversion. Instead, we chose to use drop box to
upload different versions of the code. This quickly led to confusion as to which version of the
code was the most up to date as we would often be working on different parts of the game in
parallel.
.
.
.
.
Overview:
.
. will discuss the implementation and results of the project in more
The remainder of this paper
.
detail. Specifically, it will
. cover some of the technical aspects of the project, including a high
level overview of the game
. architecture and discussion of some of the most important classes
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 8
in the game. Next it will move on to cover some of the outcomes of the project including the
outcomes of our assumptions, changes made to the design during implementation, a look at
our milestones and how they went and discussion of our risks, time management and budget.
Lastly we will wrap up the report with a final summary and discussion of improvements that
could be added to the game in the future.
Screenshots:
The following screenshots depict the player’s point of view as well as show off the most
important aspects of the game.
Figure 1 . Title Screen
Figure 1 is a screenshot of the Title Screen when you first turn on the game. From here the
player can press start to proceed to the Main Menu Screen (Figure 2).
FINAL REPORT
TEAM DEADLY GAME
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 9
Figure 2 . Main Menu Screen
Figure 2 is a screenshot of the Main Menu Screen. From here the player can choose to select
Multiplayer Mode, Single Player Mode, or to view the Credits. By selecting Multiplayer or
Single Player Mode the player will then proceed to the Character Customization Screen
(Figure 3).
Figure 3 . Character Customization Screen
Figure 3 is a screenshot of the Character Customization Screen. Here the player is able to
create their character by selecting which weight class to be and which skills the player would
like their character to have. Once the player is ready they can select the ready button at the
.
.
.
.
bottom of the screen. If.the player selected Practice Mode then only one player’s screen will
be initialized. If the player
. selected Multiplayer Mode then if other players joined in by
pressing start on their controllers
then their screens would initialize as well. Once the player or
.
players are ready then they
. will proceed to the Game Options Screen (Figure 4).
.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 10
Figure 4. Game Options Screen
Figure 4 is a screenshot of the Game Options Screen. Here the player can select how much
time they want a round to last as well as how many lives a character can have. Also the player
can choose what map to play on where each map has its own unique layout and obstacles.
Once the player is ready then gameplay can begin (Multiplayer: Figure 5, Figure 6; Single
Player: Figure 7).
FINAL REPORT
TEAM DEADLY GAME
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 11
Figure 5. Gameplay Screenshot 1
Figure 5 is a screenshot of a player in game. You can see that the time is displayed at the top
of the screen and the number of lives that the character has is displayed at the bottom of the
screen next to the avatar’s head. The bottom of the screen is reserved for each of the characters
stats (i.e. how much damage has been taken, what skills they have, what conditions are
afflicting them, how many lives they have). The rest of the screen shows all the action. You
can see the character has used Icewall, Poison Grenade, and the character has begun charging
Donkey Punch.
FINAL REPORT
TEAM DEADLY GAME
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 12
Figure 6. Gameplay Screenshot 2
Figure 6 is another screenshot of gameplay. The player has chosen to create a light character
with a different set of skills. Also note that the character has been afflicted with the burning
condition and is displayed at the bottom of the screen.
Figure 7. Practice Mode Gameplay
Figure 7 is a screenshot of Practice Mode Gameplay. There is a dummy player in this mode
which the player can test out their various customized characters.
FINAL REPORT
TEAM DEADLY GAME
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 13
Figure 8. Pause Menu
Figure 8 is a screenshot of the Pause Menu. During gameplay at anytime the player may
choose to pause the game by pressing start on the controller. This screen will pop up, halting
gameplay, allowing the player to return to the Main Menu if they so choose or to resume
gameplay. This is a must in games so that way players can go get a drink mid-game if
necessary.
FINAL REPORT
TEAM DEADLY GAME
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 14
Figure 9. Post Game Screen
Figure 9 is the Post Game Screen. Here players can see how well they fared against each other
in combat. Here players can see how often they died and killed one another and a few other
stats from the game.
.
.
.
.
.
Technical Outcomes
.
The following section .details the resulting technical portion of our project. First we will
. of our entire project, and then we will go into detail about the
provide a high level diagram
specific purpose of each.major component shown in the diagram.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 15
High Level Overview:
The following is a high level class diagram. Solid lines denote inheritance, dashed lines
indicate use.
Figure 10. High Level Class Diagram
Major Components:
Foreword on Object Oriented Programming:
Our game makes use of the object oriented programming paradigm. The main feature of
object oriented programing is inheritance. The idea of inheritance is that certain classes
represent more general objects and other more specific objects inherit methods and variables
from them. As an example consider a vehicle class that has whether a vehicle is meant for air,
land or water and how big a vehicle is. A car class could inherit those two attributes from
vehicle and add its own unique attributes such as miles per gallon or max speed.
Game:
The game class is the class which handles the actual calculations for the game. Parts of the
game such as collision detection, animation, navigating menu screens and choosing character
options are handled by the game class. The game class also hosts all the collections of other
.
.
.
.
classes such as the list. of characters, levels, conditions, and projectiles. The game class
interacts with every other
. part of the game acting as a driver for the entire project.
.
Player:
.
.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 16
The player class is the game’s representation of a player. This class contains information about
the player such as how much damage the player does, how fast the player can move, a list of
what skills the player has selected and what conditions are currently affecting the player. Each
Player in the game is represented by their own instance of the player class. A player’s
character can fall into one of three categories: light, medium and heavy. These categories
affect the character’s attribute. Attributes are characteristics like how high the character jumps,
how high the character runs, and how long a character must wait between casting skills.
The following table describes the attributes affected by the user’s choice of weight class.
Table 1. Attributes Modified By Weight Class
Light
Medium
Heavy
Speed
11
9
7
Jump Height
10
9
8
GCD Length
1100ms
1000ms
900ms
Heavy Attack
Damage
12
15
18
Light Attack
Damage
2
8
10
*Note: Numbers without units are scalars.
GameObject:
The GameObject class is the basis for all corporeal objects represented in our game.
Projectile, block, and player classes are all subclasses of game object. The following is a list
of the fields inherited from game objects:
-
x coordinate
o The x position of the object on screen.
y coordinate
o The y position of the object on screen.
Width
o How wide the object is.
Height
o How tall the object is.
isActive
.
.
.
.
o The .Boolean representing whether or not the GameObject should be
drawn,
. or still applying its effects in the game.
hitBox
.
o The .rectangle that defines the area that projectiles can collide with the
object.
.
FINAL REPORT
TEAM DEADLY GAME
-
-
REV. 1.0
PAGE 17
boundingBox
o The rectangle that defines the drawing area for the sprite of the object.
sprite
o The animated sprite that displays the object.
faceLeft
o A sprite effect that manipulates the direction the sprite is drawn.
Skill:
Skills are the various special abilities that players may choose on the character selection screen
for use during game play. Skills have various effects including creating projectiles, teleporting
the character or creating destructible blocks. When a skill is used, it goes on cool down for a
short period of time. Spells cannot be used while they are on cool down. Spells have different
cool downs depending on how powerful the skill is. A full list of the skills can be referenced in
Appendix A: List of Skills.
Projectile:
Projectiles represent objects like bullets, fireballs, lighting bolts or missiles in the game world.
Projectiles have an effect that occurs when they hit a character or wall. Projectiles are created
by characters when they use any skill with the exception of teleport. As an example, the
fireball skill creates a fireball projectile that moves across the screen. Upon collision with a
character the projectile disappears and inflicts damage to the character that was hit, and applies
a burning condition. If a fireball hits a wall the projectile is destroyed. A full list of projectiles
can be found in Appendix B: List of Projectiles.
Condition:
Conditions represent lasting effects on characters brought on by skills or elements of a level.
All conditions have a time limit or some other trigger that ends the effect. Conditions can have
a wide range of effects such as healing or dealing damage to a character periodically, granting
the character bonuses to character traits like speed or armor or returning the character to a
certain position when the condition ends. A full list of conditions can be found in Appendix C:
List of Conditions.
Block:
Blocks are used to make up the various levels in the game. All parts of the terrain are made up
of various types of blocks. Unless otherwise noted, blocks will not harm players on contact, be
it from running into a block or falling onto it from any height. Block types and their associated
properties are listed below:
.
.
.
. – These blocks make up the majority of most levels and cannot be
Indestructible block
.
destroyed by any
. means. A character cannot move through these blocks and most
projectiles will be
. destroyed when they run into indestructible blocks.
.
Destructible block
. – these blocks, like indestructible blocks, will block a character’s
FINAL REPORT
TEAM DEADLY GAME


REV. 1.0
PAGE 18
movements as well as destroy most projectiles. Unlike indestructible blocks, these
blocks have a variable amount of health and can be destroyed by a character’s attacks
and skills.

Regenerative Blocks – These blocks behave like destructible blocks, but after a short
time they regenerate their health and reappear when they have reached full health.

Lava – lava is represented in the game as a separate type of block. Lava will not flow
and cannot be moved or destroyed by a character. Any character that comes in contact
with a lava block will have the burning condition inflicted on entry and will constantly
have its duration refreshed while the player remains inside the block.
Process Outcomes
Assumptions:
During our design process we made two key assumptions, the following are the assumptions
we made during our design, and the results found during our implementation:
Assumption:
Programming to Xbox 360 will be similar to programming for a PC in that we hope to take all
of our experience with object oriented programming and the C#/Java environment to our
benefit.
Result:
This assumption held, during the development of our project, we were able to use our
familiarity with the object oriented paradigm to have our object interact seamlessly within our
game setting.
Assumption:
Because the Xbox 360 provides no internal coding functionality, we programmed the game on
a PC, as such we assume code we write and test on the PC will behave the same as when we
port the project to the Xbox 360.
Result:
While our assumption was correct in that we could easily transfer the game from the IDE to
the Xbox console, we were incorrect in assuming the schools network would allow us full
usability after getting our development console whitelisted on the school network.
.
.
.
. implementation:
Issues that arose during
. project we also ran into an assumption we failed to note during the
While implementing this
.
design process: We had
. assumed that we would be able to acquire a creators club license
through UP’s MSDNAA
. agreement with Microsoft. Despite the fact that this ultimately held
true, we had to gain. Professor Vandergrift’s assistance in acquire our creators club
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 19
membership.
Design Changes:
Our project deviates very little from our original design, the system hierarchy in place is
consistent with the one described in the design document. Where the implementation differs
from our original design, is the complexity of each individual system. Many classes
especially, player and game ended up with a multitude of instance variables that we had not
anticipated during the design process. For example our player required Booleans for their
various combat statuses like whether or not they were blocking, dodging, or grounded. As a
result of these additions, our individual systems became more complex, but the system as a
whole remained more or less unchanged.
Milestones:
During our implementation we used a list of milestones track our progress, the following is a
table that describes the estimated and completion dates of the milestone we created.
Milestones highlighted in red were completed after our originally estimated date.
Table 2. Project Milestones
Number
Description
1
2
3
4
5
6
7
8
9
10
11
12
13
Functional Specification v0.9
Functional Specification v1.0
Game Website
Design Document v0.9
Design Document v1.0
Display Game
Character Movement
Actions/Control Scheme
Physics
Animation
Gravity
Catch Up
Basic Attack
Estimated
Actual
Completion Completion
Date
Date
9/23/11
9/30/11
10/14/11
11/11/11
11/18/11
11/21/11
11/28/11
11/28/11
11/28/11
12/5/11
12/5/11
12/12/11
1/19/12
9/23/11
9/30/11
10/14/11
11/11/11
11/18/11
11/21/11
11/28/11
11/28/11
2/9/12
12/5/11
12/5/11
12/12/11
1/23/12
FINAL REPORT
TEAM DEADLY GAME
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
.
.
.
.
. One Skill
.
Damage
.
Half
. of Remaining Skills (1/2)
Half
. of Remaining Skills (2/2)
REV. 1.0
Catch Up
Conditions
Levels
Menus
Skill Sets
Sound
Beta Test
Polish Gameplay
Rebalance Mechanics
Implement Beta Feedback
Catch Up
PAGE 20
1/19/12
1/19/12
1/26/12
1/26/12
2/2/12
2/9/12
2/16/12
2/6/12
2/6/12
3/8/12
3/15/12
4/2/12
4/2/12
4/2/12
4/9/12
1/19/12
1/23/12
1/26/12
1/26/12
2/2/12
2/9/12
2/16/12
2/6/12
2/6/12
3/8/12
3/29/12
4/16/12
4/16/12
4/16/12
Other than the milestones listed below, all of our milestones were completed on time. While
we wish that milestones were completed early, it did not occur. Below are the milestones that
were completed after their due date along with the reason for their late completion.
Physics:
This was, by far the most complex aspect of our game. Because we had a physics engine that
we had tested prior to implementation that worked, we thought that this milestone was going
to function in our final framework, however when we actually ported collision detection over
it became severely broken. When we moved the engine over, while players could walk across
flat surfaces, when colliding with blocks at an angle, players would fly across the screen.
During our debugging process, we attempted to use a significantly different physics engine.
Our first engine attempted to use algebra to calculate where a player would collide with a
block and stop his movement at the appropriate point. Our second engine attempted to
calculate how far into a block a player ended up after their movement, and correct for the error
in depth by the calculated amount. Finally we took the insight gleaned from both engines and
created the currently implemented form of our physics engine that uses the process of the first
method, and correctly applies the formulae to the appropriate intersections.
Basic Attack:
About half way through the project we switched our meeting times with our advisor, that
being said we fell victim to miscommunication and as a result we failed to schedule a meeting
in a timeframe that allowed us to complete this milestone on time.
.
.
.
.
Damage:
.
.
This milestone was late .for the same reason discussed in the basic attack milestone above.
.
Beta Test:
.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 21
We ended up rescheduling this milestone twice. First we discovered that holding a beta
during the weekend prior to spring break was impractical because most of our prospective beta
testers were out of town we decided to postpone the beta test for a week.
Next we felt like the project was not yet polished enough to provide a good testing bed for our
beta testers. We decided to delay our beta for a second week in order to provide a more
reasonable product for testing. The reason the game was not fully prepared for this milestone
came about due to a large assignment in another course, a risk we noted in our design, but
failed to fully accommodate.
Remaining Highlighted Milestones:
Because the last three milestones including polishing gameplay, rebalancing mechanics, and
implementing feedback are iterative processes, we are continuously working on these
milestones. At this point in time we feel as though we have created a functional game, which
covers the requirements laid down in both our functional specification and our design
document. We took longer to polish our game than expected because we were not yet
satisfied with the overall quality until just before founder’s day.
Risks:
During our design process we came up with four possible risks that might arise during
development. The following are those risks, and if they arose, how they were countered. For
full risk descriptions, refer to the risks section in the functional specification.
Art is not finished by Founder’s Day
Although this posed a potential risk, we managed to pull through it unscathed. The artist
nearly quit half way through the semester, however he quickly received reassurance and help
from family resulting in the art being completed in ample time.
Sound is not high enough quality
Despite our original concern that the sound quality would be too poor to be used in our game,
it turns out the recording equipment available was more than adequate, producing sound that
was actually too high quality for the development framework we used to handle. We were
easily able to dumb down the sounds we created, saving them in a lower quality format.
.
.
.
. 360 with the Game Design class
Sharing the School’s Xbox
.
. our advisor who also is responsible for teaching the game design
We were able to work with
. to reserve exclusive rights to the development console. As a
course here at the university
.
result this was a non-issue.
.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 22
Conflict between Senior Design, Game Design, and Compilers
This was the most significant risk associated with this project. Because all three members are
enrolled in other labor intensive classes the time we were able to output on this project week to
week was dependent on other commitments. In the end we were able to mitigate the effects of
this crisis through well planned milestones (with the exception of the Beta Test: milestone)
and meetings.
Resource Requirements:
Time:
For the implementation portion of this project we forecasted only 127 man hours. In fact we
spent 201.5 hours. A large portion of this disparity comes from the unexpected difficulty with
collision detection. Collision detection was a complicated algorithm and working out the bugs
that resulted from it took the largest amount of time. While we originally planned only a week
to implement and debug this portion of our game originally, it actually ended up taking us five
weeks to fully implement the system. Otherwise the extra time comes from each system being
individually more complex than planned.
Budget:
During our project we budgeted 150 dollars for our artist, and 50 dollars for sound. Payment
for art was straight forward, upon completion the artist was paid in full. While we originally
budgeted money for sound creation and editing; we ended up not needing that portion of our
budget. Finally we almost had an expenditure we did not anticipate. We had originally
assumed we would be able to acquire our creator’s club license through the university’s
software agreement with Microsoft (see Assumption:), if this had fallen through, we would
have been required to spend an additional 100 dollars. Fortunately we were able to work with
Professor VanDeGrift and get our license free of charge.
Version Control:
This project used a self-implemented version control system using dropbox as a base of
operations for the team. When a version of the program was implemented, a new zipped
folder was placed in the team dropbox along with a change log, and never deleted. After one
month of development the most up to date version was left in the dropbox but all other
versions were archived to another location. While this did not cause any problems for our
group and worked well, a more strictly enforcing system like git or subversion would be
suggested.
.
.
.
.
Project Additions: .
.
Because we picked an. ambitious project from the beginning, we have not been able to
implement functionality.beyond that of our original design.
.
FINAL REPORT
TEAM DEADLY GAME
REV. 1.0
PAGE 23
Conclusions
Summary:
In summation, we feel that this document provides a more thorough understanding of both our
project and its successes. The technical outcomes section provided a clearer picture of how our
game was organized and how it functions. The process outcomes section showed some of the
initial design decisions, assumptions and risks and the how those elements played out during
the implementation of our project. As a whole, we are very proud of the product we created
and feel that our accomplishments speak for themselves. All primary objectives were
completed and anyone who has played the game can tell you that it is surprisingly fun to play,
which is all a game can truly hope for.
Improvements:
If we decide to continue development of Brawl Stars there are a few areas in which we could
improve and expand the game. First and foremost the game could benefit from continued
testing, debugging, and polishing. This would include things like gameplay tweaks and
balances in addition to polishing on menus and the overall feel of the game. As far as additions
to the game, the most likely improvement would be the addition of more skills. While 8 skills
offers us a fairly robust pool of abilities to choose from there are still some areas we would
like to explore including more powerful projectiles, healing and defensive abilities, and
abilities which apply additional conditions besides burning and poison. Lastly, we would like
to try and get our game onto the Xbox Live Marketplace.
.
.
.
.
. of Skills
Appendix A: List
.
. the player’s character across the screen in the direction the player is
 Teleport – Moves
.
facing and upwards.
. Applied: None
o Conditions
FINAL REPORT
TEAM DEADLY GAME






REV. 1.0
PAGE 24
o Cooldown: 12 seconds
o Damage: 0
o Range: 500 pixels
Fireball – Creates a fiery projectile which is hurled away from the character to damage
the enemy, causing initial damage as well as applying the Burning condition. When it
hits a wall it disappears.
o Conditions Applied: Burning
o Cooldown: 5 seconds
o Damage: 5
o Range: 650 pixels
Ice wall – Summons a destructible wall in front of the character which can be used to
block enemies and projectiles. If an enemy is caught in the initial summon of the ice
wall then they take damage. The wall has 10 health.
o Condition Applied: None
o Cooldown: 7.5 seconds
o Damage: 3
o Range: created 2 x caster’s width in pixels in front of the character
Stone Clap – Raises stone hands from the earth colliding them with the enemy. This
skill can only be used while on the ground.
o Condition Applied: Stun
o Cooldown: 11 seconds
o Damage: 10
o Range: created 100 pixels in front of the character
Magic Missile – A magical projectile that seek out the nearest enemy. If they hit a wall
then it disappears.
o Condition Applied: None
o Cooldown: 5 seconds
o Damage: 8
o Range: 600 pixels unless chasing where it will only disappear if it hits
something
Poison Grenade –A projectile is thrown by the character, creating a cloud of poison on
impact that damages enemies caught in the resulting fallout that lasts for 5 seconds
constantly inducing the slow condition.
o Condition Applied: Poison
o Cooldown: 8 seconds
o Damage: 2 for initial grenade projectile
o Range: until it hits something
Scorpion Wire – Character sends a projectile from them towards an enemy, if it hits,
the target is pulled towards the attacker. If it hits a wall then it does nothing
o Condition Applied: None
o Cooldown: 8 seconds
.
.
.
.
o Damage:. 5
o Range: 700
. pixels
Donkey Punch –. Character throws a mighty punch after charging up the attack. The
player presses the
. button assigned to the skill once to initiate charging and again to
unleash the attack
. during any moment of charge or once the charge is complete. The
FINAL REPORT
TEAM DEADLY GAME

REV. 1.0
PAGE 25
damage will scale according to the proportion of charge. Maximum charge takes 4
seconds. This skill knocks the enemy away if hit.
o Condition Applied: None
o Cooldown: 1.5 seconds
o Damage: 5 – 20 depending on how long the skill was charged for
o Range: 35 pixels in front of the character
Appendix B: List of Projectiles




Fireball – A ball of fire that moves in a straight line
o Speed: 8
Magic Missile – A missile that seeks out the enemy
o Speed: 8
Poison Grenade – A projectile that is thrown in an arc.
o Speed: 8
Scorpion Wire – A projectile that travels towards the enemy and then returns to the
character who used it.
o Speed: 12
* Note: Units are only for scaling
Appendix C: List of Conditions





Burning – Ignites the character setting them on fire causing damage over time.
o Duration: 3 seconds
o Effect: 5 damage per second
Stun – Prevents the character from moving or using any skills.
o Duration: depends on skill used (Stone Clap: 1 second)
o Effect: None
Slow – Hinders the character’s movement speed down to half of normal speed.
o Duration: 3 seconds
o Effect: None
Haste – Increases the character’s movement speed to 1.5 times that of normal speed.
o Duration: 3 seconds
o Effect: None
o Note: No skill in the game currently induces haste
Poison –Hinder’s the characters movement as well as applies damage poison damage
over time.
o Duration: 5 seconds
o Effect: 1 damage per second