Running on Magic is a procedurally generated runner-platformer coming this summer. We’ve been working non-stop since the COVID pandemic but today we’re taking a break to unveil its secrets to you.
A crash course into Running on Magic
Running on Magic is a game where the player controls a mage constantly running to avoid death. Literally. He is running from the Grim Reaper.
So, basically the game is a treadmill. The level, which is made of terrain, pickups, enemies and other hazards, is a big object which is constantly moving. And the player goes on top of it.
Also the camera follows along. Well… I lied. The camera always stands in place, that big object is the one moving past the camera. This is called a parallax scrolling camera. Scott Rogers defines it as follows:
As a parallax scrolling camera moves, the world moves with it. [...] There are two different ways you can treat parallax scrolling. First is plain ol’ scrolling. The camera is controlled by the player’ s movement —the player essentially stays in the center of the screen as the world moves past them just like in those old-fashioned western films. Giddyup. The second type of parallax scrolling is the forced scroll. The player is forced to “keep up” with a scrolling camera.
Background is also tricky. It is structured in different layers (the sky, the clouds, the floating islands...) which follow the treadmill’s movement each at a different speed. The closer the layer is, the faster it moves. So, as we walk, the islands and the clouds move faster than the sky which is behind them. Just like in real life. We are just faking the perspective.
The technical mumbo jumbo
Now we’re getting to the terrain itself. Since the levels are procedural, how does it get done?
The level is made up of slices of “content” which are continuously spawn on a frame by frame frame basis.
The smallest piece in a level is a tile of terrain. A slice is a series of tiles stack on top on each other up to a certain height. Then, enemies, platforms and the like are spawned above or right onto the terrain’s top.
It is a very straightforward process and does not look back. Once a slice is done, the algorithm moves to the next one and forgets about the ones that came before. There are several nuances more, like controlling that platforms fit into their respective position, randomizing pickups and placing background props, but they are far more boring (and sloppy) than this.
This is literally the doodle we used to conceptualize the system.
But you said it was procedural
I lied. Again.
The game is semi-procedural. All the little challenges that make a level fun have been designed by us using pen and paper! After all, design has to be intelligent, it cannot be done by machines.
Each challenge is what we call a level chunk. A chunk features a series of hazards, platforms and pickups that are positioned along a terrain of certain length and unevenness. Those data are designed on paper and fed into the editor.
In the final game, there are almost 500 chunks, which are selected and ordered randomly to form a level. But we cannot allow said levels to be fully random, since that would be unfair for our mage. The player could encounter a very difficult challenge too early or run into an enemy he/she/they has never seen before too late into the level.
So, what solution did we find? Each chunk is assigned a category (like tricky jumps, explosive enemies, ...) and a difficulty. Using these tags, we order the chunks into a pool from which we randomly take the most adequate chunk according to what challenges the player has already faced. This way the challenge ramps up organically.
There you are. Now you know all of Running on Magic programming secrets.
