Posts Tagged ‘games’

Opening Lines – Finding a Voice for Epistory

Thursday, October 22nd, 2015

Epistory needs to establish a subtle, layered narrative voice within its opening moments. Join the game’s writer in a deep exploration of why this story is harder to begin than most.

Wether you’re writing a game, or a movie, or a novel: it’s always difficult to start a story. There’s just so much riding on those opening moments. This difficulty is basically the premise for Epistory’s plot, in which a struggling writer is trying to start a novel. The player assumes the role of the muse, helping the story come to life.

Epistory adds an additional complication: as well as attracting the player’s interest immediately, it must also establish the narrative voice. In this article, I’ll be explaining more about what this means and how I’ve tried to solve the problem.

Posted Image

What’s In A Voice?
By ‘narrative voice’, I simply mean the voice of the narrator: who is telling the story? Why? And in what context? Are they speaking to the audience directly? Are they writing a letter? Is the audience an active party in the story, or are it given a camera’s eye view into someone else’s world? Ultimately, narrative voice defines the relationship between the storyteller and the audience.

Most narrative voice is established by its medium and a few quickly-gleaned implications. When a written story starts with a line like “Call me Ishmael” (a laMoby Dick), we instantly understand that there is a person telling the story to the reader. We understand that the narrator has their old world view, and agenda, and feelings. But when we watch a film and a camera sweeps across the Earth – like no human can do – we understand that a picture of the world is being presented to us impartially. We are invited to watch through a window.

Epistory Early Access – NOW on STEAM

Whose Voice Is It Anyway?
In Epistory, the narrative voice comes from a writer who we never see. All the words of narration – from the introductory sequence to the writing stretched over the levels – are the words this writer has written in their novel. The player’s goal is to help the writer create the story: typing words and discovering things to encourage the author’s inspiration.
This is a very hard thing to explain in-game: not least because we don’t meet the writer. We have to inferher presence. Originally, the game’s script did this the obvious way: it begins with a writer saying “I hate writer’s block! How am I ever going to write this story?”, and quickly settles down into the story itself, “She looked like a lost little girl”. This establishes the narration as the writer’s voice and ensures it makes sense within the context of the game.
This works – but it’s messy because it creates two distinct narrative voices. The author’s (“I hate writer’s block!”) and the story’s (“She looked like a lost little girl”). Because we don’t really know which is which, we have to infer every time – and so there’s a constant dissonance. It’s hard to know who is telling the story. Also, writers tend not to ask themselves questions in their own prose, so the voice may not sound authentic to player.

Posted Image

A New Voice
I wanted to try and do something a bit more subtle and seamless: using a single voice that represents all the narration. I’ve tried to do this by presenting the story as a work-in-progress and showing the writer’s edits. The theory runs like this:
The game begins on a black, foggy screen. A blank canvas. Then some text appears: “Once upon a time”. This is how all fairy stories start, right? The player knows that a story is beginning. But the text is quickly erased character-by-character. The story has changed, the writer’s hand is revealed by implication.
The writer tries again, and this time she writes: “It was the best of times, it was the worst of times”. This is how Charles Dicken’s A Tale of Two Cities - the best-selling novel of all time – begins. Even if the player doesn’t follow the reference (and most won’t!), they should understand that the story has been restarted.
But this beginning is rejected too, and so it is also erased. The pattern has been established now: the author doesn’t know how to start the story. So, third time lucky, the narrative begins in earnest: “There was a girl. And she rode on the back of a great fox.”. And hey presto – the fog clears to reveal the player-character.

Voice of Reason
Because there is only one narrative voice, the player can trust that it represents the words of a story being written around their actions. We build on this start by adding more interactions which make the player aware of the author – and vice versa – by changing text as the player interacts with the world. It’s a subtle idea, and maybe not everyone will get it. I expect most people won’t be able to articulate it. But subconsciously, I believe people will understand that a story is being written around them by an unseen author.

Successful execution relies on two things: using recognisable (or cliched) opening lines, so that the player understands what the writer is trying to achieve (ie, the beginning of a story); and a character deletion effect, so that the player is aware that the writer is deliberately erasing and rewriting text. Sound effects can help reinforce the idea of writing and erasing, too.

