Spiludvikling.dk

FLORALIA



Floralia is a narrative puzzle-platformer, set in 19th century Scandinavia.
It is an absurd love story filled with horror, mystery and parallel worlds.



Look test:



WEBSITE: http://floralia.blaavogn.dk/blog.php


THE STORY

Strange things occur in the mysterious town of Sandwike. You take the role as Antoon,
an inquisitive explorer of science who ventures into the town, in search of a magical
flower. In his search, Antoon falls in love with Senta, the Innkeeper's beautiful daughter
- the very key to unlock the secret of Sandwike.




THE CONCEPT

The main mechanic of Floralia is the power to push objects
in and out of a parallel world as shown in the animation below.




Besides being inspired by various platform games, we
also take inspiration from 70'ies and 80'ies cinema
and music. One of our goals is to surprise the audience,
by twisting the plot, creating bizarre scenarios or scenes
of shock and horror.



FEATURES

Solve puzzles of parallel worlds.

Explore strange and eerie landscapes.

Meet deranged townspeople and discover their secrets.

Witness the horrors surrounding the town.

Experience the most absurd love story of the 19th century.




THE PRODUCTION

The team consists of Holger Borum (Programmer) and Malte Burup (Artist)
The game is currently in development in Copenhagen, Denmark.

The development of Floralia began in the beginning of 2014.
As we are both occupied by our studies, Floralia is developed in our spare time.
We are aiming for a release sometime in 2016.

Stay tuned as we will be posting in-depth developement updates.

Looking damn fine already Malte :like:

Looks pretty good!

As part of our campaign, I have written a small post about out core mechanic.

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.



Implementation
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.