Thanks for saying so. I used to be a teacher some 10 years back, glad to hear I have some of that ability still

Yeah, these first few days/weeks will be pretty rapid and active development

Thanks for the compliments on my teaching! Hope the insights will be helpful to you!

Glad you found it useful. I WAY simplified the command pattern, but still, it's cleaner and clearer this way to make a better example and comparison

The scalability of the observer pattern is key for the bigger projects. My game jams start to gridlock if I don't code smart and use it often

That's great to hear, honestly I think I get more joy from the positive comments on this educational video than I do my other template feature videos. I know the folks that comment here have learned something valuable that they can use in the future

Haha thanks, gotta train folks up on the common coding patterns before I explain the template in full :) laying the ground work

Typos, I'm also a spanish speaker which messes with my spelling sometimes. "suction" = "succión"

@@catprisbrey ah my apologies I don't mean to laugh at your typos, I read it as "succion" as in "the succ" lol

@@catprisbrey appreciate the insight here and also your anim library videos have been very helpful. hope you didn't take offense!

Yes, and I said in the description text of the video I'm WAY over simplifying it for the sake of the analogy. But still, at it's very very most basic, one script calling outside node functions in a sequence is still command pattern, well just as you said func move() being "node.tranalate" ,"animation.play()"

Perhaps once I finish all the videos on the template. You can also go to that website I linked and read the book for free. It'd short, and concise (but a bit dense)

Nope, no need for a signally bus Singleton. The idea is, if the node is there, it'll connect to it, otherwise it won't. And then you build the features independent of each other. So for example, the targeting system I wrote. If the player sees it's there and available, it'll connect to it and vice versa,and will add that targeting feature to the game. But if I delete the targeting system, then the game continues exactly as it did before except no targeting. Or thinking something simpler. Like a sound effect or particle node waiting for an attack_started signal. If the connectionn is available, then particles/sounds will emit when the signal triggers... Other wise they simply won't emit/play. But the attack will still happen. Independent nodes and functions, that happen to take action based on the same signal. Rather then a bunch of nodes all needing to be directly called, creating breaking dependencies

Like, coupling stuff is fine. Nodes talking to nodes is necessary for the game. But there is monolithic master/commander scripts calling the names of different nodes and telling them specifically what to do (tight coupling). So basically one node talking to 10 specific nodes for example. 10 tight dependencies, I'd any break the whole thing crashes. Versus the master script just says "hey, signalling that 'x' happened... I don't care who cares". So zero dependencies in the master script. Then each of the other nodes connects only to that master, so each feature node has only one, loose dependency. If any fail, the main script won't fail, only the feature node breakers. So 1 LONG script with 10 dependencies, each crash you must review the whole thing. Verses, 10 short scripts, 1 dependency each. If anything crashes, its quite obvious which script/node had the issue

Haha, the balance between practicing code or improving art and asset workflow. And yeah the observer pattern and signals are amazing. They're not a magic bullet or the go-to-solution for every problem, but they have a role they play very very well.