Unreal Engine – Exposing Functions and Variables to the Editor

This is a repost of something I put on twitter a while ago when I first started learning Unreal Engine last year which was how intuitive it was to expose things to the editor. Unity lets you expose variables to the editor by using the SerializedField attribute. Unreal Engine has a similar method in the form of UProperty.

I have shamelessly stolen the example from the Unreal Wiki (for context this is here as part of my notes as well as a reference for anyone else), but if you do the following:

//How long, in seconds, the countdown will run
int32 CountdownTime;

You will see the variable appear in the editor:

Also, you see there are comments in the code. These also get exposed to the editor.



What is even cooler is you can expose your own code in the blueprint system. I love the blueprint system, it is powerful and is great for visualising the logic.

In one of my older projects, I had a need to expose the move direction of the player. By adding the UFUNCTION macro with the BlueprintCallable argument it is exposed to the blueprint system!

You can find out more about this on the Unreal Wiki:



C++ Struct Memory Layout

Image result for God of war

I have been playing God of War recently (also known as Dad of Boy) and it is amazing. Out of curiosity I looked at what it would take to be a gameplay programmer (I am not planning to move to the states, but you know, you never know what the future may hold) and once again it said “expert C++” or something along those lines. Although I live in C# Unity land most days, my C++ is pretty good, however I would hardly call it expert. I thought I should brush up on some of the more slightly more advanced parts that I don’t usually run into in C#/Unity programming day to day.

The first of these tips and tricks is C++ memory layout, most importantly the order of member declarations in a struct.

Lets look at an example.

struct S
    char Char1;
    int Number1;
    char Char2;
    int Number2;

If we calculate the size of each member using size of:

  • Char1 – 1
  • Number1 – 4
  • Char2 – 1
  • Number2 – 4

And if we do a sizeof of the whole struct we get is 16. Hang on, our calculations don’t quite add up here. 1+4+1+4 = 10. The structure is 6 bytes longer than the sum of its members. Huh, why? Maybe if we change the order this will change things.

struct S
    char Char1;
    char Char2;
    int Number1;
    int Number2;

The we do a size of again. This time the size of shows the struct is taking up 12 bytes. Moving the Char2 declaration caused the struct to shrink by 4 bytes.


Well the hardware here is optimized to read data from memory addresses which are multiples of the data size. Ints are 4 bytes and are thus read from addresses that are multiples of 4 So ints would be read from addresses such as 0, 4, 8, etc. a char on the other hand is 1 byte and are thus read from addresses 0,1,2,3, etc.

The problem is, C++ 11 standard states that data members are allocated in memory the same order they are declared assuming they have the same access specifier. In a struct all members are public causing the data to be laid out in the order defined by the compiler.

Essentially what happens is the data gets padded when allocated. The following diagram shows what happens.

The compiler starts with address 0, allocating the byte for Char1. As the following addresses are not multiples of 4 they are skipped. They are not suitable to put an int32 in. Therefore Number1 gets allocated to address 4 to 7. This causes padding in the struct and thus the struct gets larger. If we take a look at the rearranged struct:

The padding is a lot better on this struct as the members are aligned in better addresses.

In conclusion, the layout of C++ objects do matter. If you pay attention to the location of each member you can make your structs smaller and leave less of a memory footprint. Neat huh?


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: