The good and bad way to use events and signals in games (observer pattern)

[@adamgascoine]

I've been a game dev for about 20 years now - mostly a game designer and more recently a narrative designer. As an old school designer, my education was limited and mostly picked up on the job. I can prototype stuff and hand it off to engineers, and can usually muddle through any programming language enough to get something presentable (but not shippable) done. As such, I watch a LOT of tutorials to try and help improve my coding. I have no formal education and it's never been a priority in my work, but I want to get better. I can honestly say that having watched thousands of hours of tutorials, I have now watched all of your videos (still working on the 8 hour one) and have learned more about the concepts behind good code from you than any other teacher. Wonderful stuff! It looks like you haven't uploaded for a while, so perhaps this wasn't a passion for you, but I do hope you'll come back to it, or offer a pateron or paid course. The topics you chose and the manner in which you break down issues is a godsend for people like me. Thank you!

[@BareTuna]

Your channel is a hidden gold mine. I would instantly recommend anyone who's struggling with game code architecture to watch your videos such as this one; they've opened a new realm of possibilities to me. Seriously thank you! :)

[@kgknutsen]

Another amazingly unbiased, objective, ego-free lesson. Thank you once again for your wise advice, grounded in practical experienced rather than academic theories heralded from ivory towers.

[@embersworkshop]

I've been experiencing a lot of frustartion with my coding projects lately and I had no idea that focusing deep on decoupling everything was the reason for that! Gosh, thank you so much for this. You really are great at making encouraging videos that present realistic and tangible situations. I don't know how a 34 minute video like this still feels like it "cuts to the chase" because nearly every word sounds like it matters. Very refreshing, wish you could replace some of my Uni profs. This is probably my 2nd comment like this on your channel I'm just genuinely impressed and relieved to have videos like these to help me on my coding journey. Keep doing what you're doing!

[@stefanpopovic20]

Great video! Very fun and informative, it was very surprising for me to see such high quality content from such a small channel. I hope it gains more attention, you deserve it for sure! +1 for the lame nerd joke at the end, loved it

[@prostoxax]

Great video! I think the mushboom example is not the best, though, as you could simply subscribe the enemy only to its projectiles. For me, choosing between direct references and events comes down to asking, "Does this directly interact with this other thing or does this other thing only react to actions of the first thing". Also, things stupid by nature should remain stupid. I think, the projectile should be launched by the enemy, not launch itself. The enemy should keep count of projectiles and telekinetically control their speed and rotation UNTIL they get released/launched/allowed to control themselves. Once a projectile is released, it behaves on its own because it's controlled by physics or some other law. It could be done differently but in this case the enemy launches the projectile and observes it to create a new one because that's probably how it would work in the real world. The bullet does not tell the gun to reload

[@shaunstone9764]

Excellent resource for understanding when to use events. You're a natural teacher!

[@paprpl8513]

Fantastic, found this incredibly helpful to understand the observer pattern.

[@unfa00]

Somehow your tutorials let me learn more about why my code is bad (and how to make it better) than from any other videos I watched, even from big software development conferences. Your down-to-earth approach, simple yet relatable examples, and also demonstrating what goes wrong when we overuse given patterns are something very valuable that I am very grateful fro. Oh, and as a Godot user I also really appreciate that you also mention it and cover it's way of doing things. Thank you! I really hope we can see a new series of videos from you in the future!

[@fjodorf7341]

Awesome. Thank you so much. Really hope you’ll be picking up making videos again in the future, these are the best tutorials on game development I’ve seen so far.

[@rogpigamedev]

Thanksssssssssssssssssss, this was super useful. Now I can get how to add and manage global "key" items or upgrades, like the Hammer upgrades in Paper Mario, or events that change the map. I CAN FEEL THE POWER, MUAHAHAHAHA

[@TheFlow596]

your the best to ever do it

[@mukmusicdiary]

I just found your channel! Had to instantly subscribe, I hope you make more videos :D

[@somarandtheastronautape6518]

Man, your channel is pure and raw information. Thank you for your work. I'm the kind of person that simply can't keep programming without learning a new better way of doing things, and thanks to you my programming itch has been scratched. By the way, what is this program you use for your videos. It seems interesting.

[@rayboblio]

I can only agree with previous commenters, great video explaining stuff in very understandable and pleasant way. Currently working my way through the 7 hour Godot video :) Thank you!

[@curtheisler1200]

@10:30 - My project is literally this right now. @21:00 STOP READING MY MIND

[@cavitycat]

Another good video, surprised your channel isn't bigger

[@trampflips101]

Should the mushbooms be able to exist without the pizza? That's essentially the question you need to answer when deciding whether or not to make the mushroom pizza have a hard dependency on mushbooms.

