Time is an essential measure in physics systems.
And until the late 1960s, it was defined in terms of the Earth's rotational spin.
But since the Earth has been slowing down ever so slightly every year, this baseline is no longer accurate
enough for scientists.
Today, time measured in seconds, is based on the duration of rotation of a radioactive atom.
Time is a fundamental mechanic used in games.
It's not only presented to the player for challenges, but it's also used for everything from moving
objects, calculating physics, synchronizing networks and writing shaders.
With respect to artificial intelligence programming, time is used to move characters around an environment
and synchronize movements, transitions and align them with animations.
It's also the basic measure that crops up in all physics calculations.
In this lecture, we're going to have a look at how game engines, in particular unity, work with time
and the different types of time that there are time in a computer game comes from numerous sources.
Of course, there's the computer's own clock, then there's the engine itself, which also runs cycles
that aren't based on real time, but on the processing power of your computer.
You'll be familiar with Unity's update method.
This runs once per frame.
How fast it takes to run depends on your hardware operating system and the load already on your computer.
If you try and use update as the basis for real time in a game, then your game will run at different
speeds on different computers.
Unity also has a late update method.
This runs once per frame as well, but after the animation updates.
Then there's the fixed update.
This occurs in the physics cycle and it may run more than once per frame.
And last but not least, there's the graphical user interface loop.
It may also run multiple times per frame.
Of course, there's a whole lot more going on between these loops and there's great documentation in
the Unity Manual that illustrates it.
It's really worth having a look at, but what we're most interested in for working with our AI are the
fixed update, the update and the late update.
Which one of these you use will depend on what you are trying to achieve.
But my goal in this lecture is to examine the different speeds at which they run and to devise a way
for moving an AI in real time.
So to investigate each of these loops, what I'd like you to do is to create a new unity project and
bring in the Stata file, which goes with this lecture.
In it, when you open up the time scene, so this one back here, you'll find that there are four atoms
in here.
So this is the unity asset of the atom model.
One is called update atom, once called late atom, once called fixed atom and one is called seconds
atom.
If you have a look at each of these in turn, you'll also notice they have different scripts on them.
So we're going to actually use those scripts to investigate the different loops and the update.
So Update Atom has update move late Atom has late update move fixed atom has fixed update move and seconds
atom has seconds update, which is not actually a loop, but we will talk about that a little bit later.
To begin, though, we're going to open up the update move script that's attached to the update Atom.
So those scripts are in the script folder.
Let's open up update move in.
Here is just the basic update loop.
There's nothing happening at all.
What we want to do is move our character along its Z axis.
So that's forward facing axis.
We've been working with moving our characters since the beginning pretty much of this course.
So if you click on one of the atoms or let's take that one, hit the W key, it will show you the orientation
of that.
So you can see that we're working with the Z axis, the blue axis to push it forward here.
So in update move, we're going to translate our character along the Z.
Okay, so this dot transform translate and we'll add zero in the X, zero in the Y and 0.01 F in the
Z.
Okay.
So each update, it's going to move along its Z axis in 0.01 each time.
So save that.
Let's flip back into unity and press play to see what we get.
The animations that are on all of these characters are just going to play automatically.
We're not sinking them with any movement or anything that's just there for a simple effect.
Okay, so now you can see that this first update Atom is moving along quite nicely in the game view.
I've got a top down view so that we can actually compare the speeds and the movements of these different
guys as we go on.
Okay, let's now go and use the same code in the fixed update and the late update.
So I'm just going to copy this out of update move and we'll go into the fixed update and use that in
there and then the late update and use that in there.
Now with each of these updates run the same rate, then the atoms will all be moving together.
If they don't, then you'll notice there's a lag or a faster atom.
Make sure that you save all of these and let's go back and have a look at these.
So update atom is down the bottom.
This one here, then we have late.
Adam and fixed Adam.
Let's have a look at the results of this.
So as they start moving.
What you're going to find is that you get in this case, the fixed Adam is actually walking faster.
So these here, this is the update.
Adam, we know that it runs once per frame and you can see that the late Adam is also running once per
frame.
The only way that this fixed Adam guy can be out in front is that his fixed update is running more than
once per frame, which actually gives him more of a chance to add more translations than these other
two.
Okay.
So now let's have a look at the seconds.
Adam what we're going to do is use the computer's clock to move this atom.
What's going on with these other atoms is it's just running those updates as fast as your computer can
do it, basically.
So on another computer, these guys would possibly be running faster or they could be going slower,
depending on what it is.
Therefore, you don't have consistent movement between your characters and that's very important for
player experience.
If we use your computer clock to move something in, say, meters per second, which is a very common
measurement in physics systems, then it's going to be in meters per se, but it's going to be the same
rate of movement no matter which computer that you run it on.
So let's go into our seconds update and modify this code to move using the clock.
First of all, I'm just going to add a couple of variables.
What we need to do is keep track of when our update starts so that we can take away any sort of ticks
that have happened before we've got to this point and not use those ticks.
So that's going to be our sort of time start offset equals zero.
And then we only really need to set that up once.
And I'm going to create a bool here, not a float.
So bool got start.
Time equals false.
So Unity has a measure to tell us how long our application has actually been running, but we need to
know when this update actually happened so the application could have started running.
And then 5 seconds later, for example, this update started.
We want to make sure we get rid of those initial 5 seconds.
So in here, if not got start time.
Then.
Time start off set equals time real time sense start up and then we'll set got start time equals true
so that it doesn't go back inside of that if statement, then we'll use this time to actually move our
character.
So this dot transform dot position, we're setting the position because this is ticking up.
So it's getting bigger and bigger and bigger the longer this application actually runs.
So we don't want to keep translating it because it would be like some sort of exponential translation
and move your character too far.
So we're just using the position to update that.
So new vector three.
The first will be the current x value of this character.
So transform dot position dot x, then we want the Y to be the same.
So this dot transform dot position dot y and the z value will be time dot real time since start up minus
our time start.
Offset.
Okay.
Right.
So save that.
Let's go back into Unity Press play and have a look.
And now this character will actually be walking in meters per second.
No matter which computer you put it on, it's going to run at the same rate because it's using the actual
time.
And from this, you can now clearly see that these other update loops aren't sort of synchronized with
the real time.
It's just the speed of your computer.
Whereas this other guy who's now getting out of frame is going at a consistent meters per second rate.
Okay.
So that's a demonstration of the different times that are kind of at work in an application.
And what we're striving for is to be more like this guy here in seconds where he's more accurate to
the clock.
Luckily for us, unity provides some great tools and we've actually already looked at them in previous
lectures and you might, you know, wrack your brain and see if you can remember what it was to get
these guys to move consistently inside of those loops.
When we come back in the next video, we will actually implement that and then compare the movement
of all of these characters.