Baddies 2.1–Nodes and Tree Architecture

The game engine follows a tree based architecture, that is, all elements are nodes, and any node might be added as a child to someone else. Every node might have at most one parent. Specific cases and conditions can be dealt with from each individual node.
There are three main reasons I’ve opted for this architecture, to the point of redoing several months of work.

Low coupling

Ideally, in any computer science project there is low coupling and high cohesion. This means, in an OOP environment, that the best situation would be one where no class needs to know about any other to function. This is a goal worth pursuing, even though it is not always reasonable to stick to this guideline, as you need to sacrifice other factors (speed, mainly) to achieve it, and that is simply not an option in a game project.
But, low coupling is good, as I’ve found out in countless projects, and most games can be designed as to minimize coupling and be all the better for it. And a tree based architecture is awesome for this because since any node can be added to any other node, you can never assume a node will have a particular parent on whose internal workings it relies, therefore you must always write modular code.
This, of course, takes a toll on efficiency and forces us to use several communication mechanisms we shall see later.

Avoiding repetition

In almost all game projects I’ve done, I find the objects follow a hierarchical structure, and from each parent object I usually have to call the “Enter, Update, Draw, Exit” functions of all of its children, for which I have to create individual variables, and so on. There is a lot of duplicated effort for each object you add to a class.
A tree architecture solves all this by putting all items as nodes, so they can be stored and treated in a generic way. No more remembering to modify half the class when I add a new variable or remove it.
The down side is that accessing elements in a class from the outside is slower as a search of some sort, or even a direct access to the index of the element requires extra work, and therefore time.

Empirical experience

I worked with the Cocos libraries in a couple of projects and found it to be a delightful system, working fine in the limited environment that is a smartphone.

Conclusion

All in all, it’s a good system for games that don’t try to squeeze the processor dry, and like a clean easy to maintain system.