What are you looking at?

A short story from last week.

I wanted to go to the city and find something for lunch. To get to my favorite snack bar I have to use a cross-walk. As always the traffic light was red, so I stood there, waiting, and looking around. Worse luck, I left my view a bit off the traffic light so I noticed late when it turned green. Since waiting for the next green was not an option – my stomach was already getting angry – I got in a hurry. While adjusting my view to the left I started walking but mixed something up. My sight shot up in the sky while my feet took me not across the street but rather in the middle of it. Okay, just don’t panic I said to myself and started recalibrating my sight. But with all the struggles controlling my view I didn’t have time to focus on my feet and since everything took that damn long I eventually got hit by a bus. Well… now I’m dead.

Of course, this story is completely imaginary and I am not dead yet. Controlling your sight isn’t such a problem in real life after all. Just look left, right, up, behind you, all while walking, eating and going trough the latest tweets on your smartphone (seriously, you shouldn’t do this right on the street). We don’t even have to think about something like how to use our view.

But in games, this is a completely different story.

In games you HAVE to manually control the camera WHILE you simply want to play it… well unless the whole game – like Nitromes absolutely awesome Tiny Castle – just uses one screen. But if that’s not the case, the camera controls should be dead simple. At best you barely notice that you are using active camera control. That’s why we put decent time and thought in something negligible as controlling the viewport, and of course, we want to share our thoughts with you.

So, enough with this lengthy preamble, let’s get to the point.

 

VARIANT 1:

Path of Pow will be a top-down game, because this offers the best overview and the necessary precision in positioning your player character. To keep it as simple as possible our first idea was a fixed system. The camera would be centered on the player. You tap a point on the map, and the character will jump there, creating a shockwave that pushes balls nearby.

There would be no other gestures than tap and release and thus no way to accidentally use the wrong gesture. But simple is not always good. This just was too simple. There is no way to look around the level and what  if the ball leaves your viewport? You wouldn’t have any chance to find out where exactly it is. Obviously this wasn’t the way to go.

 

VARIANT 2:

The next ideas was to center the camera to the target marker, the spot that appears while you tap to aim but before you release to jump. When you move your finger to the edge of the screen the map would scroll in the intended direction.

This seems better, but there are still way too many issues. There is no way to get a quick overview of the whole level when you have to manually scroll in every direction, and you are always at risk to accidentally release the tap and jump. Furthermore aiming would be more troublesome because you could start scrolling by mistake while you just wanted to aim near the screen edge.
Gosh! Thats really bad.

 

VARIANT 3:

Let’s face it, we need some control mechanics to enable scrolling and zooming. But one finger tap and release is already reserved for aiming and jumping. Simplest gesture for the most basic game control. The obvious solution would be to use 2-finger swipe for scrolling and 2-finger pinch for zooming. The camera would recenter after the jump.

This solution has some really nice benefits. The player gets full control over everything. It’s possible to make jumps even while the character is out of the viewport, you can take a look around and with zooming you are able to position your jumps more precise.
But there is also a very big downside. With 2-finger swipe and 1-finger tap and release the risk is too high too accidentally make a jump while you just wanted to scroll.
The possibility of this mistakes is an absolute no go since it would completely screw up the game experience. Nobody likes it when he gets a worse score only because the controls are non-functional.

 

VARIANT 4: This time we chose a completely different approach. Detach camera control from actual game control. We could insert a mini-map where you see the whole level with your actual viewport highlighted. You could scroll by dragging the highlighted area around, and the camera would stay where you set it up.

This seems to be a much more elegant solution. No score screwing gesture accidents, quick overviews aren’t any problem and the control scheme itself seems pretty self-explanatory… or could be explained in one simple tutorial.
However, you might already guessed it, there are other problems with this solution. The mini-map is a nice tool, but only as long as it is permanently visible and accessible. This will use up a good amount of precious screen space. On tablets this is manageable but on smartphones there is no chance we could use up so much space only for view control.

Well… after the fourth iteration, with no satisfying solution yet, things started to be a bit frustrating. We knew we had to get this whole camera adjusting thing right to provide a smooth game experience. Otherwise the fun would crumble while players were fighting with the viewport instead of thinking about a solution for the level they are playing.

But luckily we are near our till-now final solution for this pesky problem.

 

VARIANT 5: Who said we have to reserve one finger gestures exclusively for the character control? Okay, I wrote it about four times in the text already, but we might find a better solution if we just forget this rule. One-finger swipes for scrolling are well-established in mobile games, as two-finger pinch zooms are. Though we would need another solution for aiming and jumping then. This could simply be done if you tap the main character – instead of anywhere on the field – and drag him to your target point.

This is still a pretty obvious and direct kind of character control and the tap-anywhere and swipe gesture is open for scrolling. No gesture accidents in sight. Yay! We finally got it… not.

Imagine following situation. You pushed the ball wide of the screen and scroll to see where it is. Now you want to jump for the next push but… the character isn’t in sight because the ball was too far away. No problem, just zoom out a bit until both, the ball and the character, are visible. But hence the viewport is too far away from the field to target precisely.

We solved this by adding a little icon to the screen edge which indicates the direction where the character is. It will only be visible if the character isn’t, and you can use it to make jumps just like you normally would. Tap it, drag it, release it. Done.

After all the different variations where are quite happy how this works. We will use it a bit longer for testing in our prototype, just to be sure this really is the best solution possible. But for the moment it works really gorgeous. We might make another post after the testing and share our then broader experience with you.

At last, I hope we could show you how important a well functional camera control is, and how difficult this is to achieve. And you might be more aware of your view control in real life… just don’t think about it in the middle of the street ;)

Tagged with: , ,
Posted in Gamedesign, General

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>