Posted Image

This, however, is not the whole story. While we work hard to establish and contextualise the narrator’s voice early in the game – we later sow in a few seeds of dissonance. Because in Epistory, not all is what it seems… 

Epistory: You can now buy it on Early Access

Thursday, October 1st, 2015

FB_avatarWhat to expect in the coming days & weeks

After the Early Access launch yesterday we received a lot of feedback and we are excited to see reactions, videos & liveliness in the community

For the next few days we will focus on ironing out the bugs and quirks that were reported. Most notably any save bug that you or we encounter. The game is currently playable in several settings but the save is sometimes a bit dodgy so that is our top priority. 

Then, in the coming weeks, we will continue to produce the next chapter of the game. We should be able to deliver it in a month. A month and a half, maximum. 

We will of course do minor content release in between chapters with stuff like improved UI and feedback, bug fixes & general polish. We want to avoid players going through a new chapter while it’s only half done because it will ruin part of the joy of discovery. 


We are also going to create an unstable branch for the game so you can try our latest advancements before we make it available for everyone. We may also add a separate branch for people wanting to try the new areas before they are finished if you ask for it. 

Thank you, more news soon.

Join the community on Steam

Epistory: SAVE THE DATE!

Tuesday, September 22nd, 2015

Hi folks! We are so glad to announce the release of Epistory on Early Access. See you the 30th of September on Steam. Meanwhile, you can visit the Steam page of Epistory and put it in your wish list



Epistory: Automating Action & Reaction

Monday, September 7th, 2015

A tale of candy distribution.


Most games can be reduced to a series of actions and reactions. Today I would like to share with you a way to facilitate iteration and expansion of these interactions. It will sound obvious to a lot of people but I would have loved to see this kind of example 6 months ago. When I was not yet used to component based mechanics.

It all started with a simple request a few months ago, we had just designed & implemented the scoring system and we needed items in the game world to be able to give points when activated. Easy, I wrote a small script which would be attached to objects that had to add points when activated. Controlled by our item’s base class, it would be called automatically.

The buildup

As time went on, that simple “points giver” script was updated to include various behaviors like prefab spawning, door unlocking and so on. It worked well but it was not very flexible. So I changed the structure to include a parent class to have a common entry point and place each behavior in a child class.

2015 09 02 17 25 18

It’s not standard notation but you can see the rewards and the items have a base class, and only these base classes interact with each other. The same kind of effect could be achieved with interfaces but I prefer to have a default implementation.

The true power of this structure lies in the modularity. Every trigger or actionable item in the game works with any reward and you can place any number of reward in a game object. The most basic action/reaction you can do is simply “collider – trigger – reward”. The player walks in the scene and something happens (tutorial message, cinematic, …).The possibilities are exponential and a new reward behavior is very easy to add.

Polish & additional features

Over time, features were added. Like the possibility to set a delay between the action and the reward. Camera travelling firing rewards at event points… What started as a joke -“reward” as in skinner boxes- is becoming a running gag: we’ll call this one “reward_kill_player”.

I recently did the same kind of structure for visual effects. A few key points (creation, destruction, hit, …) are exposed via a base class. You just have to derive from it and you get all the hooks that an artist would need to handle animations or particle effects.


The system is currently powerful enough to allow our designer to create our whole in-game introduction & tutorial with only the reward system. Looking back my only regret is that this system was not put in place earlier to have more of the game relying on it. Also, calling it “reward” when it’s in fact a “reaction” was a bit shortsighted.

I can share some sample code if some of you are interested. I leave you with one of the more complex interaction that we can produce.

main schema

P.S.: As a very tangible reward after a long wait between news here’s a few free gifs. Both features were added this week:

- One of the first iteration. Nothing special…

flower power 2


- One of the last iteration. Circular pattern, grows from the middle and not all of them at once.

flower power 3


- Black mist that will block your path (first iteration, polish will come later)

ink fog

Monkeys Ahoy! anchored on the App Store

Friday, July 24th, 2015



