*This blog post has been written by Alex, our lead programmer. You can read his original post on our website.

You can follup up with all the posts from the series:
The Making of Toto Temple Deluxe: Platforming (Part 1)
The Making of Toto Temple Deluxe: Platforming (Part 2)
The Making of Toto Temple Deluxe: Collisions for Platforming
The Making of Toto Temple Deluxe: The Unique Experience

Introduction

We have recently announced our first local multiplayer / arena game for Ouya, Toto Temple Deluxe, and we thought it’d be great to share our development process. We’d love to hear your thoughts on it.

If you’ve never heard of Toto Temple before, it’s a game we originally made during the 2013 Toronto Game Jam (ToJam). We’re now working on the follow up title (Toto Temple Deluxe), which is supposed to bigger in scope, as well as to offer a more engaging experience.

The goal of the game is to catch the goat to make points, and eventually keep it for as long as you can while other players are trying to steal it from you. There’s a bit more depth than that to the game, but you can take a look at this short IndieGames.com article to learn more about gameplay details and mechanics.

Left and right must feel right

Our first entry is about left and right controls, because it is important, in a game like Toto Temple, to have characters that are really fast and nimble for the sake of responsiveness, but still seems to be a part of a world with physics in it, in other words; we want the character to be an extension of the player, in the realm of the game.

Some action from the original Toto Temple. A lot of details have changed since then.
 

The character must move left and right with an acceleration and be constantly decelerated by friction, giving a good physically plausible, yet not floaty, feel to the character.
The character can be controlled on the ground and in mid-air, this is very important as the player will not touch the ground for most of his time, and there is nothing worse than dooming the player to a destination for the time of the jump.

Those accelerations and frictions must be different on the ground and mid-air, you must feel like you are in perfect control on the ground and like you are floating when you are in the air, just like in real life! ...If you were able to move in mid air that is.
 

protected virtual float goSpeed(float speed) {
float addedSpeed; //variable to store the speed added  to the character
        
if (onGround) { //if the character is on the ground...
        addedSpeed = accelX * speed; //the character moves normally
        [...] //other important yet irrelevant things for the current example    
    } else { //if the character is in the air…
        addedSpeed = accelX * speed* airAccel; //The character feels more floaty with less acceleration (airAccel is a fraction)
    }
vX += addedSpeed; //the added speed is added to the character’s total speed    return addedSpeed; //the added speed is returned for further verifications
}
 

The easing / skidding effect makes for a game that looks professional when done right, but can turn sour very easily and it comes with a fair deal of problems, one of them being the latency of the character to turn around and go the wanted direction. Solution: if the character is going in the opposite way as the controller dictates, the character is further accelerated toward the targeted direction, this tweak is less applied in mid-air to keep the floatiness.
 

protected override float goSpeed(float speed) {
    if (speed*speed < 0.25f) {//if the player input speed is too slow
            speed = 0;//just ignore it
        }
        if (speed > 0 != vX > 0 && vX!=0) {//if the player input speed goes against the current speed of the character
            speed *= 1.75f;// Boost the input speed
        }
        return base.goSpeed(speed);//process the speed on a deeper level, previously shown
}
 

Another skid problem being that the character continues moving toward the last input direction. Yeah, that’s the point of making the character “skid”, but do you know what happens to be in that direction? No, neither do we, it could be a pitfall or it could be a danger and it feels really wrong to have the character experience a significant event (even death) full tenths of second after the player’s last input. What if by releasing the controls he exactly wanted to avoid that thing ahead?

The solution to this is an anti-skid system: we detect if there is such thing as a dangerous collision or no ground in front of the character, if one of those conditions are met and the player does not input any movement, the character stops immediately, significantly increasing the precision of the character controls in critical situations without sacrificing overall speed and feel.

if (!moving && onGround) {//If the player has not entered any input this frame and is on the ground...
    tweakFrictionForThreats();//verify if there are threats and stop the character accordingly
}

Here’s a toto in danger of falling down, saved by the anti-skid system. Whew! Thank you anti-skid system!

Show me yours, I'll show you mine

So I’m leaving you with these little observations on other games, relevant to the subject:

In my opinion, controls are the very thing that can make or break a game, it is the base and foundation of every digital interactive experience and a really special care should be accorded to this aspect. And you, do you have an opinion on the way a character moves, in any game?