How Godot signals can make your code more modular. #godot #softwarearchitecture

Loosely-coupled code is flexible code

If you’re confused, the main difference between a normal function invocation and emitting a signal is that, when invoking, the subject needs to know specifics about the class it’s calling into — the function name, at least. This couples it to that specific implementation. With a signal, the subject object ONLY knows that “something is listening, and they’re going to do something when I trigger this”. It’s completely agnostic to what the observer object is, or what it’s going to do. This simple difference cascades into a ton of interesting architecture improvements if we follow it to its conclusion.

Let’s try to understand a problem that comes up as games get large and complicated.

Throughout development of ANY software project, but probably especially games projects, we are going to want to make changes to already written code. Maybe we need to add or remove a feature, or fix a major bug, or even redesign whole systems. Maybe this is a result of user tests, design shifts or something just not feeling right. This is the nature of games: it’s hard to understand if a game “works” or “is fun” until it has been played, and we can’t really play a game until it’s coded. But because we’ve already coded it, we’re going to end up throwing out or repurposing a LOT of that code. It just isn’t realistic to go into a game project with a completely defined design spec and expect it to work in practice with no changes and iterations.

At any level of code — a button in the UI, a class script or a whole feature — we want to be able to pull out something existing OR slot in something new without having to rearchitect **everything**. Ideally, there would only be a few small local connections you need to plug or unplug to make things happen. Connections.

For that reason, we want to write code in a way such that each “area” need to know as little as possible about any other “area”, and thus changes in one area require minimal rewrites in other code. This also makes code more reusable and testable. We call code like this “loosely coupled.” And using signals is one of our best and easiest ways to work towards this.

Maybe this sounds needlessly complex; it certainly did when I first came across the observer pattern when studying Computer Science at University. But in our first year or two of undergrad, we don’t work on big projects. We are mostly only exposed to small toy projects, exam questions etc. It wasn’t until I started working on larger projects — both my own over-engineered games, paid game contract work and professional non-game codebases — that I understood the motivation for the observer pattern and many other design patterns. If you’re thinking: “I won’t need this…” well… I think you’re wrong. Unless you’re only making tiny tiny micro games, you’ll need it. Someday. Anyways, this is a tool I want to give you, and you’ll know its there when you need to reach for it.

Видео How Godot signals can make your code more modular. #godot #softwarearchitecture канала hoveringskull