Join two young pirates on their quest to make the ultimate friendship smoothy through this bright, lively and wild monkey world. Monkeys Ahoy! is a match 3 game with a twist where players can connect pirate treasures by drawing the longest line possible through the same shapes and colors. The game allows for unique combos and chaining as you jump between shape and color to continue the chain. Easy to play and learn with the added fun of trying to make the longest chain through all the pirate goodies! 

Monkeys Ahoy! is available for $1.99 on The App Store in English, French, Spanish, German, Portuguese, Polish, Dutch and Russian.

iOS version:


Epistory: Fluffy Friday #2 – Adding critters.

Tuesday, June 2nd, 2015

More on IndieDB

Bite sized news for small stuff. Today: Adding critters.


After our world building, level crafting & dungeon inaugurating, we were left with a grim realization. For all the beauty in display, we were missing something crucial. We had a beautiful but empty painting. A canvas ready for: Life! *crackling thunder*

critters idle2

So, here they are presented with their idle animation. Minding their own business until you come along:

critters run2 text2

They’ll spawn in small groups where it’s relevant and flee when you come close. Now that the system is in place we could add more variety if we find the time. It’s not completely done but I can already tell you it adds a lot to the look & feel of the game.

We’ll show more soon and I wish you a nice week.

Epistory: Fluffy Friday #1 – Tile appearing

Tuesday, May 26th, 2015

More on IndieDB

Bite sized news for small stuff. Today: Tile appearing.


Today I present you a new kind of post that we will try to do regularly. As an introduction I’ll simply say that we have a lot of small juicy stuff to show that would feel lost in a bigger article. It will take the form of a few gifs or pictures and a bite size article. The topics should range from fluffy things to weird but funny glitches and all that stands in between: gameplay shorts, animation tests and so on. Now that it’s out of the way, let’s continue to…

Fluffy Friday #1

During your wandering in the world, you will slowly uncover more and more of it. Akin to a blank page filling up with words. We wanted that event to be enjoyable to watch because it marks progress in the game. So we did something like this:

tiles reveal

While this gif is not the final version we had at the time (I can still see a few bugs) there was no sense of accomplishment. Just another chunk of land coming in.

So we decided to wait. Once the gameplay mechanism is in place, your priority shifts to another gameplay element. Polish can come later, right? Yes! And we did a pass of polish on that system along with better graphics overall, I’ll let you see the differences for yourself.

tiles reveal2 part1tiles reveal2 part2

There you have it. Of course the final version could differ slightly from this and the gif doesn’t show the best framerate and color. I hope that this is already enjoyable and that you will want to see more posts like this.

Epistory: Handmade vs randomized level design in Epistory

Tuesday, May 26th, 2015

More on IndieDB

The constant dilemma between more control (but time consuming) and more automatism (but never perfect) in Level Design, and how tools can help.

The problem

As in most puzzle / adventure games, Epistory’s level design, is designed manually from the world layout to the smallest puzzle. But to save time and money, we need the automation of everything else, like generic and repetitive patterns or effects that give life to the world. That is what this article is about: the level building of all the things that are not unique or designed for a specific purpose.

A good example of that is the placement of every tree in a vast forest. We know what we want (a group of trees), where (a delimited zone), and how (dense and diversified). So we have parameters that could drive a procedural generation of trees. By the way, game engines have similar tools for vegetation generation.

But in the same time, we want to draw a path in that forest with a specific level design, and the trees’ shape and position influence that design. This is where lies the dilemma: a full control allows us to place each tree as we want but takes a lot of time, and a full procedural gives results that will never be perfect.

If you want a metaphor – everyone loves metaphors – imagine you are drawing a diagram or taking notes. If you use one black pen, the result is not as clear as if you use a color code. But if you have full rainbow pens at your disposal, you are always tempted to choose the right color for the right thing and, inevitably, you lose time. Limitations can have a positive effect, be it saving time & money or coming up with creative solutions.

Our tools

Before explaining our solutions to that problem, I need to talk about the tools we are using and a bit of our level building workflow. Epistory’s level design is tile based and we use the Tiled editor, which is perfect to prototype, create and edit tilemaps really quickly.

The essential criterias when choosing a tool are its usability and the level of control it allows (or in reverse, its constraints). Of course there is also the cost to buy or develop that tool, but I will not talk about that aspect here as I am focused on design (plus Tiled is free and Unity plugins are relatively cheap).

