Oh, it’s you, hi! I want to invite you to read the first post in a new series about Centralized Control. This one is an overview of the subject. You’ll get familiar with the centralized architecture, how it looks like, and what are the biggest benefits of sticking to it. You’re probably using it already, but the chances are it has got a few holes. When it has the holes, the benefits leak through them like a blood. Are you sure that you’re okay with that?

‘Read it like a book’ series

Part I – Centralized Control (this)
Part II – What to do when Centralized Control does not work?
Part III – Painless way of programming Game Modes and Skills
Part IV – Soon

Content

What is the Centralized Control?
Project structure and communication between scripts
Some benefits of the Centralized Control

What is the Centralized Control?

Centralized control is a relation between classes, where one of them uses the others, the others use yet other ones, and that structure is never inverted. Centralized control doesn’t have to apply to the whole project, but it can be implemented only in a few modules. These particular modules’ architecture is centralized then. This code structurization is so natural for an object-oriented programming that almost everyone, even unconsciously, tends toward it. But somewhere on the programming trip that centralization starts to shatter. We give the very specialized classes like Fireball a surprising amount of information. The Fireball starts to demand a data about the world from the higher-level classes. It can even force these classes to do things by calling methods on them. Directly! Ugh. The flow of the game code breaks. You start to walk a dark path deeper and deeper into the underworld inhabited by miserably deformed and unfinished games.

Do you really want that for your little baby you sick bastard? No, of course you don’t want that, my friend. Let’s see how the structure of the centralized control looks like.

Project structure and communication between scripts

Pretty straightforward, right? Now look at the part of your game’s codebase and try to draw its scheme. If none of the arrows go back to the upper class, you’re cool. If there are some places when it happens, watch out. These are the places you should rethink as they might be a source of a major problem in the future. Huge cancer can grow on these arrows.

Broken centralized architecture can be compared to dealing with an official matter in the Department of Spaghetti. You start on the first floor, and you want to submit an application at the window 101. There you’re being informed that you need a certificate from the window 821 on the third floor to proceed. On the third floor, you hear that you need to go to the second one. On the second floor you are being directed to the fifth floor, then to the first one and suddenly you don’t know why are you here anymore and where it all ends. Guys from the Department of Centralization organized their work different way. You start on the floor one at window 101 (“Oh, that is scary”, you think). Then you’re being directed to the floor two, three, four, and five. When you’re on the fourth floor, you know you’re getting close to the end. When your case is finalized on the fifth floor, you notice an elevator with Ed Sheeran inside it. While you’re riding down, he plays his guitar and sings gently. An elevator is a place where you can take a deep breath and rethink a whole logical journey.

Communication between scripts in the centralized architecture is as simple as its structure. High-level classes call methods on the low-level classes and might expect a return value. The low-level classes do their work, and when something interesting happens, they call an event (You remember events, right? The Observer pattern?) High-level classes catch these events, and do the same things as they would do in regular methods. Coupling is one-sided.

Some benefits of the Centralized Control

• The flow of the code is easier to understand.
• P. J. Plauger says about The Principle of One Right Place, that “There should be one right place to look for any non-trivial piece of code, and One Right Place to make a likely maintenance change.” It means that you’ll find the code you’re looking for faster, and you’ll make a change easier.
• Controllers’ and Managers’ classes have greater control over subordinate classes. This bullet is somehow related to the previous one. The fewer places where the low-level class is used, the less risk is taken by a high-level class that manages it.
• Believe me or not, but the classes’ interfaces become simpler and clearer. That makes writing a code easier, not only reading it! Relax, I’ll explain it in the next post.

Speaking of the next post… In the next part of the series, we’ll look at a very different approach and how it may be useful. We’ll talk a bit about one of the most overused programming patterns in relation to the Centralized Control and code maintenance. You’ll get some tips about this architecture, its dangers and the solutions. Interested? And you’re aware, that you can subscribe &&/|| like a Facebook page, right? Great. So see you there!