Monthly Archives: October 2012

 

The Story So Far

On mobile devices there is much less finality on what you ship than other mediums. It’s a good thing that you can fix things that weren’t quite right at release, and updates and tweaks are encouraged, but there is some hidden danger there. In fixing a bad, broken feature, I almost lost one of the things that, unintentionally made the game fun.

 

Now that I’ve quit my day job, I’ve actually got time to work on 10000000, One feature that annoyed me at the time I wrote it, but I didn’t have time to fix was what happens when you get to the end of the corridor:

 

You can see the mechanical reason for needing to do something here If the player is at the end of the corridor, they can’t see anything ahead, we can’t move the character any further and its generally not a good state. In the released version, I got around this by setting it as a “goal” and giving a bonus when the player got to the end:

It didn’t work. One of the most common, and fair complaints is that the player feels like they are being punished for doing well, something I agree with. I tried a simple “fix” and it yielded some surprising results, making the game less fun

 

In The Beginning

To give a bit of background on how the corridor works; your character’s position on the screen, represents the amount of time you have left in the game. It’s not something that fits well with any existing metaphors, so I searched for something to make it fit in with the lore and failed. In the end, I just had to (try) to explain it in a tutorial

Internally, this is just represented as a float “progress” which is from 0 (failure) to 100 (hurray), with the bonus occurring when the player hits ~90-95 or so.

One thing that came up when playing around with this, is that its a fun experience to be on the cusp of failure and recover and it’s an exciting experience to constantly near failure, but holding your own, so rather than using a simple linear interpolation to map the characters progress to screen position, I used a sinusoidal interpolation.

 

Simple Fix

So, I thought the easiest thing to do, is just cap the player when they get past the line and just start incrementing a counter, so long as they stay ahead of the line, that counter goes up.

Now this in itself has some good points, the player is rewarded rather then penalised for staying there, there is an equilibrium that disrupts the player back to a normal state (less warning about upcoming stuff)

But here is where it went wrong: In the original version, there was a great, unintentional tension, everyone I saw, and if I think about it, myself too, would try to get towards the end, but not too far, not enough that you’d get the ‘bonus’ that set you back, but enough to give you the biggest buffer of time, even when you were performing well you were on the edge of your seat trying to maintain an optimum lead.

While the result is bad, the gameplay it creates is great fun.

In the new version, once you were doing well It was just a matter of matching, reacting, and trying to keep your lead. no tension, so much of the game was lost.

 

 

A Solution

I’m trying a varation on that theme now. When you cross the line, you get a counter ticking up. If you manage to stay in front of that line until the counter reaches maximum, you get the bonus, if you cross back over the line on the left side (minus a bit of grace) you get nothing. It motivates you to really stay above that line, the tension is still there, but now its more about falling back rather than falling forward. You also have the nice surprise of seeing what kind of resource you are going to be getting, and a range of values it could be

It still wasn’t quite perfect though. Remember that sinusodial interpolation? It worked as a detriment here. 1 point of “progress” translates into quite a lot of z space so when you start losing time you don’t really get much of a visual warning and it feels fast and unfair. I’ve changed it so once you hit the 90% mark you start moving on a second round sinusodial easing.

And the final result (in the case of a failure at least):

 

I think this still captures the tension that was there originally, but is much more pleasing to the player.

To try to keep some of the tread-the-edge-of-optimality, if you do complete your contract, you’ll need to move back out and in again to restart a new counter. I’m still not sure whether this captures the original magical tension. I’ll have to test some more.

 

Any feedback? Hit me up on twitter