Posts Tagged ‘Game Design’

The Trouble With Tiles

All of Epistory’s levels start as an isometric RPG in Tiled (as explained in this prior article). This is a great foundation to build on – but it brings some technical limitations which we have to deal with. For example, we have to respect the TiledToUnity plugin rule that each tile must be a square of equal size. It doesn’t help that any tile rotation must be done as a duplicate tile instead of a random effect.

As a result of this, the tiles use to build each level stand out too clearly. We can see the seams, the joins, the patterns. The effect is fatal to immersion within the game world.

This old screenshot illustrates the problem nicely. Each tile is the same as the previous one, creating a very obvious pattern. This is just a small example – sometimes the whole screen will have the same tile, interrupted only by the occasional prop or decoration.

In this article, I will guide you through the steps we used to break this ugly pattern and improve the overall look of the ground tiles, which currently look like the screenshot below. It’s unlikely that we will change the tile’s look again – but you never know.

Start at the Start

If it sounds obvious, it’s probably because it is! Rotating each tile will help make it look different and vary the seams created where they join.

We started by rotating our tiles randomly with an editor script. Since our goal in art direction was to create a hand-made paper world, we decided early on that a tile would be considered an independent square of paper. Based on this fact, we agreed that imperfect tiling between two tiles was acceptable: meaning that rotation gives us variation. The result was better but still a bit jarring.

Lean Towards the Abnormal

Because each tile is supposed to be a piece of paper, it’s hard (not to mention expensive) to make each one visually unique. We aimed to solve this by dynamically changing the normal map on each individual tile.

A normal map is a 2D image used to replace or modify the normals of a 3D surface. Because our tile models are mostly flat, we use normal maps and lighting to give them some paper-looking wrinkles.

Here’s how we modified our ground shader in Shader Forge:

world position.

a parameter which allow us to tweak how much a change in world position affects the overall look.

division.

frac. It takes only the fractional part of the input. Effectively producing a value from 0 to 1, based on the world position.

append allows us to create a vector 2 (UV in our case).

normal map sampling.

normal blending. You cannot blend normals the same way you blend colors so we use a custom formula.

The effect of this is that instead of having one normal map per tile and limited to its bounds, we have two normals, whose UVs will depend on their world position. This effectively spans (and repeats across) the whole level. If you look carefully you can see that one of them will have U & V depending on the positions X & Z while the other will map U & V to Z & X. This “crisscross” allows us to have very different looking tiles each time, instead of having the pattern being simply repeated less often.

If you want a more visual way of understanding this, you can see it in the editor view. We created a gif but it was too heavy to be posted inline. You can find it here.

You can see that when I move the tiles, the normal on top of it doesn’t move. The apparent seam on the normal is a result of the tile rotation around Y.

As a bonus, we also added a detail texture. It’s a common technique so I won’t explain it here – but here’s the shader forge screenshot:

Perfect Imperfections

This was the first time I did major shader work and it turned out quite well in my opinion. With the current art direction we had to improvise a bit – but we successfully fixed the tiling problem with no rework on the assets. This results in a seamless, believable game world.

Introduction

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.

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.

Conclusion

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.

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…

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

Welcome to another installment of our fluffy sweetness. If you missed our Critters gifs last week you can check them here.

Ok! To recap, we had a world quite pleasant to walk in, decent levels and dungeons, epileptic Critters… and a girl riding a giant fox fighting against monsters and corrupted nature. Fighting how? With words. I mean MAGIC FIRE WORDS!

So, here’s the fire animation, shown in our previous paper on art direction, in action. Yes, we know, burning the forest is bad but these brambles were evil, very very evil.

Imagine you’re hanging around with your fox and brambles block the road: burn them! There are monsters on your way out from the dungeon: burn them! There are cute critters… wait… stop. May I draw your attention on the fine and not final spell forging animation before the girl sets the world on fire?

Hope you felt the magic. See you next week for another incredible Fluffy Friday!

Discovery of what unity can do in terms of jiggly bones and overriding animations.

The inception

A while back, after slowly becoming mad tweaking animations and movement behavior on our avatar, I decided to have some simple fun with Unity. See where the limit was and what’s possible in a certain domain. Since I was obsessed with the character’s animation, my attention was driven towards improving what our animator gave us in terms of natural movement. Even though the animations were quite good, I wanted some physics madness in there. So I went on a quest to mess with the bones of mecanim.

It turns out it’s rather straightforward to activate the so called “jiggly bones”. A few changes in your model before export does the trick. It does however require a great deal of value tweaking and physics engine know-how. You may follow this tutorial if you want to try it for yourself.

Here’s what I could do as a quick ‘n dirty test. This will *not* be in the game. Even if the effect could be nice, It is at the bottomest bottom of our priorities.

But doing this as a playful “what if” helped me learn a lot about how Unity works with animations and physics. Even better, I would never have thought of what I’m about to show if I hadn’t gamed the system.

A few days later, the movement and animation finally polished, I found one last thing I could do, turn the head of the fox in the direction of where the avatar will go next. Providing a subconscious feedback on the movement. Using the head bone and overriding the animation, it should be possible. Right?

It turns out it is. This gif was taken when a bug prevented the fox to move or turn so you can clearly see that the head orientation is overridden (and a bit disturbing, sorry).

The result

Here you can see the result in game. Slowed down on purpose to make sure it’s seeable in a gif. The effect is very subtle but you can see that the head will always point to the right direction (almost instantly) and the body follows soon after.

The next time you are frustrated with a particular task or simply bored out of your mind after a day of repetitive tweaks. Do yourself a favor and just play with the tools on your workbench. Who knows what kind of gem you’ll unearth.

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*

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

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.

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:

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.

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.

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 randomnessIn 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 proceduralAnother 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 variationsFinally, 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.

Sorry about the late update, it was meant to be posted Friday but we were a bit busy… anyway, let’s have an overview of Creatures Online’s ecosystem today!

Here’s how the player can interact with ecosystem:- Tap on a critter to wake it up- Critters can’t be drag & dropped directly, but it is possible to move them like decoration elements after clicking on the corresponding icon on the interface allowing you to move / sell agents- Small critters (such as insects) generally can’t be interacted with- …but some can still be drag and dropped (for example, fishes)- …and you can still tap on some other ecosystem-related things, such as bee nests

And here’s how the Norns can interact with it:- Even though the players can’t interact with every insect, Norns can. Sometimes they hit or eat some insects, which you can reward or punish.- Flowers, mushrooms & grass patches grow naturally and are randomly placed.- Ecosystem varies depending of the environment. For example, the Hatchery consists mostly of flowers and butterflies. Thus, placing an insectivore critter may be a bad idea as butterflies tend to stay out of reach (yes, you can see the critters eating grass / insects)

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.

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.

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.