This course is the third course in the specialization about learning how to develop video games using the C# programming language and the Unity game engine on Windows or Mac. Why use C# and Unity instead of some other language and game engine? Well, C# is a really good language for learning how to program and then programming professionally. Also, the Unity game engine is very popular with indie game developers; Unity games were downloaded 16,000,000,000 times in 2016! Finally, C# is one of the programming languages you can use in the Unity environment. This course assumes you have the prerequisite knowledge from the previous two courses in the specialization. You should make sure you have that knowledge, either by taking those previous courses or from personal experience, before tackling this course. The required prerequisite knowledge is listed in the "Who this class is for" section below. Throughout this course you'll build on your foundational C# and Unity knowledge by developing more robust games with better object-oriented designs using file input and output, inheritance and polymorphism, and event handling. This course gives you even more tools to help you build great games with C# and Unity! Module 1: Start using files to implement your Unity games Module 2: Learn how inheritance and polymorphism help us write less code for our games Module 3: Implement event handling to make better object-oriented designs and add menus to your Unity games Module 4: Explore the complete implementation of a small Unity game Module 5: Complete final peer review
Full Gameplay
Loading...
來自 University of Colorado System 的課程
Intermediate Object-Oriented Programming for Unity Games
22 個評分
University of Colorado System
22 個評分
課程 3（共 5 門，Specialization C# Programming for Unity Game Development）
從本節課中
Feed the Teddies
與講師見面
Dr. Tim "Dr. T" ChamillardAssociate Professor
Computer Science
In this lecture, we'll see how we can implement
the very rudimentary artificial intelligence or A.I in our game.
Now we'll make the game harder by adding a little bit of
rudimentary artificial intelligence to the TeddyBearand the TeddyBearProjectile.
So, one of the great things about the components system in
Unity is that if I look at the TeddyBear prefab,
we can see that I've added a Homing Component to the TeddyBear.
And if we look at the TeddyBearProjectile,
we can see I've have added a Homing Component there as well.
So this component based system that Unity has is awesome because we
can add the same component to multiple GameObjects.
Prefabs in this case,
to apply that same behavior to both of them.
Let's actually go take a look at that Homing script.
The Homing Component script has a burger GameObject,
a RigidBody2D, an impulseForce,
a homingDelay, and a homingTimer.
So when the GameObject that the script is attached to gets added to the scene,
we do a number of things.
First, we find the burger and save it.
And we do that because we're going to keep chasing the burger,
and we don't want to have to look up the burger GameObject every time.
The next thing we do,
is we call a GethomingDelay method in ConfigurationUtils to actually get the homingDelay.
We pass in our tag because the homingDelay for
TeddyBear is different from the homingDelay for TeddyBearProjectiles.
And this get a homingDelay method knows how to deal with both of those things.
Finally, we get the RigidBody2D because we're
going to manipulate that as we run our game.
We also create and start our homingTimer.
So we add the component.
Set the homingDelay, add a listener for when the timer is finished,
and start running the timer.
We will see who calls the SetImpulseForce method soon.
But the purpose of this method is to make sure that when a TeddyBear or
TeddyBearProjectile decides to change direction to chase after the burger,
that it stays moving at the same speed it was originally moving at.
We don't want the TeddyBearProjectile say,
to speed up each time it changes
direction because we're adding more force to the RigidBody.
We want to keep it at the same speed.
And so, if we keep track of what
the initial impulseForce was for that particular GameObject,
we can keep it at the same speed even when we change direction.
When the homingTimer finishes,
it's time to actually go toward the burger again.
Our first step is to stop moving and we do
that by setting the RigidBody's velocity to zero.
It's fairly unusual to actually manipulate the velocity of a RigidBody directly.
Usually, we just let the physics system handle everything but in this particular case,
it makes perfect sense because we want to keep the GameObject the script is attached to,
moving at the same speed.
Now, we calculate a vector to that point from here to the burger.
And then we normalize it to make it a unit vector and then we add force to
the RigidBody using the direction we just calculated and the impulseForce that we saved.
So this is the impulseForce that was originally used to get this GameObject moving.
So, because it stopped.
applying that magnitude of impulseForce will get it
moving again at the same speed it was moving up before and then,
we start the homingTimer again so that when it goes off,
we can move toward the burger again.
I promised we'd see who calls SetImpulseForce.
So, if I right click and find references,
we can see the TeddyBear calls it right here,
just after it has calculated the force here to get its RigidBody moving.
It gets the Homing Component that's attached to the same GameObject and sends that
force.magnitude in to the SetImpulseForce method so that it can get saved.
The TeddyBearProjectile does a very similar thing.
Although this time it doesn't actually have to save
it because the TeddyBearProjectile ImpulseForce
is a configuration data item so we can just get it from ConfigurationUtils.
It's not random.
TeddyBearprojectiles always move at the same speed even though TeddyBear actually move at
some random speed that's determined by the MinImpulseForce
and MaxImpulseForce that we generate for the magnitude of that ImpulseForce.
And that's how we add rudimentary A.I to our TeddyBears and our TeddyBearProjectiles.
To recap, in this lecture,
we saw how we can make TeddyBears and TeddyBearProjectiles smarter.
We were reminded of how cool the Unity component system is because we could attach
the same behavior to two distinct GameObjects and in this particular case,
using a Homing Component was a much better solution than using inheritance.
Inheritance is awesome and I use it all the time in my game development,
but in this particular case,
adding a component was the better choice.
