EntityStateMachine and EngineStateMachine has almost same code about ash

[guerrillacontra]

It is just that you're trying to abstract something that no one is going to need.

Over engineering I say! 💃

When people use Ash, if they want to extend the EntityStateMachine they will simply just do that, but no one is gonna re-use/implement an IState from the Ash framework as part of their domain logic.

Anyone who would use an IState kinda thing, would very likely roll out their own in a sub-layer underneath the Entity context, with a state machine that fits their needs better.

The contract of both EntityStateMachine and EngineStateMachine works very well for those specific concepts, but for me it does not do the job for other state based parts within the game.

[guerrillacontra]

That is true however just because they look similar no need to assume it needs to be refactored into a general form.

Looking closely it is clear that the changeState() is by far the bulk of each class, and thus refactoring is really pointless as it's not catering for what matters.

If anything they could potentially share an IAshStateMachine interface or something, but I don't think it will benefit...

[xpol]

@guerrillacontra Thank you!

And I just can't agree with you. EntityStateMachine and EngineStateMachine, in a high level of view, they does the same thing: StateMachine. The are different is just because they depends on different states. EntityState and EngineState have different interface.

I think we don't need to have IAshStateMachine but IState. (Find What Is Varying and Encapsulate It)

[xpol]

@guerrillacontra But true, indeed. The duplicated code in the two StateMachine is trivial.