Making Games: Pumpkin Man Beach Blitz Part 1
Last weekend (not two days ago, but 8 days ago), we decided it would be a good idea to make a second version of Pumpkin Man for Halloween. It started off as quick re-skin with the hero negotiating a beach setting to rescue his girl from the clutches of evil. After sitting down with Mari and Steve for a GAMESTORM, I decided that while it would be EASY to just do a re-skin, I was sick of the Pac Man style control and confinements of the Pumpkin Man engine. One game play element that I had left out of the original was the ability for the hero to pick up a weapon and shoot his way out of trouble. So, with that in mind, instead of the relatively simple re-skin they wanted, I set about to make more changes to my game engine than were necessary to transform Rugby into American Football.
I was very happy with the control mechanism that I put into the original Pumpkin Man game. I did exhaustive research on the original Pac Man and all of the web versions available before I implemented my control scheme. The original Pan Man had “power assisted” turning. The the main character could negotiate turns much easier than the ghosts chasing him. I implemented my version by having the keyboard buffer remember the last key pressed that was not the same as the direction the player was moving. That way, even if you pushed up (for example), even if up was not a possible move right then, as soon as you could move up, you would. Also, I let the player change directions as long as 75% of his body was in an open passageway That made for quick turns and an overall fun experience (at least to me). One other thing I held over from the original Pac Man was forced velocity in one direction until the hero hit a wall, or changed direction. Even if the player took his finger off of the key in the direction is was moving, the on screen hero would still move in that direction until obstructed. Also, as in the original Pac Man, I made sure the player could only face in an open direction, and could not turn and face a closed wall. All of these were necessary to re-create that Pac Man experience, even though the eventual game had more play elements that the original. I love working within constraints, it gives me an overall goal and something to strive for.
I started the Beach Blitz version with a new set of games in mind – Gauntlet and Wizard of Wor. In those games, the player can move freely about the maze, can turn in any direction, even those he cannot move in, and his velocity is NOT constant until he hits an obstruction. Also, the hero can blast his enemy to smithereens. I started to code these changes and found all kinds of early AS3 goobly-gook that I had thrown that needed to be removed. I replaced old movement related switch statements with an array of booleans representing all of the char() codes for the keys. The standard key listeners for up and down place a true or false in the appropriate array element corresponding to the ASCII value for the key press. In my main loop, I check that array (this time with a switch) on each frame tick and move and or shoot missiles based on the true or false settings for the arrows and the “z” (for firing).
Collision detection became a a major headache. Now that the player could move in any direction, I had to move from one math generated “look ahead” point for tile-based collisions to three look ahead points. I needed to be able to make sure that the player could not move onto a tile edge, but that also makes moving about the maze difficult for the user. I have yet to mitigate that problem, but I will probably space the three look-ahead points closer together to allow slight edge-crawling and result in a overall easier to maneuver experience.
Firing the Missile
In Pumpkin Man, as in Pac Man, there were power-pellet style candies that would allow the hero to chase the enemy in the maze. Beach Blitz does away with that and adds a rapid fire cannon to the hero. The cannopn will be upgaded by eating the power pellets. That has forced me to do a lot of code changes. First, I needed to create a missile pool (as well as a Missile Class) and all of the associated GamePlay class updates to accommodate firing of missiles (an aMissile array,etc). The Missiles receive the same update() and render() events as the player, ghosts, and animated tiles, but collision detection became the real problem. I tried EVERYYTHING possible to get the missiles and the enemy to collide to no avail. Mind you, the entire game is Blitted to ONE display object, so regular hitTestObject was not an option. I tried pixel based BitmapData checks and also bounding box checks and none of them seemed to work at all. I finally figured out the problem when I traced out the width of my enemy and my missile to find that I had never populated those attributes with any data, and thus the length and width of each bounding box (and Bitmap Data hit rect) was always 0. DUH! I then added in an offset and hitwidth and hitheight attributes to the missiles and enemy classes so I can modify that collision box when needed. Anyway, it took me until last Friday to figure that part out and so I am am under the gun to get this code completed and new assets integrated by Oct 20th.
Here is what is on my current TO DO list. I’m sure it will get much bigger.
1. Gun upgrade path and messaging
2. Missile hitting walls and explosion
3. Finish level by rescuing the princess
4. Can destroy enemy generators
5. Enemy generator health bar
6. Can’t shoot enemy until they start moving
7. Change bonus needed
8. New instructions
9. New layout – get rid of timers, and put in ammo count and gun level.
10. Use Bratney “Safe Timer” for when “KILL” has been collected.
11. Re-do power-ups
12. Make new levels
13. Update the enemy and missile pool code
14. Add in advanced game timer
15. Explosion object pool