Addition: WorldStateMachine? about anax HOT 9 CLOSED

What advantage does this have to "scenes" (using polymorphism, that is)? For example, my library called pine has polymorphic states implemented within it: https://github.com/miguelmartin75/pine#game-states (note: the library uses a lot of templates, but it could be implemented without).

I know you use SFML

I only use SFML for the examples and prototyping, because it's simple to use and easy to get something to work. I may/may not use it for my final product, depending on the context (e.g. if I want to have a custom renderer, or use a different library to render objects [such as 3D models, particles, etc.]).

The WorldStateMachine seems a bit 'fixed'. (e.g. wsm.changeState(TITLE_SCREEN) depends on TITLE_SCREEN; is this an enumeration? and why do I need to know the state type during run-time?).

Does the WorldStateMachine depend on anax? I don't think it's really necessary for it to be included with the library. Perhaps make a separate repository for it? You could put a link to it in the wiki if you like, discussing ways to handles states and suggesting your own method (and comparing it with others, such as the one I mentioned above).

from anax.

Yes, TITLE_SCREEN is part of a hypothetical GameState enum. And what do you mean knowing the state type at run-time?

from anax.

I don't necessarily understand why you need to know what specific state you're in. i.e. if you switch to TITLE_SCREEN, you probably store the enumeration that tells you that you're in the title screen. However, you can just use polymorphism to achieve the same result, however, you don't require to know what state you are currently in.

In other words, you're defining a state as an enumeration, but why not as a polymorphic object? Then you don't need to know what type of state you're in, it is much more flexible (but of course requires inheritance, which is in some-ways bad, but in this specific case it seems rather useful IMHO). Unless you could use this state machine for more than just title screens/menus/etc.?

from anax.

I maintain it as both in case the same state object might be reused, but with different parameters of some kind. Also, so state objects aren't copied around too much. Like I said, I haven't worked out all of the design details yet.

In my game, I actually provide two flavors of WorldStates; one is the usual abstract base class with onEnter(), onExit(), and update() methods. The other, CompositionWorldState, takes in three std::functions as parameters, and those are the functions that are called.

from anax.

I maintain it as both in case the same state object might be reused, but with different parameters of some kind. Also, so state objects aren't copied around too much. Like I said, I haven't worked out all of the design details yet.

I'm actually interested to know what this is exactly. I suggest putting up the code on github so I can see it (even if you haven't finished it, it doesn't matter).

from anax.

Sure, I just need to decouple it from my own code. I'll make a pull request some time soon. There's a couple of other unrelated things I noticed would benefit from changing, too.

from anax.

I'll make a pull request some time soon

I'm not sure if it would be best (for users that is) for a WorldStateMachine to be added to the entity system. Since one of the design goals is to be quite minimalistic (i.e. aim to do one thing only, and that is provide an entity system, which is the same reason I don't have my own event system and etc. built in). Perhaps a separate repository would be better suited IMO, unless your "unrelated" changed directly change the entity system itself (if so, then perhaps have a separate pull request for these changes and a independent repo for the WorldStateMachine).

from anax.

I haven't changed Anax itself, I just have some ideas. WorldStateMachine does depend closely on Anax, though.

from anax.

I don't think this is really necessary for the library. However, feel free to link to your project here.

from anax.