Andrew Caddell

Raymond Ching

Mark Corpuz

Ravi Kurma

Anthony Valdez

Dr. Haungs

CPE-123 Milestone #4

12/4/2010

The Adventures of Ball-E

One day, Ball-E decided to go out and have a picnic at the park. He took a nice stroll and enjoyed his meal. He decided to pack his favorite cake for desert, but was too tired and full to finish it right after his meal. So he decided to take a nap and eat it when he awakens. As he drifted into a deep sleep, he didn’t notice the shadowy stranger creeping up. Once Ball-E was sleeping the stranger leapt into action, stealing both Ball-E and his cake. Ball-E later awakens and finds himself in the middle of a volcano! Ball-E doesn’t know what happened or how he got there, but he does know that he wants his cake back. Thus, Ball-E begins his great adventure through this strange and mysterious world, to find his beloved cake.

The player controls Ball-E, the round and lovable hero of the story. The player uses the left and right arrow keys to move left and right respectively. The up arrow is used to jump. The up arrow is also used to swim in underwater levels; it must be repeatedly pressed in order to stay swimming. In order to start a new game, the player uses the mouse to select “Start” from the title screen. After the story is presented, the player is put right into the action. If the player dies they will be prompted with the game over screen. The player can use the mouse to select “Restart” to restart the game from level one, or select “Restart Level” to restart the current level. The player jumps from platform to platform, while avoiding deadly obstacles such as venus fly traps and buzz saws. The player must travel through portals in order to reach Ball-E’s precious cake.

Design:

Meaningful play:

Meaningful play comes from the interaction between players and the system of the game and how it is played. It is based off the choices the player is able to make in the game leading to the actions (the changes) in the real game being played. There are certain levels in which the player may choose a certain path, and one way may be easier than the other. The player must also choose how/when to overcome certain obstacles.

Narrative:

The narrative of the game comes from the comic strip scenes shown at the beginning of the game. It is an embedded narrative that explains the conflict of the game. It shows the story on how Ball-E and his cake are taken by a mysterious figure while Ball-E is sleeping at the park. Ball-E then wakes up in an unknown world stuck in a volcano without knowing what to do. He then goes off on a journey to find his cake and get it back; this reveals the goal of the game. The goal of the game is to pass all the obstacles in favor of finding Ball-E’s cake. To do this Ball-E has to go through the many portals that the mysterious man left to get to his cake at the end of the game. This gives the player a reason to control Ball-E and try to get his cake back.

Game Play:

The game play lies within the actual game and how it responds to the actions done by the player. In The Adventures of Ball-E we have level-to-level switching to add visual effects to make the game feel more real to the player. The different terrain and obstacles on each level correspond to the different backgrounds in the certain levels. For example, in the jungle level, there are green platforms and venus fly trap enemies to go along with the backgrounds theme to the level. Our game play is seen by the motor actions of the player. If the player has better responses to the game, the faster the level will be done and the game will end in success; but if the player lacks the skill to press the buttons the right way, the game will send the player back to the beginning of the level. The game is set with the same obstacles and platforms (in most stages) allowing the player of the game to learn the patterns that lead to the correct way of going through a stage without dying. Learning these patterns make the player of Ball-E concentrate on the level at hand creating focus on the game. All of these aspects in the game play give Ball-E meaningful play as it allows the player to understand the interactions in the game based on what the player has done so far.

Conflict in the game:

Ball-E is a game that is player vs. game system, where the player has to beat the game world to finish the game.

Uncertainty:

Uncertainty in games helps achieve meaningful play. We added uncertainty in our game with the different controls we give to the player. The player is able to move left and right causing them to make a choice on which way to go. There is also a jump function that lets the player decide when and how he or she would time a jump to get over an obstacle or get to the next platform. We also used probabilities in our game with the use of Math.Random in areas of the game. Uncertainty also comes from the player’s willingness to finish the game or the player just giving up. The information given in the game also accounts for some uncertainty, as we don’t give the player all the information at the beginning of the game. There are parts of imperfect information that the player will find out after playing the game for a little while. This is apparent in the side-scrolling aspect of the game as only a portion of the map of the game is revealed to the player, but as the player moves in game, more of the map will be shown so the player will know when and how to maneuver around the many obstacles in the game.

