Image Credit: Golf? by babiambi94
I had done a little thinking as soon as I decided to build a ball-rolling game. I imagined a game which played similar to a golf course, but where instead of counting strokes, we count seconds. It seemed fun to include mechanics such as you might find in a miniature golf course, as well. That idea was then refined somewhat further by looking at all of the games in the previous posts. In particular, I wanted to design around the following observations.
Rolling games seem to be heavy on dexterity, light on choice. I don't like this. I think that continuously presenting players with choices of varying type and significance is the best way to keep a game interesting. In mini-golf, we often see this in the form of a shot into a pipe which directs the ball straight at the hole, but sends the ball way off course if missed. This is fun! Do I go for the high risk, high reward shot, or play it safe?
Likewise, in real golf, a player brings a whole set of clubs with which to execute different types of shots and trajectories. In my game, with no strokes, that was not an option. However, we could introduce a similar choice by letting players use different marbles, such as:
- a regular wooden or glass ball
- a ball which moves fast but bounces hard, like a superball
- a gloopy ball of gel, slow moving, but able to go right over/around obstacles directly
- a fistful of small marbles, any of which count when they reach the target
These choices will want to be clear to the player, something which is given a moment's thought before trying. The more distinct, and more balanced they are, the better.
I liked it when the games I sampled made mistakes almost meaningless, and immediately let me try the current level again. Now, if we are introducing each level with a flyby (as Super Monkey Ball) in order to illustrate what different choices the player has for the level, even just the time delay gets annoying. We'll want to make sure that we only show the preview of the hole a single time, not after each failure.
Additionally, failures should come with a small fixed cost, if at all: That is, if we are measuring the time it takes to complete the course as your score, and the ball falls out of bounds, it is an extremely harsh penalty to include all the time it took to get there. It's much better to add a fixed penalty of (say) 1/2 of a second, regardless of how long the player spent in the failed attempt.
In general, almost succeeding at a challenge is frustrating, and this kind of game will tend to be likely to experience these kinds of failures. The Labyrinth Lunacy game that I reviewed in the previous post was a particularly egregious example of this frustration. I want to build a game in which one can snatch victory from the jaws of defeat, even when it looks like all is lost.
Gentle and Fun
Some have lamented that modern video games have been watered down to the point where there is no remaining difficulty at all. I understand that concern, but I'm definitely interesting in building a simple, casual game this time around. I want to make it feel fun and playful, rather than stressful and precise. Unfortunately, accomplishing this goal is going to take lots of iteration, probably with lots of emphasis on level design. And until I have something working, there's no way to iterate. "Feel" is, almost by definition, something that can't be designed in advance.
In some ways, this is like planning a movie. It is easy to say, "I'm making film noir," or "this is a thriller," but the details of what imbues a film with those characteristics are written into the script, storyboard, and ultimately the direction, cinematography, acting and editing. We may say up front that we're looking for action or intrigue or whatever, but actually creating it takes a careful eye throughout the process, not one up-front decision.
One particular detail was immediately approachable: the problem of manipulating, versus seeing the screen. The problem is that a surface that we are rolling an object on should be flat, parallel to the ground, if we want to control it. This works well for control, but makes the game hard to see unless you bend your head way down to look into your lap. I'd have to address this mismatch. There were a few options:
- Screen flat, world flat: This is what Blendamaze and Labyrinth Lunacy did. It is the most intuitive interface, but the least comfortable.
- Screen vertical, world flat: This is what Super Monkey Ball did. It's more comfortable but makes for awkward controls.
- Screen vertical, world vertical: Rolling Coins did this, but that game had to sacrifice on natural physics as a result.
- Screen, world at angle: I tried this in one of my prototypes, but it didn't feel either intuitive or visible, so I abandoned it.
After some experimentation with level design, I hit on a solution that I'm presently encouraged by. Most of the time, third-person perspective games such as I'm building here move the player forward on the screen, so that the player may see what's ahead. But in order to get a ball on a flat surface to roll forward, away from you, you must tip the plane away, making it harder to see. What if we flipped perspective so that most of the time, we want the ball to come towards us? In this case, you would tilt the screen to an angle that makes the display more visible.
So in the upcoming posts where I (finally) describe the process I'm using to build the game and design levels, we'll take a look at how bringing the ball towards the bottom of the screen and player actually works out. In my current version, if I'm really trying to move quickly, I hold the screen almost completely vertical, using gravity to zoom the ball through the course. The more aggressive I want to be, the easier it is to see the game. I like the way this works.
previous: Comparisons - 2 next: Project Setup