deeperbeige.com

Use the mouse to control Reepicheep the heroic mouse in this tricky skill game. Click somewhere above Reepicheep to make him leap towards the mouse. In the air, move the mouse in-front or behind him to apply aftertouch to your jump’s path.

Collect powerups to jump further, have more control in the air and gain extra lives.

Postmortem:

This game is one I rather like personally. It’s got on of my favorite things in a computer game – a tactile main character. By that I mean you have a certain subtlty and finesse in the character’s control that rewards patient learning and practice.

Unfortunately, these things are exactly what web-game players typically don’t want to do. They want to leap straight in and be acceptably good at the game, not to fall off every branch with no idea what they’re doing wrong.  If a random web player can’t get into the game straight away, they’ll almost certainly go elsewhere. There’s no shortage of other games out there to play.

A second issue caused trouble with this game too. Compounding the fact that it’s a pretty tough game was the fact that the client kept wanting more difficulty added to it. First it was extended to be considerably longer (which wasn’t a bad thing). Next they wanted to speed the auto-scroll up as time went by (which makes it become very high pressure towards the end). Then they wanted fewer lives and fewer life power-ups (I was generous with them as it’s so easy to die). Then they asked us to add branches that break if you sit on them too long (adding even more pressure and no chance for a breather). Eventually they wanted arrows shooting through the branches at random, which we made a stand against since you have very little chance to avoid them. It’s a game about planning your next move, rather than reacting. Once you’re in the air, you can only make fairly small adjustments. In no way could you dodge fast moving arrows!

Finally, when we discovered that lots of people couldn’t get the hang of jumping, we asked the client if we could build a jump preview line that showed the rough path of the jump before you clicked. They were heavily against this idea, dispite my thinking it would help considerably with getting new players to a competent standard rapidly.

Dispite the added difficulty, I still like this game and still enjoy playing it, which is unusual for games I’ve worked closely on. Usually you play a game to death during its development, and are happy not to see it again afterwards. Not so with this one. I still come back to it from time to time to see if I can still perfect those jumps.

The character’s movement comprises a few subtle elements. Firstly, the mouse takes his initial jump direction from the angle to the cursor. His jump force is calculated from the distance, so you can do small adjusting hops, nimble jumps to a nearby branch, or huge leaps across the screen. Then, the spring motion of the branch is added onto that initial force, so you can time your jump with the release of the energy in the branch to go higher or further, or the opposite – and do a minimal jump. You can leap up through branches then land on them, or leap down through branches to a lower level and add energy to your next jump. In mid-air, there’s an affect of aftertouch where Reepicheep has a slight acceleration towards the mouse cursor, so you can bend and curve his jump after you’ve taken off. You can power up all these abilities too, with the pickups strewn around. Finally, if you get to the right hand edge of the screen you can push-scroll the level, so it’s even possible to speedrun the game!

Collision detection was an issue in build. Branches are necessarily thin things, and the character moves necessarily fast! Tunneling through branches is simply unacceptable in this case as you’re depending on hitting them for survival throughout the game. The solution was to scan every pixel between Reepicheep’s previous position and his next, and test each for collision with the branches so that you collide with even the thinnest hint of a branch. To keep everything running well, the forrest is divided into lots of short segments, each is attached to the stage just before it is needed, scrolled through view then removed as it goes out of sight. Only branches in the current segment are tested for collisions of course. New segments are attached automatically when required, and each segment contains power ups right there on the timeline as required. A discovery algorithm runs searches through instance names at runtime as segments are attached, learning what items exist and setting them up as appropriate. This works really well, and far better than having metadata in the code that has to be kept in sync with what’s on stage, or worse, coordinates for powerups stored in the code. It’s just so much easier to adjust – you just chuck a new powerup on stage from the library, and give it an appropriate instance name. Recompile and it’s there in the game, functioning.

The final part of the forrest contains a large treehouse that you make one final heroic leap to, then squeak your important message to Prince Caspian directly. Granted, not many people are going to get this far as it’s a pretty tough game, but those that do should at least feel like there’s a proper conclusion, a bit of a point to it all. As a game developer it’s easy to overlook how important this is as it really adds nothing to the gameplay mechanic at all. It’s just a big bitmap and some special case coding at the end, rather than a different challenge etc. It’s hard to justify why we’d want to build it, but the feeling of closure and reward for the player is immesurably important.

Lessons:

• Tricky yet rich control mechanisms aren’t generally a good idea. Extensive user training is required, which most people won’t bother to work through
• A proper end goal is a great way to finish a game. Just cutting at a given point really isn’t! This one does it well, with the final treehouse with Prince Caspian being a really solid final point
• The Flash IDE is still a great level design tool