I don't understand for the need for subclasses of ComponentHolder (e.g. what additional behavior does GraphicsComponentHolder have over ComponentHolder?). Likewise, I don't understand the need for subclasses of View and Controller. Can't Controller just update all of the things inside the ComponentHolder?
The controller needs to know how its going to update the holder: bullet physics updates the holders in its own way, the graphics controller updates it in its own way; same with the Views. As for the subclassing of holders, I only do that for having less amounts of castings to the needed type. Instead of casting every component to the right type, I just cast the holder to the right type and access its elements. How would you do it? I don't really understand how its possible to have generic holder, view, and controller classes while still preserving flexibility of the state machine.
Backing away a bit: maybe you should even reconsider the notion of GameStates. What's the real difference between the "Play" state and the "Main Menu" state? Aren't the states simply implied by the currently active entities/components? Do you really need any custom functionality for the states?
For me there is not meaning behind States as there is no meaning behind Entities. They are both just containers with ID. The way I think about both of them is like a Storage Unit - by themselves, they are pointless; but once you put the things in it, they get valued The State Manager I want to implement is very different than most I have seen in the internet; the ones I have seen always inherit from a base State class to a PlayState or MainMenuState. For my state management, there is a generic State class; that is handled by any sort of state machine - whether its FSM, HFSM, or BT. Then, there is a special case "GameState" where its used for changing menus or whatever. This container itself consists of "components" = managers, controllers, views. The systems are identified by "name". The main difference between controllers/views and managers is that, each state has its own created manager, while each state stores only the reference to the particular controllers/views. The controllers "don't care" about the existence of a state, they run in separate threads and update/render whatever is given to them. I have had Managers, Controllers, and Views working altogether but I want to change that and separate the controllers/views.
In my current project, I do sort of have the concept of "states", and each state has it's own completely separate entity manager (and completely separate systems). This does have the advantage that I can easily just completely shutdown and destroy all the entities related to the main menu screen, for instance (this would be more difficult if I shared entity manager and systems across states). So that's something you might want to think about too. I don't have any custom subclasses for my states, because they don't have any custom functionality... they're just the sum of their parts (i.e. their functionality/logic is completely defined by the entities that exist in them). And I do have some code that sits above the states that manages transitions from one to another.
I've been wondering if I could refactor this a bit though, and eliminate my separate entity managers altogether.
I just realized that I want to build something similar to what you have The moment I have a working version of what I want to achieve, I am thinking of getting rid of the entity class all together because it has no specific function than be a "middle man" between the components, which I think components should do directly. For me it makes sense to have a State because of transitions in the State Machine. But for Entity, I would rather change it to a sorted double linked list of components (or maybe a set. i'll figure it out when its time); where one can find the other components by comparing IDs. One question, about Entity Managers? what are they? Are they basically a World or are they the creator of the entities? Or are they both?
I too have had my share of problems implementing a finite state machine.
I have found the very last answer in this thread (the post from Henrique Barcelos) to be a very good starting point.
It is easy to understand and the implementation is very generic.
My main problem is not the implementation of the state machine but the design of a flexible and generic GameState (MainMenu or Play) that can be created into anything.
If you do follow the example that I posted a link too, I think a good idea would be to put the system parts of the ECS in the machine and component parts in the states.
Something like this psuedo code..
I really like the idea of the world. Can you please give me an idea of what a world is? What can it do? What does it store? How is it compared to my ComponentHolder? Is it just a container of component holders?
I think this topic isn't about state management but more about "Designing a world object"