Type of player game:

Ball-E was created for the standard game player or the casual gamer for its intention to keep all rules solid without changing any of them in the middle of the game. The game has its rules set so they cannot be broken making it a game without cheat codes nor any forms of hacking in the game. There are no ways to implement cheating in Ball-E.

Core Mechanic:

The core mechanic to the game of Ball-E is controlling the arrow keys to move Ball-E around the levels to reach the next level. Also, jumping with the up arrow key to avoid obstacles and reach other platforms

Flow:

Flow in any game is the emotional and psychological state of focus and happiness brought on to the player by the game. In Ball-E we tried to make it so that player skill and the challenge of the game was not incredibly hard or incredibly easy in a way – a proper mix of the two was to be achieved. In the game we added easy levels in the beginning of the game for the players with little or no platformer game experience to test the water. As the player gets past some of the earlier levels, they become increasingly harder. More obstacles and platforms are added in the later stages so that the game won’t end really fast and so that it would stimulate the minds of people trying to find the strategy to beat the level and eventually the whole entire game. In Ball-E the thought for the easier beginning levels was to get the player into the game so that they would be stuck to it for the harder levels creating the perfect mix of anxiety and boredom in the later levels of the game. Challenges were inserted in the level design to trick the player on which way to go and when to jump giving the players more to think about in the real game.

Conditioning:

In the game of Ball-E we add many parts of that condition the player with positive or negative reinforcements that include punishments throughout the game. A positive reinforcement in the game comes to play with the reward of access to the next level. In the game after the player passes obstacles to get to the next stage by way of a portal. Punishments are frequent in the game. As a player dies in the game, they are sent to the “Epic Fail” screen showing their demise in the game. Dying comes easy in Ball-E as it is just when the player makes contact with one of the many obstacles of the game or falls off the screen. This also brings in some positive reinforcement into the game as when the player dies, because there are no lives in the game, the player has the choice of either starting the game over from the beginning or starting the game from the beginning of the level that they died on. This makes trying to beat the game easier for the player as there are unlimited lives that the player could utilize while playing the game.

Implementation
Organization:

In our game, we have the Document Class which is the big class that adds all the levels, the GameOverScreen, the YouWin screen, and the comic strips at the beginning, as its children.

As an overview, the Document class adds a Menu Screen, and then once the “Start Game” button is pressed, the Document Class will start to bring up the opening comic strips. Then the Document Class adds the LevelX code. The level codes addChild( ) the platforms which make up the level, any obstacles that are in the given level, and the portal that signifies the end of the level. When the ball touches an obstacle, an event is dispatched to the BallEvent Class which converts the event into a string which the Document Class recognizes and causes it to run an onBallDeath( ) function. This function adds the GameOverScreen. If the ball touches the portal, then a separate event is sent to the document class to add the next level, while removing and nulling the level that was just completed. The process is then repeated until the last level. At the final level the player is sent to a YouWin screen. See Figure A for a visual representation of this overview.

Figure A

Obstacles

In the GameOverScreen, two buttons are added. One button allows players to restart from the very beginning of the game. The other lets players restart only the level they were on. Both buttons have a separate event listener placed on them, which are just listening for their specific button to be clicked. For example, when the restart level button is clicked, the listener recognizes the click, and calls for a onClickLevel( ) function. This function dispatches a navigation event which goes to the Navigation Class. This class sends a string to the document class, which causes it to run the restartCurrentLevel( ) function. See Figure B to see how this example works.

The comic strips are all added by the Document Class also. We have a “Next” button in the shape of an arrow which causes the document class to start the next scene and remove/nullify the last one. It is a one-step process which does not require its own diagram. Also, the YouWin Screen is just a single screen. It follows the same coding pathway as when you are progressing to the next level, except when you touch the last portal it opens up the YouWin screen rather than another level.

