When is it a good idea to follow through with a game design idea, investing the time to implement, balance and create assets?

And when should you acknowledge that a feature is not working the way you had hoped, and might even be detrimental to the game?

I had to make this decision recently for Rubberband Racing, the 3D Flash game I am currently developing, learning a couple of interesting things in the process of doing so.

Limiting Factors

There are several limiting factors for the game design of Rubberband Racing, which are owed to the fact that I want to keep the development time as short as I can.

I’m hestitant to invest time into elaborate features without knowing whether my audience will like the basic game mechanics and setting.

• There will be no multiplayer mode

  While this might be risky for a racing game, implementing a multiplayer mode would mean that I had to develop (or find), test and maintain a game server which is capable of providing real-time gameplay.

  The Flash player doesn’t allow peer-to-peer connections, so going that route is not an option.

  Not only is maintaining a backend a cost factor, but getting it to run can be time consuming.

• There will be no NPCs/AI cars

  Implementing a racing AI would be a fascinating task, but I estimate it would blow up the development time by a great deal.

  Creating the necessary metadata for the AI, bug fixing and testing can easily take up weeks, depending on how much road blocks you encounter.

Spicing Up Gameplay

If I’ll neither have a multiplayer mode nor NPCs, then what is there left to challenge the player with? I suspect that only driving around in circles trying to score better times would get old very fast.

The original idea was to have the player collect pellets with his car. I already mentioned that feature in my article about heatmaps.

The idea was to have separate trails of pellets on the track.

• Each pellet that is collected by the player would either grant score points or a time bonus.
• If the player collects all pellets in a certain trail, he would get an additional bonus.

At first this seemed to be a logical and easy way to give gameplay an additional dimension and to motivate the player. Also, the trails would provide the player with hints on how to find the racing line.

All in all, it seemed like a pretty good feature.

Having Second Thoughts

I experimented with the placement of the pellets and had some success in streamlining the path players would take.

Still, it didn’t feel right. In fact, the feature made gameplay a little frustrating.

My suspicions became worse when I deactivated the pellets after a while, and had the feeling that the game was more fun without them.

I set out to find out why that is.

To entirely clear a trail of pellets, you needed to steer your car very precisely. Even with well placed trails and a good amount of practice, it’s easy to miss one or two pellets due to not following the path accurately.

There was a discrepancy between the margin of error the track design suggested and how much players could actually veer off of a certain path without failing the challenge posed by the trails.

As players will want to complete the course as thoroughly as possible, missing pellets in the trail will feel like a blunder, even if the car stayed safely on the street.

This considerably narrows the path that the player would consider “successful” or “correct”.

Conclusion

It came down to the fact that the feature didn’t diversify the gameplay or offered more options, but actually limited the player.

Also, I had to accept that the controls in Rubberband Racing aren’t precise enough to let the player perform such delicate maneuvering. My previous game, Satellite, had a similar problem.

That wouldn’t have been a big problem if collecting the pellets was perceived as optional. But they were a central element of gameplay.

Finally, failing the challenge posed by the pellet trails was in no way interesting. It didn’t make the game more suspenseful or gripping, it didn’t require alternative play styles or decisions.

All of these reasons made this feature more frustrating than rewarding. Even though it felt like an elegant addition to the game design at the time, I decided to discard the pellet trails entirely.

Finding Alternatives

At this point I was basically back at square one. Still, I had realized a couple of things:

• Collecting items or pellets should be, and feel optional. It shouldn’t be the central gameplay element, at least not in this game.
• Failing to collect an item should open up a different challenge or interesting game situation.

This is how I implemented these lessons: Meet the rocket launcher.

The rocket launcher is an item that the player can collect. If he does so, he is granted three shots, which is admittedly much closer to proven gameplay mechanics in games like Mario Kart.

Now, what does the player need a rocket launcher for if there are no other players or NPCs?

The player will encounter a couple of scattered obstacles shortly after the rocket launcher item.

• If he collected the item, he will be able to blow up the obstacles and shoot his way through them. Which, in my opinion, is inherently fun.
• He will encounter a different challenge in case he didn’t collect the item, namely that he now has to evade the obstacles and try no to bump into them.

Both are interesting and engaging situations, making for much more rewarding gameplay.