You can get used to Tiled pretty fast and come up quickly with a rough prototype. It saves you time while doing repetitive tasks and is easy to edit. In sum – as long as you stick with tiles – its has no big usability flaw.


So I start by creating the map with Tiled. But the game is in 3D and developed on Unity. So here comes theTiled to Unity plugin that uses the exported tilemap to generate the level in the Unity editor. It simply places the right 3D asset at the right place.


For more specific features, we modified the plugin source code to add more functionalities. An example: when you progress in the game, new zones of the world will appear. So we need to be able to delimit those areas. The easiest way to do it – from a level designer point of view – was in a specific layer on Tiled. So the plugin can also add the generated tiles to a tile manager, and determine to which zone it belongs from that “Zones” layer.


Finally, I place interactive elements and puzzles manually in Unity. It is easier and more editable this way because they all have specific behaviors and parameters. Unique decors used as landmarks and localized visual effects are placed the same way at the very end.


Some solutions

Controlled randomness
In my opinion, the best solution to the “control vs automatism” problem is the more obvious one: a random (or procedural) generation in the editor, which is corrected manually only where it is needed. Note that the random aspect only exists in the editor, it cannot be regenerated in game. As long as you do not change everything, that controlled randomness has a good time / quality ratio.

For a concrete example in Epistory, I will use the example of the forest again. I use the random mode on Tiled to randomly paint with elements from a selection. Then I change some of them manually in Unity if it creates strange looking patterns. I try to have a continuous border for smooth collisions. And I place a few mushrooms, again with a bit of randomness.

Localized procedural
Another solution is to use a more ordinary procedural generation but limited to a very few parameters and/or a small area. Here the randomness happens in game, but not on the key elements of the design. That localized solution allows a correct placement at macro scale without having to place small elements one by one.

In Epistory, we use that method to spawn critters. Potential spawn points are defined and only some of them are chosen a game start. They are not always at the same place but always at a suitable one.
There also are large zones in which groups of particles are randomly spawned. That lets us quickly define the areas in which you will find butterflies, fireflies, fog and so on.

Item variations
Finally, only one attribute of an element can vary randomly. This way, you can use item variations that keep – for example – the same size and function in game but can look a bit different. You do not have to bother about the small variations if they do not affect the design.

On Epistory, we made little use of that but we consider adding variations like size and texture for trees and rocks, rotation on tiling textures, ripped paper effects on some tiles, and so on.

I am sure there are plenty of other solutions and applications to them. I hope that you found those ones interesting and that they could be useful elsewhere.

Thanks for reading.
More on IndieDB

Epistory: Paper on art direction

Monday, May 11th, 2015

More about the game on indieDB

A paper on art direction

The “Art Direction” is basically a set of visual rules you decide to follow during all the creation process of your project. All the visuals you will design will stick to it, and in the end your project will end up coherent, with a specific look everyone will recognize.

“Paper” please

When Epistory was just in the shape of a playable prototype, we were just finishing a serious game on 1st world war. Despite the seriousness of the theme, the Art Direction of this project was really cute, showing flat scrapbooking characters and paper styled interfaces.

Our game about 1st world war. Notice the “scrapbooking” art style !


We really enjoyed making all the game assets with this look, but couldn’t push the style beyond the limits. Then Epistory came within our grasp: “A muse lost into a writer’s mind, creating the world as he imagine the story, fighting against the blank page fear” ? Hell yeah ! We immediately saw that we could continue with the paper style thing, but pushing it a lot further into a full 3D game !

Art “right” Direction

We first started to look for interesting references and we made moodboards with it.

Some of our “papercraft” styled references


We quickly noticed that the scrapbooking style couldn’t be enough. Despite the 2D movements of the avatar, we had to make full 3D environments, and relying only on 2D paper collages would appear flat and boring. We decided to go for a more “papercraft” approach, with some additional elements taken from the origami techniques.

First 3D test to see what we could do with those papercrafting/origami techniques. Once we defined the shapes, we worked on a basic colored layout.


Paper pot

After testing differents approaches we ended up with a mix of different paper techniques:

