| geocities main | times square | Index |
| Vic-20 | DOS | X11/Unix | RiscPC | Ideas | e-mail me |
| Introduction | Theory | Guidelines | Analysis |

Analysis of Dodge'Em

As an illustration of the issues described above, consider the game Dodge'Em (screenshot). I've never played Dodge'Em seriously until I ran into it again recently. I used to find it too difficult and frustrating for serious play. In this game, you control a car, driving anti-clockwise, which has to pick up all dots. The movement of the car is restricted: it cannot turn, and can only switch lanes inwards or outwards at one of the four open spaces, up to two lanes at a time. The car can also switch between two speeds using the fire button. Driving in clockwise direction are one or two enemy cars, which try to ram you. These can only switch one lane at a time. In its time, many clones were made of this game. However, this game has very few recent descendants. This game has been re-made some time ago. However, like most remakes, it was mostly a reference to the old game, a reminder of the good old past. The concept has not been varied upon or improved in any meaningful way.

While playing the game, I have made the following observations. Firstly, it is necessary for your car to be able to switch at least two lanes at a time. If you could only switch one lane, you would have to switch at the last possible moment, just after the enemy car has passed its last open gap before approaching you, and thus its last chance to follow you into the lane you have switched to. However, it is nearly impossible to time the approach of the cars to the gaps in such a precise manner. The solution: switch two lanes at a time, so the enemy is too slow to follow. Secondly, there are some interface difficulties. To switch to a specific lane, you have to push the joystick in the direction you want to go. However, since the board is circular, this direction is different depending on where you are. This is especially a problem in the inner lanes, when the car makes quick circles. A second difficulty is that switching is deliberately restricted to 1 lane at a time when driving fast. The solution is to release the button just before switching lanes. I think that both these problems may be considered interface problems, and should be eliminated. I propose the following interface: since there are only four lanes, the interface may consist of four buttons, each standing for one of the lanes. When the user presses a button, the car tries to go to the lane specified as far as this is possible. Further modifications can be made: the action is probably easier to view when the lanes are represented as four straight lines which wrap at the edges, rather than a square or a circle. Note that the cars would then have different speeds in the different lanes. After making these modifications, we are closer to the essence of the game. Now, we should implement this new interface and make further observations. Is the new game as much fun, or does it turn out that the author had good reasons for making the game exactly as it was? Is it easier to time your lane switch? Is it still necessary to be able to switch two lanes at a time? How much thicker and faster can we make the action now that interface problems have been eliminated, e.g. how many extra enemy cars can we add before the new game becomes too hard?

I have implemented a prototype. The main objective was to have two enemy cars which both home in on the player. As far as I know, the original did not have this. I think the game is more fun with two enemies. The game becomes more varied and challenging.

Development took me about 3 days: one day for programming, and two days for playtesting, and learning to play my own game! Who said designing games isn't like playing games?