Am i golden hammering observer pattern?

Unity Courses Ask
,
#1

As soon as i looked at the code challenge i IMMEDIATLY wanted to swap it out for observer. so much so that i thought the challenge was a “set up” to explain an observer pattern use case. i wont rewrite the code but i would have done the following…

Enemy

  1. even if i was going to cache the character id do it in awake to avoid initialization or race conditions later, but id just scrap the cache in start in this case.

  2. swap attack to an event/Action( id probably prefer to use an event becuase i like having unity actions for an audio manager, but if itsa bigger game id use an event because i think they have better performance…not 100% sure on that).

Character

  1. either serialize the health field or move it to its own class depending on complexity of health system

  2. removed the animator, and audio variables and put them in some sort of audio script

  3. implement iKnockbackable, and iDamagable interfaces on character(or health script for iDamagable if we did need the health system to be more robust)

  4. Moved the methods to their relevant scripts

  5. subscribe the methods to the Attack event( via OnEnable/OnDisable)

#2

As golden hammers go, this is one I strongly approve of. Done properly, event driven programming is one of the most effective tools in your arsenal to decouple classes (the other being interfaces!).

Well done!

1 Like
#3

Oh yay! its almost like i’m actually learning! thanks Brian!

#4

I feel the same :joy:

Recently I learned that the correct way to handle Menus is to have them on a different scene all together, and have them work by tuning in in to events.
It’s supposed to make it so that different teams can work on different scenes in a decoupled way.

#5

i work by myself in unity. though i don’t think that will be the case forever. Soon ill probably start to need to merge projects and so on, but right now as I’m solo i really like having things in very small projects. i do this for speed, clarity, runtime efficiency, modularity, and decoupling. i have a projects for environment building, testing my stat loadouts and combat system, a project for inventory and UI testing, a project for fine tuning my character controller( that also became my animation controller tester), and a few others i use when i want to test a new solutions. it really forces me to never accidentally walk into a dependency i don’t want. the only downside ( if it counts as one) is that I always have to ask myself " does a solution to this issue lie in code in another project and if so is this a merge point for the two systems? that was how i ended up with the player controller project and animation stuff together. i like that it FORCES me to DECIDE to couple.

It works for my needs. i likely will be performing “the great merge” sometime between mid july, and mid September when i will put them all in the same project and start using a more professional source control model and just branching. for now though i kind of like it.

1 Like
#6

One of my future tutorials will be on preparing a module of code/assets for use in other projects.
It will include:

  • Ensuring the module has no dependencies in the current project (one way, much like the packages from the Package Manager
  • Any dependency you must have becomes another module. For example, you might have a Common Library with interfaces and functions you use everywhere. but it must be self-contained.
  • Assembly definitions, the module will sit in it’s own assembly, not in Assembly-CSharp
2 Likes
#7
#8

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms