Why is Game Logic so Decentralized

Question

So I've dipped my toe in and out of game programming pretty regularly over the past few years and all of the tutorials I've watched and books I've read have all had one thing in common that perplexed me.

Most of the logic in the games I've seen built is completely decentralized and distributed among the various components of the game. There isn't one (or several) central controller(s) that guide how everything interacts with everything else, or that objects and methods in the game defer to to enforce the rules/design.

If an object in a game (a player object for example) impacts a broader game system by say, resetting the level when it reaches 0 health, it doesn't call to some "LevelController" or "LevelController -> GameController" which then resets the level, it just does it itself by directly accessing a built-in game engine directive/method call.

Almost all the actions and interactions from initialization and set up, to combat, collisions, etc. are all resolved in a sort of case-by-case individual bases with all the rules contained solely within various game objects and the only "oversight" being the inherent limits of the game engine itself.

As someone who comes from a pretty traditional top-down Object Oriented development background this whole methodology feels scattershot and piecemeal. It has made it difficult for me to design any kind of holistic architecture for my game projects.

Is it just the case that most intro level projects are like this because they focus on the basic components of a game and how they work and less on more complex, higher level design? Or is it the nature of game design/development in general, perhaps a necessity due to the unique nature of the complexity of games?

Answer 1

Most basic tutorials try to keep things simple. They want to demonstrate an API, not take an hour to create an over-engineered software architecture and then proceed to explain the things the audience actually came to learn. So they instead try to demonstrate the most simple way to do a simple thing. An experienced software engineer will then decide on their own how to best build an architecture to encapsulate all these building blocks of a more complex game.

But nevertheless, there is one core difference between developing a business application and developing a game. Game development is a far more creative process.

When you create a business application, then your product owner expects you to create an application which fulfills a very specific purpose. You usually have a precise and detailed list of requirements. That allows you to plan well. A software architect can design their software architecture down to the class level and then hand their UML diagrams to a herd of code monkeys to program it. You then hand the resulting program and your requirements to your testers, and when they made a check-mark behind every requirement, you ship your software.

But with game development, your only requirement is "fun" (and maybe to get the player to spend money on microtransactions, if you are in that part of the industry). You usually do have some idea what you want your game to be. But the finished game might still turns out to be substantially different than your original game design concept. You intended to develop an RTS, went a bit over board with your unit progression systems and storytelling, decided to ditch base building and ended up with what feels more like an RPG? So what? As long as it is fun to play, you have a product which will sell.

That means game design is usually a far more iterative process. You want to try out all kinds of ideas for game mechanics, testplay them, see what sticks and discard the rest. In order to allow a short design->develop->test->redesign cycle, you need to be able to make quick changes to your game. The more you over-engineer your architecture, the harder it can be to do experiments you didn't anticipate.

Sure, if you neglect architecture completely, you might soon find yourself in an unmaintainable and undebugable mess of code. Many game development projects fall into that trap. This is why game developers came up with some software architecture patterns of their own which bring some structure in a codebase but still allow fast iterations.

One very common architectural pattern in game development is the Entity - Component - System pattern. It does a great job at loosely coupling different game systems and makes it very easy to mix and match them. Yes, it means that your game mechanics are distributed over multiple separate systems, but that separation allows you to add, develop and remove each game mechanic independently from the others.

I am looking forward to playing your games.