Unity Triple A – Characters looking at stuff via IK

I have been talking about doing this for ages, and as my interest for Triple A techniques increases and the blog was looking a little sparse, I thought I would do a few tutorials on more Triple-A techniques. In this article, I am going to talk about using Inverse Kinematics in Unity and in particular characters looking at each other.

If you have ever played games like Uncharted 4 or Final Fantasy XV, when characters talk to each other whilst the player is controlling them, you will see them physically look at each other. This to me is really cool and adds a level of immersion that you wouldn’t get if the characters “just” talked to each other. If you look at the gif above you can see a transform being moved around the environment and the characters head looking at it, whilst the rest of his body is still. That is the sort of thing we will be looking at in this article.

So firstly what is IK?

Well in simple game dev terms, it is an animation technique.

Most animation is produced using a technique called forward kinematics. This is where an animation is created by rotating the angles of joints in a skeleton to predetermined values. The position of a child joint changes according to the rotation of the parent and thus the end point of a chain of joints can be determined from the angles and relative positions of the individual joints it contains.

Inverse Kinematics is working backwards to forward kinematics (hence the name!). By taking a chosen point in game space, you work backwards and find a valid way of orientating the joints so the endpoint lands at that position.

In simple terms, it allows us to make characters do stuff like point at things, look at things, touch an object at a specific point, etc in a more dynamic way. Unity actually has this built into Mecanim, which is pretty sick.

In order to get IK working you need a “correctly configured avatar”. In order to get one easily, I grabbed the Ethan from the Standard Assets.

Then we go an make an animator controller with his idle animation and set it up for IK by clicking on the little settings icon and enabling IK pass.

Then make sure your animator controller is actually assigned to your character’s animator.

Setting up the character to look at stuff is super easy. Create a new script called IK Controller and add the following:

Add a sphere into the scene and set it up as your _lookObj. Set up the other references. Run the game and move the sphere around a bit and viola.

We have a system similar to what is shown above.

Now in conversations, you can do a distance check if the characters are close enough you can enable the IK look at.

There you go. Easy!

If you want a sample project all the code lives here:


User-friendly data tools for my JRPG

Image result for persona 5

I haven’t done a project blog in regards to tech in like forever. In fact, I haven’t blogged in like forever. HI! So yeah I finished Persona 5 (hence the picture) and it took around 90 hours. And that game is a JRPG. And I am working on a JRPG so see it is kind of relevant right!

So today, I am talking about how I am doing some of my data tools. JRPG are giant houses of numbers. It is like your overpacked loft… but instead of the random crap you have collected, it is numbers. And you want to be able to change these numbers all the time for balancing.

As I said before I built a sort of equivalent CMS system in my game. It is the loosest phrase of “content management system”, but as I said in the previous post, I modelled what I was doing by separating data, etc from my work at MediaTonic, who have a quite frankly world class CMS that is hundreds of times better than others I have used. Like I mentioned previously, I make heavy use of scriptable objects:

For some designers, however, double-clicking on the curve and editing it from the editor can be quite cumbersome. And writing Editor GUI code in Unity is quite frankly out of the question, because it is well… horrible… so I came up with a slightly better solution.

Google sheets. In google sheets you can build your data really nicely, view it in graphs and curves to see progression and can be used for balancing.

I came up with a sheet schema as above and then wrote some a little editor script:

And also a static parsing class to parse the data from a csv file to my game data:


What the editor script does is add this little button to my battle character scriptable objects:

And uses the parsing code to fill out those curves.

Therefore we can use the power of a spreadsheet program to plot our graphs and then load the data in and apply it to our scriptable object.

Neat, huh?



Researching a replacement for dynamic shadows continued…

I am still playing Nier: Automata so you will get a few of these pics for a bit.

A while back, I posted an article about researching a replacement for dynamic shadows.

On projects I have worked on we often default to using dynamic shadows to make stuff look good, but they can kill our performance on mobile. In order to hit the 60 FPS mark (or sometimes even 30) theya re one of the things we turn off. We then replace them with blob shadows, which are OK, but are still not as performant as we may like I found this advanced technique called graphics command buffers and a sample that includes decals in deferred shading. Decals are quite a nice way of creating blob shadows.
I have since knocked up a super quick test bed to see the difference between real time shadows, projectors and decal textures.
Realtime shadows:
And here are there corresponding BASIC stats:
Real time shadows:
Projector Blob Shadows:
Decal blob shadows:
Again, this is only a cursory test, but so far the decal blob shadows are edging out on the number of tri, batches and overall framerate. Of course this is needed to be taken with a pinch of salt and needs to be profiled more in other scenarios, however as a starting point it looks promising.
My next step is to see if I can create real time shadows using render textures and combine it with the decal techinque.
There is a warning here though that at time of writing this technique only supports deferred rendering and not ALL mobile gpus support it. However, I will press on and get a better overview of what hardware is affected, and come up with an alternative for that.