Whatever happened to the block game?

Regular readers will recall that I intended to build a simple dodge-the-blocks game as a testing ground to measure the impact of product-placement style nostalgia cues.

Looks pretty simple, huh?

WRONG.  This has certainly been a very educational experience.  What started as a very simple game has turned into a monster that needs quite a bit of taming.

There's nothing particularly difficult about the game, or implementing it.  It's similar to the training games I've implemented many times when teaching students to use programming tools like Java or Microsoft's .Net framework.  (I often use Pong or Space Invaders clones, because they are familiar, easily constructed as a progressive series of steps, and are good ways to illustrate certain algorithms or programming paradigms.)

However, with my mind now expanded to appreciate some of the wider considerations of game mechanics, I found myself unexpectedly bombarded by decisions which threaten to undermine the whole project!  That's not bad for a small, disposable project which should have taken only a few hours to complete.

Problem #1: Too many options

When you think you know how a game works, it's all too easy to try to jump in to building the game straight away.  Bad move.  As François Laramée points out, detailed design plans are a necessity.

Ignoring these wise words (at my peril) I booted-up the computer ... and then realised that I'd need to write up my project -- and some formal planning would definitely look good.  I started jotting some ideas down on a piece of paper...

As you can see (unless you have bionic eyes you may need to enlarge the image) I started realising that there was more than one way to do each thing.  Examples:

• Should the game be a timed competition?  If so, how does the challenge increase to ensure a good flow?  I'd envisaged making the blocks move faster.  However, this created the possibility of timed rounds, each getting progressively harder (e.g. more blocks, faster speed, or smaller arena).
• Should the enemy blocks travel through each other?  Or bounce off each other?  There's a lot to be said for the bouncing option, because it makes the prediction of movement more complex, and potentially more satisfying for a skilled player.  This could be integrated with the timed round idea.
• How to control the player?  This was a nightmare.  Traditionally, this game uses a mouse for analogue, absolute positioning (i.e. moving like a mouse cursor).  However, what about keyboard control?  This could use constant velocity (like Pac-Man), subtle acceleration/deceleration (like Defender) or thruster-style control (like Lunar Lander).  This technology choice changes the whole gameplay.
• Where to show the timer?  (Or whether to show it at all?)  If the player is checking the timer, like the driver checking a speedometer in a car, they are taking their eyes off the game.  This is the norm for this game, but what about putting the timer on the player's block?  This would allow greater focus, leading to potentially greater satisfaction.  However, it might reduce the challenge.
• How to conclude the game?  Do you display a simple "You lasted X seconds" or do you do a coin-drop tease to encourage them to play again, metaphorically slapping the player around the face with the gauntlet of the current high score?

And that's just the start.  Course tutor Josh Taylor noticed that horizontal-movement-only enemy blocks will push the game into Frogger territory.

In this case, with the original purpose in mind, I have decided to ignore the possibilities of making the game mechanics more interesting, and lock the game down as I remember it from playing it many years ago.  But that's quite a wrench, as the designer in me wants to make it better!

Problem #2: Change of mechanic

The idea was to create three variants of the game:

• Plain, with coloured blocks.
• Same game, but with old sweet wrappers as an aesthetic.
• Same game, but with a visual theme and back-story based on the movie Dodgeball.

In the back of my mind, I knew that I'd need to use dodgeballs as the enemy for the third version.  However, balls are not rectangular.  I could enclose them in a solid rectangle, but this detracts significantly from the mechanic of the dodgeball game itself.

So, should I use circles for the enemy on this version?  Should they bounce off each other?  Does this change harm the subjective experience comparison, or enhance it (by reinforcing the theme)?

This presents a dilemma.  By reinforcing the theme I would have to change the underlying game mechanic.  And that would definitely change the subjective experience, rendering my experiment invalid.

I've decided that the implementation of the theme is vital to the third option, which has forced me to step back and reconsider building a different game -- working backwards:

• Dodgeball-themed game, with bouncing (circular) balls -- all the same size (another option!) -- and circular player object (featuring picture of Vince Vaughn), set in a rectangular arena.
• Same game but without the backstory, using rounded cutouts of sweet wrappers, with enough of the logo (or visual identity) on display to trigger a nostalgic reaction.  Circular player object.
• Same game, but pared down to simple coloured circles.

Conclusion

I've been astonished how much my original, simple game has had to change just because of the temptation to improve it.  This echoes the warning issued by John Dennis about overambitious projects.

Hopefully, now, I can get on with some research into the effect of visual nostalgic cues!