Section 1: Lecture 7: Using Action Events Instead of FindGameObjectWithTag?

Unity Courses Ask
,
#1

Would having the HealthUI and GunUI subscribing to a Player ActionEvent be more along the Law of Demeter design guidelines as it would create a loose coupling between the Player gameObject and the UI objects?

Like how it would function in my mind is the Player would have call the ActionEvent after it calls take damage or fire gun which would call the RedrawUI methods on the GunUI and HealthUI. There’s probably a way to make the ActionEvent more generic as well but I am still learning and this is just off the top of my head, but is this inline with what we are aiming to get at with the Law of Demeter?

#2

I would say you’ve got the general idea, but I’ll nitpick the specifics…
The Single Responsibility Principle says that one class is responsible for one thing… so in this case, the Player shoudn’t be responsible for either the state of the Health or the Gun. You would have a Health component that tracks health, and a Gun class that tracks the current ammo. Therefore, I would have the HealthUI subscribing to a HealthChanged event in Health, and the GunUI subscribing to an OnFired event in the Gun. This is in keeping with a component only knowing what it needs for the job. Were you to have an event in the player that covered both of these things, you would have unneccesary calls to HealthUI or GunUI

1 Like
#3

Okay thanks for the clarification, but what is the purpose of the Player Class in the example? Reading player inputs or a placeholder tag like how combat target was for a bit in the RPG course? Cause from the example I think we probably wouldn’t need a Player Class like the one defined in the example just probably a GameObject after we refactor the Health into it’s own class and implement ActionEvents.

I guess this might also be an example of badly defined names, not that this is a criticism of the course or instructor’s method of teaching if anything I would assume this is a common feature of developing a game. Constantly refining and defining concepts in a manner that is understandable, basically a long way of saying words are hard.

Anyway, thanks again I will be updating my notes to incorporate The Single Responsibility Principle.

#4

Sam wasn’t really muddying things up with a big example here. I’ll give you an example from the RPG: Core Combat course. We have several classes on the player, each with their own purposes… because they are individual components, we’re able to re-use most of those components on the enemies as well.
For example: These are just a few of the components on both the Player and the Enemies:

  • ActionScheduler → Coordinates which component has control
  • Mover → Responsible for moving the character from point to point, can be an action or used by Fighter or other components.
  • Fighter → Responsible for directing the character to the target through mover and attacking.
  • Health → Health
  • BaseStats → Repository of stats like initial health value, attack and defense by level.

Then we have a PlayerController and an AIController, depending on the needs. The controllers select targets/movements, using the Fighter and Mover components as needed.

1 Like
#5

So the Player Class would potentially be refactored into something like the PlayerController Class.

So putting it all together the new classes would work like this:

  • Health → responsible for health
    – HealthUI → subs to Health component Action Event
  • Gun → responsible for gun related actions reloading, firing, and ammo
    – GunUI → subs to Gun component Action Event
  • Player → holds reference to Health and Gun components and handles player interaction with them.

The reason I brought up naming is because that specific Player Class is probably the most common poorly named Class in a beginner project, so I think it’s a very great example given by the instructor. I am almost certain that I have a couple early projects that just have a Player Class and GameController Class where searching for any specific functionality is rough or requires collapsing multiple methods and reading lines of comment text to navigate. (Might go back and try to clean up those projects after I finish this course as practice.)

These classes essentially only functioned as containers to hold functionality that should of been broken up into individual classes but at the time I was more concerned with knocking off the programming dust and making something that worked. Now I’m really trying to knock the dust off of the more refined parts of coding with things like single responsibility and basically everything covered in this course.

So far it’s been really informative and refreshing topics and concepts I vaguely remember from school, I just need more clarification on the best Unity approaches as well and lucky for me GameDev has a great community for support.

Thanks again for the detailed example.

#6

Amen, but for the purposes of demonstrating a different pattern, it suffices and everybody is immediately familiar with it. Ordinarily, I don’t see Sam naming a class Player.

Yep, as Rick would say “First you make it work, then you make it pretty”.

I strongly recommend this for all students. Take the early 2d and 3d course projects… They were designed to teach the language, not design patterns (and if we’d have started with design patterns in those early courses, we’d have lost 90% of the students who had never programmed before in their lives) in the first two sections of each course). These early projects are ripe for significant refactoring, and it’s very good practice to clean those projects up. Refactoring is a skill that will take you far in the coding industry.

1 Like
#7
#8

Privacy & Terms