Figure B

Game Objects:

The most influential symbol in our game would be our hero, Ball-E. He is a one frame wonder, with no animation. Within each Level Class, we entered code to check if an appropriatearrow keyhad been pressed. If, for example, the right key is down, ActionScriptadds five to Ball-E's x-coordinate value. This happens every frame until the key is lifted. We also added gravity and velocity variables to each level. We use these to control the ball's jumping.

Aside from our hero, we have various obstacles moving around our levels. Some of these are animated to appear as if they are rotating. There is an axe that swings in a pendulum motion which was animated in flash, and then the symbol was just added in by ActionScript. Otherwise, we have ninja stars and fire balls that move from one edge of the screen to the other. This is accomplished by first moving the obstacle at a constant speed either up or down. Then ActionScript checks either the x or y coordinates of the obstacle (depending on if the motion is vertical or horizontal) and when it reaches the edge of the screen, the movement constant is multiplied by -1.

One level haslightning boltscoming from the sky, which are obstacles but are handled differently from the rest, so they deserve a special mention. We used this level to introduce some randomized danger to make it so pros would not be able to just memorize which timings worked and breeze through our whole game. We created an army array the same as was done in the Avoider Game tutorial, using math.Random to determine when alightning boltspawned, as well as where it happened.

There is also a "platforms" symbol for each level, which is added by the level class code. These just sit there and give the player a way to traverse the map and avoid obstacles.

Our last game object is the portal which players touch to advance to the next level. This portal is added by the level it is in, and does not move at all. There is a PixelPerfect collision detector we added that dispatches the navigation event which causes the next level to start and removes the previous level.
Major Issues:

Our biggest problem over the weeks was understanding how programming worked. We had to restart twice before we got our variables named correctly and in a way that worked. Once that was done it was relatively smooth sailing as we all became more comfortable with our programming space.

Another big issue was getting the ball to jump. Even once we got that working, it took a while to get the jumping to look nice and even, and then we had to change the height of the jump, and the speed with which the player falls back down after jumping to make finishing our levels possible.

It also took a while to discover a way to allow players to restart from the level they died on. We struggled with this for a couple weeks before just asking for help and getting what ended up being a creative and easy solution.

The final problem big problem we encountered was trying to get the screen to scroll so we could make larger levels and not reveal all the level information perfectly right from the beginning. Eventually another group helped us to solve this problem.

Iterative Development:

All games go through a specific iterative design process in order for the game developers to determine if their game achieves meaningful play. The generic steps that the designers go through are prototyping, play testing, evaluation, and refinement. Prototyping is the process that the game developers go through as they write code and create the game’s characters, levels, and other aspects that go into the game itself. The prototype includes the game rules and the core mechanic that the players will have to use repeatedly to progress through the game. There may also be some of the storyline incorporated into the prototype to give the player’s a glimpse at more of the meaningful play that will be merged into the final product. The next step is the play testing of this prototype by regular people instead of by the game designers who already know how what tactics to use to complete the game in the easiest manner possible. By using other people to play test their games they are able to see if certain aspects of their game are too challenging or too easy. The developers’ observation of the players allows them to complete the next step of the process which is evaluation. Designers listen to the feedback of the play testers and gain insight by observing them when they play. If the players become frustrated with the game or are bored from the lack of the challenge with the game, then the designers know that they need to make changers to address the skills of the players. It is better for developers to observe more play testers playing their prototypes so that they can get a larger base sample to base their decisions off of. After gathering their notes and coming up with ideas to make their games better the designers go through the next step of refinement in which they actually implement the changes into their prototype to address the issues that the play testers had with the game. The refinement could be the changes in the levels within the game, the controls, player movement, or small tweaks with other aspects of the game. The changes that are implemented into the prototype can often have drastic changes on the gameplay as well player experience, and it is for that reason that this process is repeated beginning again with a working game prototype, and progressing through the stages of play testing, evaluation, and refinement as the developers try and achieve meaningful play within their games and create an entertaining game for their consumers.