World-shifting system

I would like to start a small series about some of the technical aspects of Floralia. Floralia is being developed in Unity, which handles a lot of tasks by itself, thereby making it easier for us to concentrate on the special mechanics of the game. So far the implementation has four major systems that handles different aspects of the game:
  • World-shifting system - The core game mechanic
  • Movement system
  • Cut-scene system
  • Camera handling
In this post I'll explain how the world-shifting system works. It might get a bit technical but hopefully it will also give an impression of our core game mechanic.

World shift

Before digging into the implementation of the system, it might be useful to explain a little about the game mechanic. Initially, we had this idea of making a game with two parallel worlds where the player can shift between them. I liked the idea, but we quickly became aware of some challenges. First of all, in order for the game to be playable and enjoyable, it would be necessary for both worlds to be visible to the player simultaneously. We found games with a similar mechanic, but in these games, the player would change the entire screen when shifting between worlds. In our experience, this mechanic was more confusing than entertaining. Also, if the player was simply able to change between two worlds, the game would in reality be a 2d-platformer where the player could move on the z-axis. Therefore we came up with the solution of freezing objects on the screen. By the press of a button, the player is able to activate/deactivate (pushing objects in/out of another dimension) for his/her advantage. It simply allows the player to solve puzzles by manipulating the world. This is the core-mechanic of Floralia.


The challenge with implementing this mechanic is that all the objects the player encounters should have this world-shifting behavior. Since all the objects should have the same behavior, it is quite simple to implement using inheritance. I created a base object, called LayerObject, that simply makes it possible for a object in the game to become activated or deactivated by calling respectively activate() or deactivate(). The main purpose of these methods is simply to keep track of a LayerObject's state in a boolean property. Also, it changes the transparency of its sprite and moves its collision box. All objects inherit from LayerObject, and before moving it checks if it is active or not. Since objects then only move if they are active they appear frozen when they are not active. This is a fast and easy solution, however, I don't think this is the best way to do it anymore. One day I may rewrite the code a bit so objects that inherit from LayerObjects do not have to make this check. Instead they should implement a LayerObjectUpdate method, that is only called from LayerObject when it is active. This would be very nice, since it removes a lot of redundant checks.