Milestone 4 - Final Report
CPE 123-09
December 4, 2010
BomBlaster
Olivia Gandara
Victory Chang
Jaime Ceja
Spencer Lines
BomBlaster Description
The goal of this game is to survive for as long as possible as the game
gets progressively harder. Sound too typical? Well, how about this. You are a
commando who has been shot down behind enemy lines and they want you
dead. As such, you face an onslaught of enemy helicopters, helicopters that
just so happen to have plenty of bombs to drop on you. On top of that,
these bombs contain napalm. When a bomb hits the ground it releases said
napalm, which will continue to burn for a while. Touching the napalm will
reduce your health and eventually kill you, thus you should avoid it or jump
over it. But there is more bad news; these bombs are being dropped more
and more frequently. On the positive side, you are a terrific athlete and a
skilled marksman, and you have plenty of anti-bomb ammunition for your
gun. So, you can either dodge the bombs by moving left or right or you can
shoot them in the air by clicking on them with your mouse aimer. The
terrible news is that some of these bombs take multiple hits to destroy.
Good luck with that ...BomBlaster!
Meaningful Play
One of the keys to meaningful play and the closely-linked idea of flow
is providing ample choices for the player to make, such that he or she can
choose the ones that complement their style of play and connects them to
the game. In BomBlaster, the player is given multiple choices as to how they
will survive. One option is to shoot the bombs that are dropped from the sky
(aka off the screen). Since these bombs speed up as they fall like real
gravity, there is limited time for strategizing and more emphasis on
instinctual reaction (another component of flow). Players must avoid theses
falling bombs because if they get hit by them, they will instantly die and go
to the game over screen. No one likes to see a game over screen with a
decapitated head of their hero leaking red stuff. We tried to make the hero
look tough, but at the same time cartoonish and like-able. The goal was to
create an avatar for the player that they could bond to and envision
becoming in the game, which makes the game more meaningful for the
player. As for the napalm, when it appears on the ground you and either
avoid it or jump over it. Jumping over napalm is higher risk since you might
jump into an oncoming bomb, but it can also provide a higher reward of
getting out from underneath a localized bomb barrage. The goal is to give
the player the freedom to pick the best choice based on the situation that
they are faced with, such as the number of bombs that are being dropped or
the amount of napalm that has been produced in game. If they chose to
shoot the bombs, they can destroy them, gain more points, and avoid being
killed by them instantly. However, the bombs that they do not destroy will
hit the ground and turn to napalm, which when touched will decrease their
character’s health and eventually kill them. In the larger context of the
game, losing all of your health or the result of an instant hit from a bomb
will result in death. Players have a lot of choices for what actions to take,
and choosing the best combinations will ultimately determine the amount of
time they survive and the number of points they receive. Another way we
create meaningful play is by incorporating different modes of interactivity
into the game to make the player feel that he or she is entrenched in a war
and has been shot down behind enemy lines. It is mainly the graphics and
sounds that make the first mode possible, since seeing is believing. The
second mode of interactivity is what is actually happening in real life, it is
the actual interaction between the player and the game. For our game it is
the movement created by pressing the arrow keys (or WASD), and moving
and clicking the mouse. The third mode of interactivity encompasses all of
the choices available to the player in the game. For instance, the jumping,
shooting, dodging, moving and anything that has to do with a decision being
made. The final mode of interactivity is seen when the game is over. The
high score is saved onto the computer and will be there until a new high
score is achieved, which can give that player bragging rights over others
who play, or it can give the incentive to try again and do better.
Feedback is incorporated into the game to create meaningful play as
well. Negative feedback loops are incorporated by programmers to
continually adjust for stable play, while positive feedback loops are used to
encourage divergent play and behavior. In our game, negative feedback
loops occur in the sense that both the score and the time determine the
difficulty of the game. If players can only avoid bombs and survive for a
minuscule amount of time and points, then the skill level will be easy. But as
a player progresses in the game, the difficulty becomes harder to match the
players skill level. At the same time if a player is doing really well then the
game will drop much more bombs at a time and the bosses will get a lot
harder. This allows for stable game play and makes the game a lot more
fun. There can also be positive feedback loops that bring about a quicker
victory. For instance, if the player is was doing well, we could make the
game get easier and easier until he or she won. Or, for every bomb you
destroy your gun could get stronger and stronger. In our game, there are no
positive feedback loops that help a player to win faster as they do well; you
can only lose, but the addicting question is, “How long can you last?”
Implementation
In BomBlaster, there are currently sixteen class files, all of which are
instantiated by two main class files called “DocumentClass” and
“BomBlaster.” The document class sets up each of the various screens that
are in the game. This way we have a very small main flash timeline (only
three frames), and the rest of the work is done with code. Each screen class
has listeners for custom dispatched events which tell each screen when to go
to a next screen. The menu screen listens for a button press to either load
the intro screen, the controls screen, or launch the game. The intro screen
listens for the completion of the external SWF file which holds our intro
movie and then creates a new menu screen. The largest screen is actually
an instance of the BomBlaster game class. This screen listens for the death
of the main character and then ends the game and calls the game over
screen class. The BomBlaster class sets up all the game objects like the
avatar, bombs, bosses, bullets, and napalm. It then executes a massive
function called OnTic every 25 milliseconds which moves all of the objects
and checks for collisions and garbage collection. This is made possible by
holding each object collection in an array and stepping through the array
using for loops. Now we will discuss what each object actually does.
Avatar- The main character class, is controlled by mouse and the
arrow or WASD keys using keyboard and mouse event listeners. There is no
running animation for the avatar, but the left/right stepping and the gravitybased jumping is very smooth, as it is executed every 25 milliseconds. The
avatar has a gun symbol attached to his x and y location, and the symbol
which is continually rotated to point at the mouse.
Bomb- The most common enemy. A bomb either has 1 or 2 health,
each bullet shot does 1 damage. Bomb size and point value is tied to its
health. When a bomb hits the ground (reaches a certain y location) it is
removed and replaced by a napalm object. When the napalm animation
finishes, the napalm is removed from napalm array and from the stage.
When a bomb is hit and still has health, the bomb symbol goes to the next
frame which is the red bomb. When a bomb is hit and has no health, the
bomb symbol plays the rest of the explosion animation and sets a
bombIsDead Boolean to true so that the explosion animation does not kill
the avatar on collision (which was making the game almost impossible to
play).
Boss - This class spawns a helicopter and passes the x and y location
of the avatar to it. Using that location data, the helicopter can chase the
avatar while continually dropping bombs. Bosses gain a level each time they
are destroyed and their health, speed, and drop rate is tied to that level.
All of the collisions are detected by an advanced pixel-level collision
class that was borrowed from previous lab work. Pixel-perfect collision is
very important, since round symbols are bounded by an invisible square box,
and no one likes to die by touching an invisible box.
There were quite a few implementation issues throughout our game
design process which we needed to overcome, especially in our first
prototype. When we introduced napalm into the game, which is a movie clipbased symbol, our game lag got out of hand. The lag would be zero in the
beginning, and then get progressively worse, which is symptomatic of
dwindling computer resources. Sure enough, the napalm was being removed
from the napalm array. But the inivisble napalm symbol was staying on the
level and using up resources. Once that was corrected, lag was better, but it
still occurs when tons of bombs start dropping. Using the .bitmap
actionscript function to convert our objects to images and have a smaller file
size also reduced the lag effect. Another aspect of the game that we had
trouble incorporating after our first prototype was jumping. It seemed very
simple because we thought it would move a character up to a certain value
and then back down, but our code seemed to defy gravity. When we hit the
jump key, the commando would move up slowly and when we let go, he
stayed on that location of the screen and never came down. We solved this
problem by finding a simple code from an actionscript tutorial online to make
our character jump. There were also problems in our thirty percent
prototype, such as a lacking bomb explosion animation which ruined the
realism (since when do bombs just disappear). Unfortunately, we fixed the
bomb explosion problem but never had time to implement a decent
helicopter explosion animation. However, adding explosions was not a good
thing at first. After you destroyed a bomb, the remaining flak would still be
lethal and cause an instant kill if your character were underneath it. The
animation played by telling action script to play movie clip until stop(); in
the action bar. So each step of the bomb movie clip was intuitive. Once a
bullet hit the bomb and destroyed it, we needed to tell action script to turn
off lethality by using a Boolean. Time was also a major issue that we needed
to manage. We wanted to develop a great game with great graphics, but
nice graphics do not make a game fun. They only enhance the fun gameplay
by immersing you in it. At the end, we had to forgo nice animations for
better player interactivity for the sake of meaningful play.
Mathematics also became a large part of our game because we needed
to use instances such as the angles sine and cosine to follow the location of
the aimer with the mouse to shoot bullets in a straight path and it was
necessary when we were coding the scale of objects in the game by testing
out and using ratios and decimals for our objects such as the bombs and the
drop rates.
Iterative Development
The iterative design process is a four step procedure that we
undertook multiple times in order to develop a game that implements
meaningful play and player understanding of interactions in the game. The
process of prototyping, play testing, evaluation and refinement helped us,
the game designers, to the develop a final product. For instance, we made
multiple prototypes in an effort to see what play testers would like in the
game. We also created a questionnaire for the play testers to fill out after
they played that asked them questions like what they would like to see
added in the game. Each prototype added something new to try to address
the concerns of our play testers. Our first prototype was very basic and just
had one type of bomb falling and a level system that made the amount of
bombs falling increase as your score increased. The feedback we had for this
prototype was a mixed bag of negative and positive. On the negative side a
lot of the responses wanted power ups, and said it got pretty boring after a
couple minutes. There was also some lag issues but mainly responses were
concerned with the fact that it was boring. Instead of adding power ups we
evaluated their feedback and decided that since boredom was the issue we
needed to expand the game to include more diversity and deeper play. The
next round of prototypes added another type of bomb, there are bigger
bombs and small bombs, some with faster drop rates and some that take
two shots to explode instead of just one. After this prototype we again had
play testers play the game and give us feedback. A lot of the problem with
this prototype was the fact that the difficulty increased exponentially. Since
the score determined the difficulty after awhile the score would increase so
quickly that the levels would fly by and spawn rates for the bombs was
enormous. Again we got a lot of people wanting power ups for the game or
something to make the game challenging but not dull and repetitive. We felt
that instead of adding power ups we could employ a new dimension in the
game like an explosion that erupts when the bomb hits the floor. We did try
at first to create some sort of blast radius but it was too difficult and instead
we decided to go with a napalm fire that ignites when the bomb hits the
ground. This meant that we also had to include a health variable and a
health meter for the player to see. The napalm erupts when a bomb hits the
ground, and lasts for two seconds. Touching the napalm reduces the player’s
health and if stood in for too long it also would kill you. After this round of
play testing a lot of people said the game was a bit repetitive but very fun.
We could have stopped there but from the beginning we had wanted a
helicopter boss battle for the player to fight and possibly get health packs
from or weapon upgraded from upon shooting it down. So in the last and
final prototype we added boss battles with a helicopter. The boss comes out
on a time schedule and after every reincarnation gets harder and harder and
takes more shots to bring down. The addition of the boss would give the
player a break from bombs dropping above them and give them a challenge
to look forward to at certain instances in the game when the boss would
appear. We ended up scrapping the idea to drop health packs and weapon
upgrades because of a lack of time. We also had tossed the idea around of
having missiles launched from the helicopter to the character and we had
even created the graphics and symbol for it. The problem with the missiles
would be how to calculate its speed, would it be a homing missile or a
straight shot with a lot of speed? Would it have a huge blast radius or would
it only kill if it hit the player? Lastly, the missile would have taken a lot of
time to code into the game since it could only be shot when the helicopter is
present and we did not have nearly enough time to add the missiles.
During our play testing sessions, we felt is was necessary to evaluate
and let a variety of both gamers and non-gamers play test, because they
have their own perspectives of how to make the game more fun or what was
necessary to include or to remove from the game. It was important to see
which aspects they would point out because different people have their
personal opinions about what is fun and what is not. We have also found
that the non-gamers quite enjoyed our first prototype because it was a
challenge for them to accomplish. We found that gamers, however, wanted
more of a challenge because it wasn’t complicated as other games that they
have played, and it was too easy for them to accomplish, they did not need
to exert effort to stay in the game long, it was intuitive, but boring. Our play
testing sessions were successful because we found out which items that we
included in our prototype worked or didn’t, but most of them wanted the
same additions as suggestions for our future prototype. We took into
consideration which items were possible to add such as mapping the WASD
keys instead of the arrow keys and more challenging obstacles, which is why
we included napalm and the health bar, to create a more distinctive and
meaningful game play. We also had to consider the other suggestions that
we felt were not as appropriate to prioritize in our game, so we included
suggestions like adding different music, different weapons, and artwork on
the last of our to-do list. It was important, however, to address player
concerns in our group discussions in order to develop a game that would
satisfy the gaming world.
In our evaluative process, we found flaws that we were missing from
the player suggestions, but also our notes, and that was accommodating
narrative play. When you click start, you instantly start a screen and start
destroying bombs, but there seemed no purpose as to why you are being
bombarded. On our papers, we would develop a storyline as to how the
commando gets to the position he is in, but the players on the other hand,
are in the dark. We felt that we needed to spend time to develop a pre-game
cut scene in order to implement narrative play because it helps demonstrate
a player’s actions in the game. While evaluating our play testing results, we
also found that our first prototype incorporated somewhat boring and
repetitive game play, but it was a task that non-gamer could accomplish .
Overall however, we found that each of the suggestions that they mentioned
all relate to a boring game with a lot of glitches that we had yet to figure
out. Our second evaluative process after play testing showed us that being
rained on by a ton of bombs and shooting them did not make the game
strategic. From our evaluations of prototyping and learning about new
aspects to include into our game from the lectures, we the needed to
combine our efforts and make changes, this process of evaluation was
crucial for us to develop a game.
The final step of the iterative design process is refinement, and this
was where teamwork was required. Each of our group members had
completely different schedules, but we needed to find time during our busy
schedules to brainstorm what we learned in the play testing and the
evaluation that is possible to attempt in our next prototype, given the
limited amount of time that we had. Each loop of the iterative design process
changed our priorities list because our limitations of time would only allow to
focus on objects such as a boss or a health meter, as opposed to something
such as art or graphic design of your game.
Future Work
If we did come back to this game, there are a number of aspects that
we can add to make our game more interesting. Since this class is only a
quarter long, we did not have the extra time to include features that we felt
weren’t as necessary for our completed version, we were focused on
creating a 100% complete legitimate and fun game.Through play testing, we
have found that players wanted specific objects in the game such as a
variety of weapons and it is a good idea to implement this to create more
diverse play. Some weapons that can be implemented could be a machine
gun or a rifle, each with a limited number of ammo and speed for strategic
game play. A fairly new implementation to our game is the working napalm
and the health bar. In our final game prototype, we had the time to
implement a boss that appears after a set number of seconds and gets
harder as time goes by. With more time, we can go into the detail and
artwork and take time making different types of bosses that appear, each
with their own number of health points and difficulty as the game
progresses. Of course by making the bosses, we understand that they have
to fit into the story of our game of a commando and enemy lines. Possible
additions to the bosses could include a military jet or an enemy on the same
land that you are on, shooting missiles or throwing grenades still seeking to
destroy the opposition, you. An interesting addition to the game would be
heat-seeking missiles. We took time considering heat-seeking missiles,
however we felt that it wasn’t as important as finishing the health bar or
implementing a boss. We would need to implement code for the missile to
rotate and follow the position of the commando or the main character. If we
had an extensive amount of time, we would look into physics and
gravitational force. We wanted to implement that when a bullet hits a bomb,
the bomb would bounce off and move to the direction it was hit.
Sub-goals would be an interesting aspect to our game because of all
the objects being thrown at you and the speed of the game. A possible subgoal is get a chain bonus. So if a player destroyed x amount of bombs in a
row, a counter would go up showing the number of bombs. At a certain
number of bombs in a row, the chain would disappear and the player would
receive an additional amount of points to their score. Another sub-goal that
we have looked into is receiving power-ups or health packs. If we had more
time, we felt that it would possible to add health packs for our player when
he or she is low on hyper points. Destroying enemy bosses would in fact
drop these packs and be an incentive for the player to continue of their
verge of outlasting the bombs. We could also drop new weapons that they
can yield to their advantage.
Games with the best graphics, and not necessarily the best gameplay,
do tend to be very popular. With an extensive amount of time, we could
redraw and recreate all of our graphics to make the game more interesting.
We could also add sound effects to the game and change the music in the
background so that the music won’t be as repetitive.
There were many aspects that we could have implemented if we had
more time. However, our plan throughout the whole project was to create a
fun and challenging game that was playable and creates meaningful play, all
in the time of one very busy quarter.
Conclusion
In summary, each of us have our own skills, and we demonstrated
that as we designed our game. Some of us had more knowledge in
Actionscript, while others had more in writing or art and we needed to
implement them to be successful in our project. We assigned each person a
job to do, but ultimately, we needed learn how do do each other’s jobs as
well.
You should play our game because it took a lot of gut, sweat, and tears to
develop, and some other projects may have suffered and bled a bit to give
you the freedom to play such awesomeness. All in all, big things are not all
that hard to do when you have a bunch of people willing to do what it takes
to get the job done. And when the job is done, the product is all the better
when you have new and better friends to enjoy it with!