The Ultimate Scrolling Analysis.

Huge thanks to Itay Keren for having written his essay that creates a clear nomenclature of camera techniques in (mostly) platformer games, ranging from Pac-land's position locking to Mario's platform snapping to linear interpolation and beyond.

Grâce au développeurs de Frogatto, j'ai pu découvrir l'existence d'un excellent article sur le scrolling des jeux de plate-forme publié il y a quelques jours sur Gamasutra. Eh oui. C'est ça, l'après Google Reader. Je ne vais pas repasser en revue toutes les techniques qu'il présente, du premier platformer à nos jours -- pour ça, il y a l'article d'origine, mais j'en profite pour mettre à jours mes propres références.

Lerp in action. (C) Itay Keren.

Back then, when I started researching how to move Bilou's camera, my colleague Cyril suggested "an elastic string that would draw back the camera to Bilou's position". One close match is Donkey Kong Country's linear interpolation technique. It still has some "wobbly" effect but much less nausea-inducing than when you lock to the player's position. But this is far from being the only camera mechanic in DK games. Anyone who played the game has noted that some areas of the level are apparently "scripted" with cameras behaviour and that entering some hitbox may suddenly allow the camera to move past some artificial barrier, revealing a hidden area. More subtly, this can also be used to enforce "bottom-locking" in some part of the level, or change the horizontal tracking to the type of gameplay (rush, explore, climb...) of a specific area.

Commençons par une technique que j'avais laissé sur le côté quand elle m'avait été proposée par Cyril -- une "sorte d'élastique qui ramènerait la caméra vers Bilou" -- que j'avais tenté d'implémenter avec le code de poursuite des BerryBats. J'aurais mieux fait de procéder comme dans Donkey Kong Country avec une "interpolation" linéaire qui déplace la caméra d'autant plus vite qu'elle se trouve loin de son point de destination.

When I tried myself to analyze the horizontal scrolling of Super Mario Bros, I thought that there was two 'push-the-screen' positions, depending of the speed at which Mario moves. The reality is a bit different.

two triggers in SMB. (C) Itay Keren.

There is indeed two trigger positions, one -- walking barrier -- that forbids Mario from entering the rightmost part of the screen, and a second that smooths camera movement when Mario starts running. The "early-scroll" trigger doesn't try to keep Mario at its left, though, so he eventually "escapes" to the walking barrier.

Passons ensuite à SMB1, avec son interdiction de revenir en arrière. Ici pas de soucis pour faire demi-tour, mais Miyamoto a quand même pensé à nos jeunes estomacs et a ajouté un démarreur de caméra deux blocs avant la position 'naturelle' de Mario. On y gagne pas pour autant en visibilité pendant la course comme je le pensais au départ, mais on évite un départ trop brusque de la caméra si on revient en courant.

This is what smooth out the movement of the camera by reducing the instan(aus)eous acceleration of the image. I'd be tempted to say screen will move at walking speed until the real barrier is hit. I guess with more CPU cycles and memory, miyamoto's team could have even tried to linearly over time in that region rather than having two-steps, but I doubt most of us would notice the difference, so it's not bad to keep it simple. But no, you don't really have more headroom when running in SMB.

Finally, Itay's model of Super Mario World's camera nicely complement the video document I already found (and not yet re-blogged so far). The camera here clearly has multiple mode, that Shaun categorizes as "platform-snap", "bottom-locked" or "free-moving". I tried and mapped these as an UML state machine, but it lacks one component: the fact that in some levels/parts of the level, some transitions are forbidden -- e.g. in some levels, you will not enter platform-snap and stay bottom-locked.

Les différents mode de suivi vertical de Super Mario World, j'avais déjà étudié par l'entremise de Shaun. Le code est assez sophistiqué pour mériter une machine d'état à lui tout seul. En plus de ça, certaines transitions sont interdites dans certains (morceaux de) niveaux, forçant par exemple la caméra à rester au niveau du sol à moins que Mario ne s'envole dans les niveaux plats. 

What Itay adds to that, is a clear illustration that the camera in SMW has a direction state of its own (moving leftwards or moving rightwards) distinct from Mario's movement. In each direction, there is one barrier that will make you push the screen if you try to go past it, and a trigger that will switch to the other mode if you touch it. When the camera is "heading right", the two yellow lines are active -- Mario is confined within 2 blocks. As soon you hit the dashed line while turning back, the camera switches to "cyan mode", and then you have the screen adapting as quickly as the camera's max speed tolerates because you're about 64 pixels away from the push barrier for that direction (still picture shows a point in time where such catch-back occurs).

L'analyse de Itay est plus précise en ce qui concerne le scrolling horizontale. Il illustre parfaitement le mécanisme des deux "poussoirs horizontaux" décentrés (un pour chaque direction de caméra) et les déclencheurs qui forcent la caméra à changer de direction quand Mario a fait demi-tour de plus de 2 blocs. Il semblerait qu'on ait ici aussi utilisé une "interpolation linéaire" pour adoucir le mouvement de la caméra quand elle atteint à nouveau la position de Mario.

With this scheme, the player always have at least 1/3rd of the screen in the direction he face and half-a-screen-plus-one-block in most of the cases. That works quite well with exploration games like Commander Keen, imho.


If you're doing game design in some way, I strongly recommend you to spend some of your "research points" reading Scroll back : the Theory and Practice of Cameras in Side Scrollers.