|
Suddenly you find yourself on the spotlight. You discover a major flaw in your game, and anything you do to try and fix it will start to ripple through all aspects of the game....what do you do? Specially when the game has already had some time in production, the prospect of taking a decision that will (potentially) change several aspects of the core game is scary. However, if you discovered an issue with your core gameplay, its a decision you will have to make. Core design problems are game-breakers, and they should be fixed as soon as they show up.
So generally, when one finds a game design problem your natural tendency is to go straight to the simplest solution. Overpowered weapon, make the player drop it as he leaves the room; walking around is boring, place random enemies around the level, jumping too high, place a ceiling..... These are simple to implement and they are (somewhat) isolated from the rest of the design, so they become reeeaaally tempting. However, there lies its problem. They are patches, they are not integrated with the design and they don't really solve the problem.
.
On the other hand you could try and implement a whole new design; scrap everything, we're taking it again from the top. New design means new programming, new assets, new everything.... but its worth it, to make a fun game. That is until you try to explain the rest of your team why it is that all their hard work is to be scrapped. Iteration is a given in the industry, but with milestones coming up and angry managers demanding to know what's the hold up, you can't restart the project.
So what to do. Well there is a third option....I'll be honest, its tough, its not evident, and it might be tricky to explain. The idea here is to slightly change the circumstances around the problem so it becomes a non-issue. Its much more subtle, instead of blocking the player from taking an action, you make it riskier, you try and dissuade him. I call this an elegant solution.
.
An elegant solution is the one that tweaks the game in such a way as to turn the flaw into a choice. Without forcing the player's hand and without redesigning the mechanics, the elegant solution changes the circumstances under which the player makes his gaming decisions. Don't attack the problem directly, look around it; check the other systems it affects and try and tweak it from there. For example: imagine a 2D shooter where the player has a high jump. This is important because it allows the player to jump onto platform, start combos, etc... However, this is also gives rise to bunny-hopping. You find out the player is able to jump all through the level and not even fire a shot. If you're already in production, go back and change the jump height will be a level apocalypse: platforms will have to be reset, art will have to be remade, months of work will go to the recycling bin. On the other hand you could stop the player from shooting while jumping. Then the game looses part of its essence, it looses action, and the problem still persists.
A third option would be to reduce the horizontal speed while jumping. Sure the player can keep avoiding bullets by jumping, but now he won't be able to advance as fast.....he has now a choice. Now the player can choose: slow and safe by jumping, or fast but challenging by running. Of course, for it to be truly meaningful, there must be some risk on both accounts; maybe you could sprinkle some AA enemies throughout the level. This solution only affects the player and enemy positioning, and it creates a new set of meaningful decisions. This would be an elegant solution.
I know this is not news for you, but I do believe its best to always strive for the best solution, not just the easy one; and its important to hammer home this fact. So often we feel the pressure of production that we loose objectivity on an issue. In the end, its important to remember that just getting the problem out of the way is not fixing it.
|
1. The character control may not feel natural to the player if the difference in horizontal speed is too big between jumping and running. But if the difference is not enough, the "choice" is gone.
2. It depends on the game and/or levels. If part of the gameplay is barely reaching platforms by jumping, reducing the horizontal speed will break your game. But if this is the minority of gameplay, then it's probably okay, as fixing those particular areas won't take long.
3. If a particular level doesn't require too many jumps, players will run through the level anyways and won't mind doing a little "bunny hopping".
It's tricky when you've been in production for a long time. Difficult decisions have to be made. Do I delay the project, affecting the budget, but fixing the root of the problem? Or do I apply the most elegant patch? One can probably find both horror and success stories of each choice.
For a current project, one must take a chance and learn from mistakes. For the future, it's good to test early and often (using external testers). Your playtesters will usually find a way to "bunny-hop" even if it doesn't require actual jumping. If caught early, it's easier and less costly to fix the root of the problem. This is a good reason to build a vertical slice instead of working on all your levels at the same time.
Well I was developing a kind of spaceship racing game , in wich the ships run across many types of scenaries, including big cities, rocky deserts, mountains and so on.
At the middle of the production, It shown to be clear that the fun of the game was the fact that the spaceships could fly at will, not so limited by the track. The track itself was presented as a sequence of checkpoints around the map.
The problem was , As the spaceships could fly anywhere, the world should be huge. and there were no budget for creating so many 3D models for the map. and the engine itself presented some performance limitations.
Unfortunatelly, I "Fixed" it by preventing the player to travel to a certain limit of the map. Upon reaching this limit, the player and his ship were abducted by a UFO that appeared subtly. This solution was not satisfactory, mainly because it was aesthetically uncompatible with the style of game.
Can anyone imagine a better solution?
I suppose the race would have a timer, and if the player takes too much time wandering other participants will reach the finish point and the race would end, showing the player as a DNF (Did not finish)
- Warp space so that they quickly return to the far side of the track. (Not good if it's exploitable, but hopefully you don't need to wrap too quickly). (Best if you can put this on a very small planet and just use normal 3D space.)
- Have automatic pilot force their steering back towards the track. (Does automatic pilot steer them to the starting line? Can this be done without breaking the physics used elsewhere?)
Sounds like a fun decision to make. What's best all depends on the feel and style of the game though, doesn't it?
Other than that small quibble, I enjoyed the article. :)
- You could make jumping (or at least repeated jumping) inaccurate, so that its good enough for reaching a ledge or crossing a trench, but chaotic as a form of movement.
- Or you could just make repeated jumps lower and lower until the player stops for a while. In the limit, this could just be implemented as a mandatory pause between jumps.
[Sorry - Didn't notice how late I was to this discussion!]