Welcome back.
Now we know that we need a few classes to get our UI system started, so I'm going to go into C plus
plus classes aura public, and we'll make a new C plus plus class here.
And I'm going to choose all classes and search for user widget.
I'd like to have my own base user widget C plus plus class and I'm going to use this class for my user
widgets in this project.
That way they're all compatible and share the same base functionality.
So I'm going to choose user widget.
Go to next and I'll place this in a folder called UI slash Widgets.
That way I can have all UI related stuff in UI and my aura user widget in widgets.
In fact, I'll just say widget to keep with the convention that I'm using throughout the course without
the s at the end we have a player folder, a character folder and so on.
We're going to have a widget folder and this will be called Aura User Widget.
This will be our specific user widget.
I'm going to create the class.
And I'm also going to create the widget controller class.
So I'm going to right click New Cplusplus class and my widget controller is just going to be a simple
object.
So we'll have a U object and I'm going to click next, put this in the UI folder slash widget controller
folder, and this will be called my Aura Widget Controller class so we can make widget controllers and
base them off of this class.
And this will be designed to be the controller for all widgets in our system.
So I'm going to click Create Class and close the editor.
And here in writer, I should be seeing the UI folder popping up in both public and private.
And there it is.
It took a second, but now I have UI and in UI we have widget inside of which we have aura user, widget
and widget controller which contains aura widget controller.
So now that we have these two classes, we can start making them compatible with one another.
Now my Aura user widget class, this will be our base class for widgets.
I want this class to have a member variable for its widget controller.
I would like our widgets to have the concept of a controller.
So any given widget is going to have its controller set.
And when the widget controller broadcasts data, our widgets will receive that data and respond to it.
So our dependencies will be one way from or a user widget to or a widget controller.
The widget controller isn't going to know what widgets it's associated with, but the widgets themselves
will know what their controller is.
So we're going to make a public section, and here in the public section I'm going to have a T object
pointer.
And the type for this will simply be you object.
So it's going to be very generic.
The way we're setting this up, the widget controller could literally be any object that makes it a
little bit more versatile.
And we're going to call this pointer simply widget controller.
Now, widget controller is going to need to be accessed from blueprints as all of our user widget classes
are going to be widget blueprints that use this C plus plus class as their base and widget controller
should be a new property with access in blueprints.
We're going to make it blueprint read only so that we can only access but not set it directly.
Now, most of what our user widgets are responsible for is the visuals for the widgets.
Basically, they're responsible for what the widgets look like on the screen when they receive data.
And whenever we set our widget controller for a given user widget, we're going to want to initialize
the visuals.
We're going to want to do something visually in response.
In other words, as soon as the widget controller is set, we now know that we can get whatever data
we want from that widget controller.
So we're going to want a sort of begin play like function that we can call as soon as the widget controller
is set.
So I'm going to make a protected function.
I'll make a protected section and make a void function called widget controller set.
And I want this to be a blueprint implementable event.
So I'll give it a new function macro with blueprint implementable event.
So this way, whenever we set the widget controller for a given widget, we'll also call this function
widget controller set.
And as soon as that happens, anything we want in the blueprint that we would like to do in response
to the widget controller set, we'll do that in the blueprint.
So that means we should associate setting the widget controller with calling widget controller set.
These should be tied closely together.
So what we'll do is we'll make a function to set the widget controller.
I'll put this right at the top of the public section and it's going to be a void function.
It'll be called set widget controller, and it's going to take an input of type you object and we'll
call this in widget controller like so.
And I'd like to be able to call this from blueprints.
So I'll make it a new function with blueprint callable so we can set the widget controller from Blueprint
if we want.
And I'll generate the definition and the definition will be simple.
All we want to do is set widget controller to in widget controller, but we also want to call widget
controller set.
Now this is a blueprint, implementable event.
So if we set the widget controller, we should do so with the setter and that way this will be kicked
off and we're safe to assume that when we implement widget controller set in any blueprint, we know
our widget controller will be set as it was just set.
Okay, perfect.
Now, or a widget controller is going to be responsible for getting any data from the system, from
the model in this architecture.
That means our ability system component, our attribute set, our character, anything that really matters
relating to our data.
The widget controller will be responsible for getting that data and broadcasting it over to any widgets
that have their controller set to it.
So what I'd like our widget controller to have is a set of variables from which it's going to get any
information, any data.
And for the purposes of this game project, I'm interested in four main classes.
I'm interested in the ability system component.
Obviously I'm interested in the attribute set and I'm also interested in the player state and the player
controller.
Throughout the game.
Our widget controller may need to have access to the four of those.
So that's how our dependencies will be set up for our widget controllers.
We're going to have those four variables.
So I'd like to make a protected section.
Since any child classes of or a widget controller are going to want to access these to get data from
them or to subscribe to delegates broadcast by them.
And those four objects are going to be the player controller.
So we'll make a T object pointer of type A player controller and we'll call this player controller and
this gets a new property and I'm going to give this a blueprint read only with a category of widget
controller.
So the widget controller is going to have a player controller variable.
It's also going to have a player state variable.
So I'm going to make a T object pointer of type A player state as we will have important information
on the player state that will need to know about in the HUD.
So we're going to call this one player state.
This one also gets a new property with the same specifiers and category.
Now, in addition to that, we need the ability system component and the attribute set.
So we'll make a T object pointer of type U ability system component.
And we'll add a forward declaration for that.
And this will be called ability system component.
And we'll also have a T object pointer of type attribute set.
We'll add a forward declaration for that and call it attribute set.
And just like the others, we need U property and we'll make this blueprint read only.
Category Widget Controller.
And now the widget controller has four main variables and these are the variables that it's going to
get the data from in order to broadcast to our widgets.
So now that we have these, we need to set them up.
Right.
We've just created classes.
We've never actually created any instances of these classes.
And in our game we're going to want a widget controller to control certain widgets.
For example, we may want an overlay that shows health bars and things like that, but we may also want
other widgets like menus attribute menus, spell menus, things like that.
And each of these is going to need a widget controller that can broadcast data to it.
So we'll set that system up next.
For now.
This is looking good.
We should compile our code, make sure we don't have any typos, make sure everything compiles and we
see that it does.
Perfect.
So we'll continue with this in the next video.
I'll see you soon.