Previous Next

Look, this is just getting really silly, okay? I'm going to make things really easy for all the programmers out there from now on. Here is the Simon Forrester definitive guide on how to write a scrolling-bloke-killing-things game that'll actually pass review stage with flying colours. This guide was written with reference to a certain game whose name can be found elsewhere on the page (in very big letters).

1. First off, always make sure you have a concept. A concept is an original game idea that separates £3.99's worth of cassette from the one next to it. Never, ever just place a man with a gun on hostile terrain and leave the rest to the player's imagination.
2. Consider the bad guys. You have a choice here - either place thousands of them in the game and make them ludicrously easy to kill, or just scatter a few around and add a little challenge. It would be nice.
3. Difficultly is always an important factor. When a reviewer manages to complete the game on his first attempt (indeed, his first encounter with the game at all), you'll find that your final rating drops no end.
4. Obviously, you will always have to restrict the player's access, keeping him on the main playing area, not allowing him to wander clean off the screen. This does not mean, however, that he should ever be incapacitated by an invisible barrier. It's cheap, and very tacky.
5. End-of-level guardians should be just that. Killing an end-of-level guardian should never be just as easy as everything else. If you simply add a large sprite and allow the player to kill it in a matter of seconds, the reviewer will most likely pass out.
6. Just a small point here, but people do own Plus machines. Plus machines do not have a tape counter. Adding a software tape counter (Firebird style) would probably be a Very Good Thing.
7. The general public is intelligent (okay, if you've ever watched Beadle's About you might have your doubts, but nevertheless I stand by my statement). They will notice when the terrain and playing style of each level (bar about two) is identical, even if you have tried to disguise the fact with a few graphical tweaks.
8. Try and keep some kind of logic to barriers. This means you should never have a scenario in which the player is perfectly capable of strolling up a cliff approximately the same height as them but cannot step over a knee-high steel loop. It's just not cricket.
9. It's usually assumed that the player's character is intelligent, and knows what a brick wall is. This doesn't mean it should to do all the playing for you and refuse to bump into the walls, just that he shouldn't stick to them when he does - he should turn and walk parallel to them instead. Programmers with a psychological aversion to intelligent diagonals never get far.
10. If you put an open doorway in a building, or a wide archway in a burnt-out wall, please make sure the player can walk through - what's the point in drawing it if he can't?

I could be here all day, so you'll have to use your imagination for the rest of it. Don't get me wrong - Mercs isn't the naff game of the century, it's just a run-of-the-mill romp with a few too many bad points.

Graphics 57%
Badly drawn, garishly coloured, and totally unconvincing sprites.

Sonics 40%
Abysmal spot effects - enough to make you stop shooting totally.

Grab Factor 55%
Moderately interesting for about the first 30 seconds or so.

Staying Power 35%
Holds about as much long-term appeal as a rotting haddock.

Overall 47%