Games Assignment 7: Improved Platformer

Due Tuesday, April 6 before class

In this assignment, we'll be modifying the book's platformer code (available here as A3GPU11_PlatformGame.zip -- please support Rosenzweig's efforts by buying the book!) to make the game more interesting. The character will be able to climb walls, the levels will be a little more interesting, and the monster behavior will be more easily controlled from the level editor.

1. First, we'll add the ability to climb and jump from walls. From a game design perspective, this opens up a lot more possibilities for interesting levels; and from a programming perspective, it'll test whether you understand how walking works, since it's very similar.
   • You'll notice in the code that there's a Boolean field for the hero called inAir, which checks whether the character is in the air; this affects how the character moves and is animated. Similarly, add a Boolean to the hero called "climbing." Whenever something works differently for climbing versus other states, we'll check whether climbing is true. It should start false.
   • We want the character to be climbing if he jumps into a wall. In moveCharacter, the values hitWallRight and hitWallLeft are calculated. If inAir and one of those values is true, set inAir to false and climbing to true.
   • Find where gravity affects the character, and make gravity ineffective if we're climbing. In testing the movie, you should now be able to jump and stick to a wall.
   • Now we'll add the ability to go up and down. Go to keyDownFunction and keyUpFunction, and add some code analogous to the movement code already there that checks for keycodes 38 (up arrow) and 40 (down arrow), setting some variables named moveUp and moveDown appropriately. Then, in your climbing check where you decided to ignore gravity, set verticalChange instead to be proportional to timeDiff * climbSpeed, moving in the correct direction (recall that y increases going down). (You'll need to define climbSpeed somewhere appropriate, of course.)
   • Your code now probably allows the character to airwalk off the wall. Figure out how to fix this. Likewise, add a check in moveCharacter for whether we've climbed too far up or down -- hitWallRight and hitWallLeft will both be false -- and change the state to inAir instead. You might consider adding a little bump in Y if the character is moving up and reaches the end of a wall, which would allow a character to climb to the floor above if there's one there; but this is not required.
   • Now we need to add some climbing animation. Use "Insert Keyframe" on the hero to add 2-3 frames of animation for climbing. (These don't have to look that great -- mine don't!) Name the first frame "climb" in the Properties window (right-click, Properties) so that we'll be able to jump to it in the code. Study how the walk cycle works in the code, and add some analagous code that will cause the character to cycle between your climb states while moving and climbing. Notice that adding a climb cycle to the middle of the hero's timeline will throw off the other arrays, so fix them if that happens.
   • The book code makes the character rotate while jumping, so you'll probably want to set the rotation to 0 when you begin to climb. You can also just turn off this rotation; it's kind of silly.
   • Also, make sure normal enemies don't enter a climb state when they hit a wall; notice that moveCharacter is called for them too, but only your hero is allowed to be a ninja.
   • To complete the ninjafication of your character, add the ability to jump from the wall. Study how a normal jump works, and add some analagous code that will cause the character to spring away from the wall (ie, with a horizontal velocity component) when the jump button is pressed while climbing. Change the character's direction as well, so that the character is facing away from the wall.
   • The character can now climb out of the existing levels ... but there's currently no default behavior for falling infinitely, which is what the character will do if he climbs out of the level. Kill any characters that fall beneath the bottom of the screen. (You should kill them when they're at least a full character height beneath the screen, maybe more, so that the player doesn't see a nonsensical death animation.)
2. Now that we can climb and put bottomless pits in our levels, let's make a level that takes advantage of these facts.
   • Make a new keyframe for your game's main timeline, and shift the others over. Move the Actions (View/Actions) of the original starting level to this frame, and name this frame "play" so that the splash screen's action works.
   • Draw a background, and export it to an object called Level 0. Make sure the registration point is in the upper left, or scrolling won't work correctly. Double-click on your level so that you're adding children to the level instead of the main timeline, and plunk down a Hero and some stuff from the Library, just to try things out. Name your level "gamelevel" and your hero "hero", so that the code can talk about these things correctly. At that point, you should be able to walk around your level a bit.
   • Once you've tried out level editing for a bit, it's time to get serious about level design. Make 6 layers for your level 0 object. From bottom to top, they are:
     • Monster Guides, hidden behind the background; we'll get to those later.
     • Background -- the game background that everything will appear in front of.
     • Stuff -- all the game objects like Walls and Floors and things to collect.
     • Window Dressing -- this will hide the ugly blocks your character is actually walking and climbing on, making them look like buildings and trees or whatever.
     • Hero -- put the hero on this layer, so that the hero is never obstructed unless you specifically want him to be.
     • Top Window Dressing -- this is stuff that can float in front of your character, like foliage. To be used sparingly.

     My advice is to start with the Stuff, build a playable level using the boring building blocks, and then pretty it up. You don't want to draw something beautiful, only to find the hero can't jump high enough to complete the level.

     Two useful tools to be aware of are View/Grid/Show Grid, which overlays a grid on your level, and View/Snapping/Snap to Grid, which ensures that the blocks you place will be lined up with each other.

     You can keep the basic setup of Key and Door, or toss it, but there should be some way of progressing to the next level.

     You must include at least one wall that can be climbed, and at least one enemy. Be sure your enemies follow the "enemy1", "enemy2" naming convention, since the code cycles through these names when setting up the level.

3. At this point, you've probably noticed that the monsters are stupidly wandering off the ledge to their doom. Let's improve the monsters now.
   First, make sure the monsters die when they fall below the screen, as with the main character.
   • Make an object called MonsterGuide, which is just a thin line. Drop them wherever you'd like a monster to turn around. In the code, in examineLevel, add MonsterGuides to the fixedObjects, along with the walls and floors.
   • That was sufficient to make the monsters turn around, but now the guides also block your character! Fix this by having the code "continue" in moveCharacter whenever we're checking for floors instead of walls, or when it's a wall but the character is not of the Enemy class.
   • Finally, set hero.jump to true whenever the hero kills a monster, to add a satisfying spring in the hero's step.
4. Final touches.
   • edgeDistance, a variable used in the function that makes the screen follow the hero, is currently a little lame, since it doesn't let the character see very far ahead. Increase it so that the player can see farther ahead.
   • Choose one powerup to implement for your hero. Hi-Jump Boots, temporary invincibility, and a stopwatch that temporarily stops all the monsters are all good bets. (Change from the original assignment: Designing a second level that makes use of this new item is optional, though it's a nice way to have a stab at S rank.)

A flawless execution of all of the above steps is sufficient for an A; changing the animations for the characters is not necessary. For the S ... well, impress me. But keep in mind that S's have to do everything A's do, and more -- hit all the bases first, before going over the top.

Zip your creation and send it to the Drop conference... or if FirstClass complains, e-mail it to me.

Have fun!