> Scrapbooking for the environments ground tiles:

> Animated objects made of paper crafted volumes for destructible assets:


> Folded paper for texts and logos:

> Origami/folded paper for the monsters:

“Hot paper”

Once we had chosen the path of paper, all the assets had to stick with it, even special effects and particle systems ! We made “folded paper” styled textures, and used almost no alpha or additive techniques. It was complicated at first to find elemental paper styled effects to replace “classic video game effects”, but once we did the first ones we just had to stick to the technique.

 Fire effect without using the classic additive method, only with plain opaque paper sheets !


The major drawback of this Art Direction is that it is often difficult to create assets “looking like paper” but with a non realistic look. We wanted to keep things cartoonish, with strong shapes and colorful
environments, but when you have to make a style of paper you can find in real life, the risk is to end up with a great but too realistic asset. The difficulty is to make believable paper looking assets, but still looking cartoon… It’s an everyday fight to maintain consistency between the assets, but
the challenge is motivating and we believe the final visuals of the game will make it really unique !


Like the game on Facebook

Follow the game on Twitter

Epistory: Lessons learned while switching to Unity

Thursday, April 16th, 2015

More about the game on indieDB



Paradigm Shift

When we started working on Epistory, we had to choose whether to use our proprietary engine or not. For reasons that go beyond the scope of this post we decided to go with Unity. While the prospect of working with a tool as streamlined as Unity was stimulating, after five years working in a workflow dominated by C++ my C# habits were rusty if not inexistent.

After some time with C# I remembered and saw some of the neat tricks you can do with this language. I also received and read a few tips for Unity itself that can do wonders to keep performance high and coding time low. I will keep this as code free as possible and direct you to the relevant documentation -if necessary- to get all the juicy details that would needlessly blow up the length of this post.

Stay organized

While Unity is very flexible and lets you do basically anything, it can be a blessing as well as a curse. If you don’t force yourself to organize the project and the code from the start, it will become messy really fast. One performance hit that is negligible at the beginning but can grow into a big problem later down the road is the caching of your GetComponent(). Basically each time you ask for a specific component in a GameObject, Unity will go through its component list. In most cases you can safely cache the result and keep a reference. If you start adding components at runtime you’ll have to decide whether to cache it or not.

Leave no warnings behind

Even though most programmers will treat warning as error -or at least minimize the amount of warnings- it bears repeating. The more serious warnings are almost always a bug waiting to be triggered. That is even more important in C# because of some leeway given to the developer. For example: you can hide a virtual function if you don’t explicitly add the override keyword to the sub-class function declaration. And a warning will remind you to make your intentions explicit. The difference between overriding and hiding is that the overridden function will call the runtime type and the hidden function will call the compile-time type.

False friend

The switch statement is a good way to keep the code readable. But in this case its behavior is slightly different in C#. You cannot fall through to the next case section. You have to place a break/return/goto… However, there is a walkaround. You can use something like “goto case 1;” to jump to another case. More details here

Missing Link

LINQ can be a powerful tool to interface a program seamlessly with a database. Even though its syntax can be off putting, you should at least try it before you leave it. You can use SQL-like statements to query an xml file, for example. You can also use it to perform operations on IEnumerable (a.k.a. Arrays and Array-like) classes. All you can eat buffet here


Daily routine

Coroutines can be achieved in pure C# but Unity made their use very easy and intuitive. It is akin to starting a new thread without the problems associated with thread safety issues like concurrency, race condition & deadlock. The coroutine also behaves like any other member function. It has access to other functions and member variables.

I will leave the implementation details aside (see links below) but know that it can easily be used to provide easing to an object over time or calculate the next score increment. Another, more advanced, use-case is a very elegant way to implement a state machine. More information here and there and state chartshere

Eventful delegation

Event firing and registering is built into the language. Events & delegates are two sides of the same coin. The delegate provides an equivalent to an array of function pointers and the event is the message being sent. This makes for painless event driven programming and we all know how much a game can be event heavy.

This could make a post topic by itself so I leave you with the documentation and an in depth tutorial/study


There you have it. A non-exhaustive list of tips, tricks and gotcha. Thank you for reading and feel free to ask any question in the comments.