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
Adding an Event Manager
Loading...
Do curso por University of Colorado System
Intermediate Object-Oriented Programming for Unity Games
17 ratings
University of Colorado System
17 ratings
Curso 3 de 5 em Specialization C# Programming for Unity Game Development
Na lição
Event Handling and Menus
Conheça os instrutores
Dr. Tim "Dr. T" ChamillardAssociate Professor
Computer Science
In this lecture, we'll refactor our Fish Revenge game,
again, to get an even better object oriented design.
The big idea is that we'll implement an EventManager utility class that will
make it so that none of the game objects need to know about each other at all.
Let's go see how we can make that happen.
Okay, this is the game that we ended with in the previous lecture.
Remember, we started the previous lecture with the fish needing to
know about the HUD.
And we didn't like that because fish really shouldn't know about those kind of
game components.
So we changed our code so that we used event, and
the HUD now has to know about the fish, which is still not totally satisfying,
but better than the fish knowing about the HUD.
In this lecture, we're going remove the need for the HUD to know about the fish
by implementing what I'll call a utility class.
It's a class that provides helpful functionality to objects in the game.
So you can think of this like the configuration utils class that you're
using in the wacky breakout project.
This provides utility functionality without really
supporting actual game play.
The script I'm going to add is called EventManager because it's
going to manage events.
Just a reminder of the way this currently works.
The HUD in its Start method finds the fishScript that's
attached to the FishGameObject and
then adds its AddPoint method as a listener for the point added event.
And the fish, implements an add points added event listener method
that lets listeners like the HUD, add event listeners for the event.
Here's my template EventManager script provided by Unity, so
it's an event manager.
And it really isn't an instance of MonoBehavior,
this is not a child class of MonoBehavior, so I'll get rid of that.
I will make it a static class so that the HUD and
the fish will actually both end up calling methods on the EventManager.
But we don't want them to need an instance of the EventManager,
we can just make this a static class instead.
Let me get rid of start and update, because we don't get those anymore,
since we're not a child class of moto behavior.
I'm going to implement two fields in this EventManager class.
I'm going to implement a field hat holds the invoker of the event,
and I'm going to add a field that holds the listener for the event.
So both of these fields will be static so they're accessible within static methods.
One, I actually know is an instance of the fish class and
I'll call this the invoker.
And the field for the listener is remember,
a UnityAction<int> and I'll call that listener.
Now, I immediately get a compilation error because I need a using directive.
Now I'm going to add two static methods.
The first one is public static void and
it is called AddInvoker,
And this is going to be a Fish script.
So I'll add a comment here like so, and all I'll do is
I will say that invoker, = script.
What this does for us is it's going to let the fish register itself as an invoker
here with the EventManager, so the EventManager doesn't have to go look for
the Fish object and find the Fish script.
The HUD doesn't have to go looking for that object and find the Fish script.
The fish knows about its own script.
Once it's doing its Start method stuff,
it can add itself as an invoker in the EventManager.
Let's do that now.
So here at the end of the Start method in the fish,
add self as event invoker.
So we put EventManager.AddInvoker and
we can just provide ourselves as that event invoker,
and that is this instance of the Fish class.
So it's this object right here that is attached to the fish game object
as a component.
Now one of the nice things about using this EventManager is we don't have
to know which order these game objects get added to the game.
We're not going to have to care if the HUD gets added first.
And if the HUD gets added first, and it tries to add itself as a listener
on the fish, that fish isn't in the game yet, so we'll have a problem.
So we're going to make it that it doesn't matter whether the invoker is added first
or the listener is added first here in the EventManager.
So when we go to add an invoker here in the AddInvoker method,
we're going to check to see if a listener has already been added, and
if a listener has been added, we will add it as a listener on this invoker.
In other words, the listener got added first and
it's been sitting around waiting to get added to an invoker.
Now that we're adding the invoker, we can add that listener to it.
We want to make sure we're only doing that if listener isn't null.
That's how we can tell whether a listener has already been added.
So if the listener isn't null,
then we will say invoker.AddPointsAddedEventListenter.
And it's that listener that's been hanging around waiting to be added to some
invoker of the event.
The add listener method is similar.
I'll type it in and then we'll come back.
We're going to pass in our event handler as the listener.
So the first thing we do is we assign our listener field to that, and
then we check to see if the invoker isn't null.
So in other words, if the invoker has been hanging around, waiting for a listener and
if it's not null, then we'll call the method to add the listener for that event.
And this is really nice because the HUD doesn't have to know about the fish,
the fish doesn't have to know about the HUD.
It doesn't even matter in which order they are trying to participate in
the event-handling process, the EventManager is sort of the intermediary,
if you will, to handle all those details.
We've already had the fish, add itself as an invoker.
So here in the HUD, for the Start method, we want to add the listener and
we can get rid of this stuff.
All we have to say is EventManager.AddListener(AddPoints).
And I will compile so that I can show that everything compiles okay and
I'll run to show that everything still works properly.
So if I juggle a teddy bear, if I eat a teddy bear,
you can see that the score gets added properly.
So it 's still the case that the fish and
the HUD need to know about the EventManager so they can add themselves
as the invoker and listener, respectively but that's okay.
Having our game objects know about utilities is perfectly reasonable and
that's what we've implemented here.
To recap, in this lecture,
we saw how to implement an EventManager utility class so that none
of the game objects need to know about each other to implement our event system.
And this leads to a really solid object oriented design.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