[@ShadoFXPerino]

Just watched your singleton video as well and I think this is a good place to discuss "Call down, signal up" architecture for node communication kidscancode.org/godot_recipes/basics/node_communication/ Call down structure lets you recursively narrow down your search space when debugging Signal up lets you invoke back up the chain, when you need it, and is easy to add logging to Importantly, the signal should be defined at the common parent between source and target, so the "act of setting up the signal" itself is a "call down" If you directly signal laterally, totally ignoring the node structure, then you're going to get spaghetti signals Using this sort of consistent structure helps you avoid needing global state through singletons while also avoiding the tangled mess that unrestricted use of signals can cause

[@123TeeMee]

I like how insane this starts sounding part way through if you didn’t have any context

[@realMenta]

Amazing video. Your channel is awesome!! Thanks!!

[@karaiidesu]

Thank you very much! Your videos are so awesome

[@123TeeMee]

The point about the lack of tracing is important. Having no feedback between things messes things up generally. Having one way communication or a fire and forget system would mean you don’t get any errors, warnings or anything coming back

[@123TeeMee]

Adding communication creates interconnectivity, which is either a big win if the connections make themselves, or a big problem if something has to be done for each connection

[@123TeeMee]

I’d also say that having one way connections is bad as it’s not only about runtime communication but the compile time links for programmers to navigate by with ide tools. I think I’m rambling here

[@SuperQuwertz]

And thank you so much for doing this videos.

[@lkasikakalus123]

thank you so much, this really helpful

[@gnomemann6986]

Is this what you would use groups for in Godot? Just put every node that wants to subscribe to a specific signal into a particular group?

[@mpaul0416]

I really appreciate the look into code architecture for game development! I have a question about an application of an event system. If I were creating a game that had combat between many units (say, a real-time strategy game), would events be a good fit for that system? Would the event be "unit hit" emitted from the attacking unit and observed by a combat manager? The manager would then work with direct references that were passed with the "unit hit". It would create a direct dependency on Combat Manager and their units, but I couldn't think of a better way to handle this situation.

[@badunius_code]

13:50 well, I don't know. For example, JS has no custom events. So you will *have* to implement your own "game manager" thingy, or "event manager". There are ways to isolate pizza from this manager, for example, by passing onPizzaDestroyed as an optional callback to the constructor. The point is "we created a manager and we're good" --- yes, some times we are. Even thinking in GD sense, I'll _have to_ add a singleton to listen for pizza_destroyed signal and re-emmit it, so that all other systems could hear it.

[@shanewatson1235]

Discord? Patreon? I want to support the channel so we can get more content!

[@puzzud]

How are you avoiding Godot's problem with a cyclical dependency between pizzas and mushrooms? Unless I missed something, every pizza doesn't have to subscribe to the events of every mushroom.

[@mpaul0416]

If you strongly typed both your mushrooms and your pizzas, then it would create that terrible cyclical dependency. For that, I would leave the object I'm not expecting to have as many calls to untyped (in this case, probably leaving pizza untyped on the mushboom). For your second statement, I think he is referring to handling all the signals through an Event Hub, like his GameEvent from the 7 hour godot course. You are absolutely correct about the pizzas only subscribing to their mushbooms. The only problem that leaves is changing the speed of the mushbooms after one is destroyed. I can't think of a cleaner way to do that other than a direct reference.

[@SuperQuwertz]

0:32 Gotta stop here. Im hungry

[@kenonerboy]

Subbed

[@antonsimkin]

what is tight coupling in gdscript?

[@4after]

you could also decouple the pizza from the mushbooms by having an aggregate "MushboomPizza" object/node/whatever handle communication between the two

[@industrialdonut7681]

is that really decoupling them though?

[@trampflips101]

This doesn't decouple them. Decoupling is about dependence, and in the setup you've described, Pizza depends on MushboomPizza which depends on Mushboom, and if A depends on B which depends on C, then A depends on C (so Pizza still depends on Mushboom, you've just added an extra step). The point is that Pizza is supposed to depend on and be coupled to Mushboom as it essentially owns them (a Mushboom cannot exist without a Pizza).

[@SuperQuwertz]

Okay, but what if a mushboom has its own orbiting mushboomies who have orbiting mini mushroom pizzas who have

[@RyanScottForReal]

Surprise ending

[@thomasrodriguez3107]

I didn't finished the 7hour video !

[@IsraelRuizGodot]

I'm still in the process of watching it. Lol 😅

[@davidjohnhamm]

i like the part where he says mushboom

[@rudy_kolibri]

image someon making this pizza game