Comment by Tommy Hodgins on "Modularization without dependency hell"

I don't think I have very much to contribute for the architecture part, but I know people who work in games and animations and things where the types of things you're describing (characters, weather, properties) need to be changed by modular code in a larger environment, and they can talk at length about Finite State Machines (FSM), rather than OOP-style for this sort of thing.

So I don't know if you know about FSMs, or if they would be of help here. I'm sorry I can't understand enough to recommend anything myself, but I hope you can find a model that works for you :D

(I think it would mean you are storing the state of everything in the environment as data somewhere and all your modular code acts on that data, modifying the state - rather than speaking to other code)

An FSM would be an alternative solution, and I think it's quite a valid option for anyone interested in modularization :)

Basically, what I am using is something called "Entity Component System", which already stores all data in a central place (the "world"). What I want to put in the modules is the definition of what is stored in the world and the logic which operates on it.

An Entity Component System is made up of entities (think of them as indices... just numbers, if you like), to which components are bound. Components hold the data and are used to do define what an entity really is made up of. For example you could create an entity and add the components "creature" and "player" and "movable" and "position" to it. The third part of an ECS are systems. They contain the logic. Usually, you iterate over the entities and match them based on their components, then do something clever. For example, you search for all entities with "position" and "moveable" and "player" in your "input_system", then check the keyboard state and change the position accordingly. Does that make sense?

Search Hashnode