A game’s mechanics are powered by a gameplay engine. This piece of code takes care of handling all the logic behind the scenes to make the game behave like it should. With the 1.1 update of TURN Episode 1 comes a new gameplay engine, rewritten from scratch.
In this second post (read first post), I’ll tell you about the process used to decide on the behaviour.
Settling down on the game’s behaviour
After too much time trying to get the old engine to behave, having realized all the problems we were running into, five of us decided to lock ourselves up into a room to settle once and for all each case and draw rules out of it.

A few not-so-simple cases
We started by enumerating on a whiteboard a few cases that were encountered while playing and that felt weird or buggy. And guess what: we came to realize we didn’t agree on what the right behaviour was! TURN is a puzzle game, not a physics simulation, we’re constrained by the grid in which the objects are located and can’t end up with objects standing on two tiles at once. So sometimes, as I stated in the first part of this series, the behaviour just has to be agreed upon, there just isn’t always a universally superior solution.
On the wall was projected a wiki page which we could edit in real time to settle down on the rules.
The new rules
We decided the game had to be split into small timesteps during which each object could move at most once (in the final game, each of these steps lasts 1/6th of a second). Here is a extract of the game timestep’s recipe:
- Gravity: Processing from the bottom to the top of the room, each object subjected to gravity that does not stand on a solid object goes down one tile
- Artefact: If Kurt (or Camila) stands on the tile which contains the level-ending Artefact, the level is completed right away
- Crushing: If a non-solid alive object (Kurt / Camila or an enemy) is on the same tile as a solid object, it dies and isn’t part of the room simulation anymore.
- Landing: Processing objects from the bottom to top,
- Crate: If a crate just fell and now stands on a solid stopped object, the object it stands on takes damage. If the object still exists after taking damage, and the crate is now stopped.
- Breakable crate: If a breakable crate just fell and now stands on a solid stopped object, both the breakable crate and the object it stands on get damaged. If the object still exists after taking damage, and the breakable crate is now stopped.
- Boulder: If a boulder just fell and now stands on a solid stopped object, the object it stands on get damaged. If the object still exists after taking damage, the boulder will try to roll.
There are some other steps but they are left out for the sake of brievity.

The team discussing a particular issue using "Paper TURN" ™
Once we had covered a broad sample of cases and decided upon these simple (but precise) rules, we gathered around a table, cut a bunch of small cards for each type of game objects and started testing.
At the time we started the meeting, I was quite anxious as to whether we would be able to find a consistent behaviour for the rolling boulders. But we did! I guess next time, we’ll be careful to have this kind of meeting before getting our hands dirty with coding the game. We could have saved some sweat and time!
Share on Facebook