Posts Tagged ‘unity’

Breaking the cycle

Monday, October 12th, 2015

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.

tile old

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.

tile new

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.

tile before

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:

2015 09 23 15 34 27

  1. world position.
  2. a parameter which allow us to tweak how much a change in world position affects the overall look.
  3. division.
  4. frac. It takes only the fractional part of the input. Effectively producing a value from 0 to 1, based on the world position.
  5. append allows us to create a vector 2 (UV in our case).
  6. normal map sampling.
  7. 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:

2015 09 23 15 21 27

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.

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. 

epistory_earlyaccess_discount2

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: Automating Action & Reaction

Monday, September 7th, 2015

A tale of candy distribution.

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.

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.

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.

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

Epistory: Fun with bones in Unity

Thursday, June 11th, 2015

More on IndieDB

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.

jiggly bones 350px

 

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?

epistory fox head move

 

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

How to do it

First, you have to get a reference to your head bone:

private void Awake()
{
  HeadBone = /*find the headbone in the hierarchy*/.transform;
}

There’s nothing to do to your model. All you have to do is use the LateUpdate function which is called afterthe internal update of the animations.

private void LateUpdate()
{
  Quaternion
    look_at = Quaternion.LookRotation(Direction, new Vector3(0.0f, 1.0f, 0.0f));
  look_at *= Quaternion.Euler(-90.0f, 0.0f, 0.0f); // Our models are rotated
  HeadBone.rotation = look_at;
}

You can do all sorts of crazy stuff with this.

The result

fox turn head subtle 350px

 

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.

}

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.