Hey everyone! We’ve got a couple of things to catch you up on, so listen up!
We’ve been working on our own game for a little while now, and we’re proud to announce Floppy and the Sleepy Planet! It’s a cute little precision platformer, in which you control the eponymous Floppy, a robo-bunny, on his journey of exploration and self-discovery across a mysterious and seemingly abandoned world.
If you’ve been following our various social media channels, you’ve probably already seen more screenshots and video of the game. We originally started working on it in the April 2016 UE4 Gamejam under the title “Grabbity”, and enjoyed such a positive reception - it was selected as one of the winning entries by the Epic Games team - that we decided to keep working on it.
Since then we’ve expanded and refined it, decided on a better name, and even shown it off publicly at a few conventions. We’ll try to blog more about it as we make progress, but in the meantime, why don’t you do the subscribe-like-follow thing? Just use these handy little buttons:
In other news, we’re happy to announce that Remi Crespo has joined the Broad Strokes team on a permanent basis! We’ve been working together for over a year now, and are now officially business partners. Check out the Team page for a photo of his face and a little bio blurb about him!
If you’ve visited this website in the last few days, you may have noticed a safety warning pop up in your browser…
I’m sorry to say the reports were right. It appears that a malicious WordPress plugin has injected some malware into the site, full-on redirecting users to an ad-site (which was probably also infected with malware) the first time they clicked on anything. Well, we couldn’t have that now, could we? Nuke it from orbit, I say! That’s why, instead of trying to salvage WordPress with all its bloat and thousands of fragmented PHP files, I decided to move the whole website over to a static site generator.
This site now runs on Jekyll, although “runs on” isn’t quite correct - Jekyll runs on my own computer at home, and I use it to generate a whole static website from a bunch of text files, which I then upload to this web server, where you can access it. That has the advantage that whenever you load a page from this website, it’s just a static .html page - with no code whatsoever being executed on the server. That doesn’t just make everything faster, it also makes it more secure for everyone. Yay!
I’m not quite happy with the new layout yet, so expect some adjustments there. And please, please let me know if anything breaks - just send me an email or poke me on Twitter!
Again, I’m sorry - not just for the inconvenience this might have caused, but also because I hope that no one got exposed to malware themselves. As far as I can tell the stuff was only up there for a day or two at most, but you never know… Everything is nice and new and clean again now though, and happy faces prevail!
Unfortunately this emergency website surgery also means that I couldn’t finish part 3 of my Power of Math™ tutorial this weekend, and you’re going to have to wait for it just a little while longer.
Welcome back, everyone! This is part 2 of my tutorial mini-series about how to make things move nicely using your awesome powers of math! (See part 1 here)
As with part 1 of this series, I’m going to assume that you know at least the basics of Unreal Engine Blueprints already – if not, check out this official video tutorial series by the Unreal Engine team, which should get you started! And since I only just set it up a few days ago: If you want me to keep you up-to-date with new tutorials I release, why don’t you subscribe to my mailing list? You’ll get notified when I post cool new tutorials or other interesting stuff!
Just to catch you up, I’m using this asset here to demonstrate a few simple ways of how to animate something using only blueprints and math:
(Shown at 8x speed)
In the first part, I showed you how to create a nice swiveling motion. This second part is a bit simpler, and it will teach you how to improve that swiveling effect by adding some soft bobbing motion. Let’s turn off the swiveling for a moment, so you can see what the bobbing motion looks like all by itself:
Looks simple enough, right? And it also moves kind of unpredictably, which is exactly what we want. So, how do?
Who’s this Bob guy?
Let’s define bobbing motion as smooth up and down movement, like what happens when you put an apple in a big bowl of water, and then punch it slightly, but not in a mean way. It’ll start bobbing up and down a bit! Bad example, probably, but I think you know what I mean, right?
So, how do we do this? We’ll need to use our awesome knowledge of sine functions that we either already had or acquired in part 1 of this tutorial.
As always, illustrations help! Did you know that sine functions can be expressed like this?
Let’s look at the right part of it first. On this graph, the X axis (the horizontal one), tracks the rotation angle. If you’re curious about the π stuff, don’t worry about that for now – that’s a different way to write angles, called “radians”, which you might have heard of. For ease of explanation, we’ll just use degrees – but if you’re curious:
You may remember from your math classes that the circumference of a circle is equal to its radius, multiplied with 2 π, or in equation form:
c = 2 π r
Think of radians simply as the length of circumference, relative to the circle’s radius, you get at a circle section of that angle. As you can see in the animation above, at 360°, the radian value is exactly = 2 π, which is exactly the value for the circumference of a full circle. If we only take a half circle, i.e. a 180° angle, the radian value is half that = π.
Some functions in UE4 use radian input instead of degrees, and for some others (such as the trigonometric functions like sine, cosine, and tangent) there are two versions – one for degrees, and one for radians. Just something to be aware of!
So, what interests us here is purely the vertical movement on the Y-axis over time. Sine functions are a great way to create cyclical motion, and that’s exactly what we want. Take a look at how it looks if you animate a point using just a sine wave:
The fun begins when you start to layer multiple sine waves with different periods, phases and amplitudes on top of one another, and that’s just what we’re going to do! Why, you wonder? Take a look:
Layering multiple sine waves
To explain why layering multiple sine wave functions is cool and useful, let’s do a quick recap on the words we use to describe certain attributes of sine functions.
Amplitude is the height of the wave’s peaks. Perhaps you’ve also heard this in the context of audio already – that’s because sound waves are waves too! And the higher the amplitude, the stronger the pressure in the air that carries the sound, and therefore, the louder the sound. Makes sense, right?
Period is how long it takes for the function to do exactly one full cycle. Frequency, which you’ve probably heard more… frequently (I’m sorry) is used to describe the amount of full cycles per second. So basically, period and frequency are the inverse of each other – period is “seconds per cycle”, and frequency is “cycles per second.” When I build blueprint tools, I tend to use either, depending on which one gives users the easier to understand number. (Remember: Build easy-to-use tools! The rest of your team will thank you. Or just take it for granted, because you’ve spoiled them… oops.) For example, a frequency of 0.0167 is a lot less convenient for making small adjustments to than a period of 60 🙂
Phase, lastly, is the horizontal offset. Unmodified, the sine function starts at 0/0, and then starts swinging upwards. With a phase of e.g. 0.5 as shown above, that 0/0 point is offset by 0.5 units to the right – or if we’re looking at it as a movement over time, it comes 0.5 seconds later.
Since we’re going to need it later, here’s how you express those attributes mathematically in a function:
y = [amplitude] * sin ( ( [frequency] * x ) – [phase] )
For ease of explanation, we’re going to ignore amplitude and phase for now, and just look at what combining multiple sine functions with different frequencies gets us! Let’s start with this sine function here:
As you can see, it has a period of about 2.3. Here’s another sine function:
This one has a much higher period, which is why it looks so much flatter – its period is about 20.
Now I wonder what happens if we just add the two functions together…
Can you see what’s happening? The function with the shorter period looks like it’s doing some oscillation of its own, in the same pattern as the other function! Let’s add another one:
And now, we’re getting somewhere! Doesn’t that already look pretty irregular? There are of course still recognizable peaks and valleys, but it’s a lot harder to make out the overall repeating pattern now. Which is why we’re going to use three functions with configurable periods and amplitudes to give our rock a nice, irregular-seeming up-and-down movement.
Alright! Enough graphs, time to look at some Blueprint graphs instead!
3D Widgets: Drag & drop instead of type & hope
Before we go on – Do you want to know how to make these nice little handles that let you move stuff around without manually typing values by hand?
Those are 3D Widgets, which are available for any Vector or Transform variable set as “editable.” Just select the variable in the My Blueprint list, and enable the option!
That will create one of those widgets for each such exposed variable. It even works for arrays! With vector widgets, you can only move them, but Transform widgets can be rotated and scaled as well. That can be quite useful when you’re building tools!
Note that I’ve also set the “Advanced Display” flag for this variable, so that it doesn’t show up in the Details panel unless users click on the little triangle button that expands the advanced options.
The second part of making parts of your Blueprint adjustable like that is to do something with the value of that 3D Widget’s vector variable, and in our case that means we have to set our TopMesh to the new default location in the Construction Script, and that’s all. Whenever a variable in a blueprint is changed, the construction script is executed again, so the location of the Top Mesh component is set to the new relative location the widget was just set to. Just like this:
Bobbing, coming soon to a UE4 near you!
So how do we do this bobbing thing in UE4 then? Simple! We are going to re-use a lot of the things we learned in part one for this. First off, let me show you the part of our Blueprint that is responsible for the bobbing movement. This is the relevant part of the Tick event:
<figcaption class="wp-caption-text">Click to enlarge!</figcaption></figure>
Don’t worry, it looks more complicated than it is, and we’re going to pick through it bit by bit. If you ever find yourself looking at a Blueprint and wondering what the hell is even going on, here’s a useful tip for you: most Blueprints can be best understood by working backwards! Start at the executable functions (the ones with the white “execution wires” going into and out of them), which tell you WHAT is being done. Most of the time, those have really helpful tooltips too, if you hover your mouse over them and their variables. Think of executable (also known as “impure”) functions as one line of code. They basically say: “And now, do this!” Any wires that go into these functions ‘only’ specify HOW that function is supposed to do its job.
So then, let’s start with the “What” in this case, and work backwards through the “How’s”!
Fairly straightforward, I hope. We add two vectors, “Top Mesh Location” and one that we’re creating right there on the spot (with some more math that we’ll get to in a bit), and setting that as the new relative location of our floating rock mesh.
Next up, HOW do we calculate that vector which we add to our Top Mesh Location vector?
Look closely – it’s just three sine functions which we’re all adding together, just like in the graphical example above! Each one is also multiplied with its own amplitude variable, which just means that the output of the sine – which is in the -1 to 1 range – gets multiplied with it. So the amplitude variable is the distance in world units that each wave function makes the rock move upwards and downwards.
Lastly, here’s how we calculate the “Bobbing Cycle” variables:
If you remember part 1, this is almost exactly the same thing we did for calculating the progress of the swivel motion! That’s because it is 🙂 Each “Bobbing Cycle” gets something added to it on every tick. We multiply Delta Time (Get World Delta Seconds has the same output as the Tick event’s Delta Time output, so if you want to get rid of some wires…) with 360, so that one second equals one full rotation, and then divide it by each bobbing cycle’s period to make sure that each cycle takes [period] seconds. That then gets added to the existing Bobbing Cycle variable, which loops back to 0 when it reaches 360. All stuff we’ve done before, at this point!
And if you combine this with the swivel motion we did in part 1, you get a very nice, seemingly irregular movement of the stone, all without even touching any animation tools. It’s The Awesome Power Of Math™ at work for you!
Well then! That’s it for now. Part 3, coming soon, will finally go into how to create those little orbiting rocky bits. It’s really very simple, but in the process you’ll learn a lot about how to customize things, and about random seeds which might give you a start on creating procedurally generated content in Unreal Engine 4! If you subscribe to my mailing list, you don’t even have to check back here yourself to see if it’s out yet – just saying!
So, you thought to yourself, “Man, wouldn’t it be cool if I could add some floating rocks to my level?” Well, I heard those thoughts you were thinking, so here’s a quick tutorial for how to do that kind of stuff pretty simply with blueprints!
This tutorial assumes you know at least the basics of how to use UE4 Blueprints – I’m more concerned with showing you the why’s and how’s of the math, and the thinking behind these things. If you have any questions, feel free to use any of the social media methods linked above, or just post a comment!
The thing we’re going to build
I just built this tool here yesterday for a scene my friend Jon Riley is making (all meshes and textures used here are made by him!), and we’ll use it as an example to show some things you can do to make those stones float nicely:
It’s pretty simple, really! Let’s look at the big stone at the top first. As you can see below, it does some very slow undulating rotations and a bit of bobbing.
Here’s the same thing at 8x speed, so you can see it better:
Let’s pick it apart then, shall we? 🙂 As you can see in the sped-up version of the video, the rotation of that rock is basically a swivel motion, combined with some vertical bobbing. The swiveling is more interesting, so let’s tackle that first!
Swivel those rocks!
Swiveling is defined as “turning around a point”, though in this case it makes more sense to think of it as rotating around an axis. Here’s a visual illustration of the math we’re going to use:
To get started with that, let’s first create the swivel vector in our blueprint’s construction script. If you paid attention in the video at the start of this post, you’ll have noticed that the user control for this is not a vector input, but just a float to specify the swivel angle. To get a swivel vector from that, we have to do our first bit of math!
I added some squiggly notes so that you can hopefully better understand what does what. The Swivel Cone X/Y float variables are editable variables that your level designer can use to tweak how exaggerated the swiveling should be. Swivel Axis X/Y are our blue vector above, for the X and Y axis respectively. We’ll rotate those around the local space X/Y axes on every frame by a little bit, in order to get that nice undulating swivel motion.
It’s no Sine to enjoy maths!
Now, I assume that you already know at least the basics about what sine waves are, but just in case, here’s a quick refresher in the form of an image I shamelessly stole from a Google image search:
The other input (besides the swivel cone angle) that level designers get with this tool is the rotation period. As the diagram above so helpfully illustrates, that means: the time it takes to perform one full cycle. I decided to use period, because it’s the most human-relatable number, even if it makes the math we’re doing a little bit more complex. Always plan for user-friendliness! The less you have to explain how the tools you build work, the more time you can spend actually building your tools 🙂
Here’s the math that creates the swivel motion:
Alright now, don’t get intimidated! This is actually quite simple. Let’s pick it apart bit by bit!
On Ticks and the illusion of smooth movement
First of all, what’s a “Tick”? Does it bite? No, Tick is an Event that gets called by the engine on every single frame that is rendered. It’s a common misconception that somehow things in a game are happening smoothly and gradually. The truth is that things happen in steps. Very small steps, yes, but still. For example, if your game renders at 60 FPS, that means there are 60 steps to everything, every second. Game engines generally work like this: First, all the logic is executed. For example, every moving object has its position and rotation updated by whatever drives it, projectiles fly forward, player input is received and handled, and so on. Next, the engine takes all that information and gives the relevant parts of it to the renderer, so that it can produce the image that you see on screen. And then it goes back to the first step, forever repeating until someone presses Alt+F4.
So, games really only give the illusion of things moving smoothly. Just like films! Although… am I the only one thinking that 24FPS for films is really just not enough? I hope the glorious future of VR movies changes that habit…
ANYWAY. Back to the math. Let’s just look at one of those parts in isolation.
“Delta Seconds“, by the way, is the real-world time that has elapsed between the last Tick and this one. It’s great if you want things to move at the same speed, regardless of framerate! Which you should always want. Here, the first bit of math that we do is to multiply delta seconds with 360 so that one second equals 360° of rotation. Then we divide that by the Swivel Period, which, you guessed it, is the period (see that sine wave terminology graph above) for one full cycle. The result: we get the amount of degrees that something should rotate in this tick, if it has the rotation period we specified!
The next bit is pretty common too: we take that result, and add it to our Current Swivel variable. We want this value to continually count upwards, so to do that, we have to take the rotation of this frame, and add it to our current rotation. That way it continually counts upwards, and in a framerate-independent way! Neat, huh?
Now you might wonder what that node with the percentage sign is for. That’s a “modulo” node. If you remember your elementary school math, when you had to do divisions by hand, whenever a dividend wasn’t a full multiple of the divisor, you always got a result, and a remainder. Modulo is basically that: it divides input A by input B, but instead of returning the result, it returns the remainder. So, for example… 13 modulo 10 equals 3.
In this case, we’re using it so that the rotation “loops” when it reaches 360°. This won’t be noticable in game, but it’s a good practice because if numbers get too high, at some point you might run into float precision errors. Let’s not get into that right now though!
Doing something with all this math stuff we so bravely calculated
Doesn’t this look familiar to you? If not, check above! We already used the Rotate Vector Around Axis function in the Construction Script. Here, instead of using the straight-up coordinate axis as the In Vector, we use the rotated vector that we created from the cone angle earlier in the Construction Script, and rotate that around the local coordinate axis. That makes the vector swivel exactly like the one in the example with the two arrows above!
The next thing you might be wondering about: “Make Rot from XY.” UE4 has a whole number of “Make Rot from …” functions, and to understand what they do, you need to understand a little bit about Rotators and coordinate systems. If you already know all this stuff, just skip on to the next big section! 🙂
A few words about vectors, rotators and transforms
Let’s talk about Rotators first. In Blueprint, a Rotator (colored light blue, like the wire coming out of the Make Rot node in the screenshot up there) is composed of three components: Roll, Pitch, and Yaw. Roll is rotation around the X axis, pitch is rotation around the Y axis, and yaw is rotation around the Z axis.
By convention, UE4 considers the X axis as the forward direction, Y as right, and Z as up. Rotators are simply the amount of degrees that something needs to be rotated from the default rotation (facing forward down the X axis) on each axis, in order to reach the desired orientation.
“Why not just use vectors?”, you might wonder. There’s a simple explanation – allow me to illustrate! You all know this guy, right?
Think of that little blue arrow there as a vector that indicates the character’s forward direction. But is that enough information to exactly determine its rotation? Sadly not. Observe:
The character’s forward arrow still points exactly the same way, but we can all see that that’s not how it’s supposed to be rotated, right? Vectors are great for indicating locations or directions, but if you need more than that, it’s best to use a rotator instead.
This is why each and every actor and object that exists in the game world has what’s called a “Transform“. Transforms are totally neat and useful! In code, they’re usually represented by a 4×4 Matrix, which… stop, come back, don’t run away! Math just wants to be your friend! And don’t worry, in Blueprints it’s a lot simpler: Transforms are represented by Location, Rotation, and Scale. The neat thing about transforms is that you can use them to represent any transformation (a-ha!) from one spatial configuration to any other in one single operation, and you can even combine multiple transforms into a single one!
As a side-note, you may have already encountered mentions of “Relative” and “World” space. If it’s not obvious what that means, “relative” space is simply a coordinate system that is transformed so that it aligns with the Transform of whatever object its relative to – meaning that the relative X axis is the object’s forward axis, the relative Z axis is the object’s up axis, and so on.
Make Rot from what?
Alright, now that you know all that or have refreshed your knowledge, what do the Make Rot from … nodes do? Simply put, they let you specify one or two axis vectors, and create a Rotator based on that. Make Rot from X, when given an input vector, treats that vector as the Rotator’s target coordinate system’s forward vector. As we’ve established above though, one vector alone does not give you reliable results! While UE is smart and will try to guess what you mean (in the case of Make Rot from X, it assumes that the standard up vector – (0,0,1) – is your desired up vector, for example), you can get more precise control by supplying two vectors. Make Rot from XZ for example creates a Rotator that points forward down the supplied X input vector, and then rolls it (remember: roll is rotation around the X axis) so that the output Rotator’s up vector is as close to the Z input vector as possible. Make Rot from ZX does the opposite: it creates a Rotator where the Z input is guaranteed up, and then it’s rotated around that axis so that forward is in the direction of X.
Side-note: that means that the two input vectors don’t have to be perpendicular – the first one is taken as the guide, and the second one is approximated as closely as possible. Except it’s not approximation at all, but exact math – it’s all a bunch of trigonometry under the hood, but really, you don’t have to worry about it too much.
So, what are we doing here then? As a refresher, and so you don’t have to scroll up, this is what we were talking about:
As we’ve already established above, the outputs of those two Rotate Vector Around Axis nodes – over time, i.e. over the duration of multiple ticks – describe two vectors that perform a swiveling motion in a cone, of whatever angle we’ve let our level designers define, around the X and Y axis respectively. Now we simply take those two axes, and make a Rotator out of them.
And since the speed and angle of the two swivel motions are different from each other, that gives us a nice, natural-looking and seemingly non-looping undulating rotation!
So now, all that’s left is connecting that Rotator output into a Set Relative Rotation function for the top rock mesh component, hit the big Play or Simulate button, and we can see it doing its thing! Neat, huh? 🙂
Well, that’s it for this first part, folks! Part 2 will deal with the big rock’s bobbing movement, and part 3 will explain how to make those neat little orbiting stones.
I hope you found this tutorial useful! If you have a moment, please feel free leave me some feedback in the comments – not sure if I went too in-depth here, or not in-depth enough… but I hope I managed to strike a good balance. If this tutorial taught you anything, you could also do me a solid and click one of those share buttons below!
In unrelated news, Remi Crespo and I will be blogging about our casual journey of developing glorious and ultra-realistic catstronaut simulation game tentatively titled Space Cats!™ over at this new Tumblr blog: spacecats-dev.tumblr.com. More info coming soon!