Posts Tagged ‘indiedb’

Indie of the Year 2015

Tuesday, December 1st, 2015

Update: We didn’t make it but we’d like to thanks all the people who voted for Epistory. Next year you’ll do it! 

Hi Folks, 

It’s the 6th Annual Indie of the Year Awards, a celebration of this year finest indie games chosen by indies fans. If you could give us a hand and vote for Epistory on IndieDB it would be great. The top 100 will be announced on the 11th of December. Let’s do our best!

Go my army. Spread the word around you! 

rabbit_army_smaller

Thank you very much. 

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.

GD_article_img_1.png

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.

GD_article_img_2.png

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.

GD_article_img_3.png

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.

GD_article_img_4.png

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 !

“Crapbooking”

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

epistory_c_to_unity2_455px

 

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

 screenshot_epistory_prog2_455px

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

Epilogue

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.

Epistory: It all starts with (good) intentions

Friday, April 3rd, 2015

FB_avatarMore about the game on indieDB

The beginning

When you start creating a game. When you think you have a great idea to turn into a great game. When that idea has just been tested and when your team thinks it may become that great game you have in mind. There is something you have to do without waiting. You may have already done it during the early design process but the original vision has changed now that you made different rough gameplay tests and added new members to the team. That thing – the title already spoiled it – is defining your intentions.

Whether you call them guidelines, pillars, objectives or mantra, it is the long term vision, the global idea of what you want to do with your project. You should keep it to the essential, as it will serve as a reference to drive the whole production.

Epistory is a keyboard driven game. So that is obviously one of our intentions. But there is another one we have, not so obvious, and which came from its genre. Define the genre was needed to better define the game and communicate about it, and that is exactly why it was a problem.

The Typing Game Problem

Our core feature is the full keyboard control. So I already hear you say that we could just call it a typing game and move on. The problem is that, when I think of a typing game, I have two things in mind – and it’s not just me, a quick google search will give you the same results. First, it is most likely a mini-game or an edu-game. In other words, something I do not plan to play for a long time, or to have fun with. Secondly, I will only type words. No deeper gameplay, no choices. And eventually my computer will remind me that I am not a very good typer!

Do not get me wrong, those games are not all bad – some are even really fun for a while. But they are absolutely not comparable to Epistory: the term typing game gives the wrong idea. In fact, it is probably harder to explain what we try to do with Epistory using this comparison than starting from scratch – but now that we are here, I will try anyway.

How it works - Move screenshot

Playing a game means making choices

What we absolutely want in Epistory is to make it really feel like a game and not just a typing application. For that, we believe that it requires a non-linear experience and meaningful choices. And when I say meaningful choices, I am not talking about a big decision which follows you for the rest of the game – well, not only that – but constant small choices. A few examples in games would be taking the short risky path or the long safer one, exploring the east or the west of the magic forest first, upgrading one skill instead of another… Even positioning your car in the fastest racing game implies constant quick choices. You made them depending on the track, your opponents’ position, your current speed, the ideal trajectory, and so on.

To make those choices meaningful, I try to remember that as a Past – Present – Future rule. The player needs to understand that he has a choice (Present). He has to know what it means from past experiences (Past, in this game but not only). And he has to expect something in the future from his action (Future). If it is not a meaningful choice, the player is not an actor but just obeys the game as there is no other possibility of action.

We made that one of our intentions – even if it is important in every game – to make sure it was applied to Epistory’s design. I am not going to describe Epistory’s gameplay deeper on this article – there are more to come, but we will not fall into the trap of your ordinary typing game.

Main character concept

A keyboard controlled adventure

So Epistory is an exploration / adventure game, and we like to call it like that. It gives the player the opportunity to explore an imaginary world, use magical powers to interact and fight enemies, and upgrade them as he wants.

You should see the typing aspect as an opportunity, not a constraint. Because that is what we did: using a keyboard as the unique game controller to create new gameplay experiences. Not only to type words, and not only to earn points. We like to say that you will type the story – but that is for another article.

Thanks for reading. Don’t hesitate to support us on social networks.

Website coming soon