Skip to main content
15 events
when toggle format what by license comment
Dec 13, 2024 at 19:46 comment added KulaGGin Does this sound about right? The states do have access to the enclosing character and it's used as global container for the states. Does this sound right? Do you have any links to read to understand FSM better and the logic and data and context parts?
Dec 13, 2024 at 19:45 comment added KulaGGin @pdr so I have a Character(the main context) and the CharacterState. And let's say I want to hit the other character from the current character and I call OtherCharacter.GetHit(HitDirection), in this OtherCharacter object I set this.HitDirection = HitDirection; and then StateMachine.TakeTransition(GetHitTransition). I implemented the original GoF FSM with enum transitions and state IDs.
Feb 5, 2012 at 6:22 vote accept Kal_Torak
Feb 5, 2012 at 4:54 comment added Kal_Torak I'm going to mark this as accepted, as this discussion has helped clarify my understanding, and I should be able to build a decent solution now. Thanks!
Feb 5, 2012 at 4:52 vote accept Kal_Torak
Feb 5, 2012 at 6:22
Feb 5, 2012 at 2:29 comment added Kal_Torak @pdr, this is the client that I'm building here, I've already implemented a state pattern on a per-game basis server-side. I just drew a diagram to try to show how I've got it laid out, please excuse the slapdash attempt at UML. link
Feb 4, 2012 at 22:07 comment added pdr @Kal_Torak: Please provide more info for a more specific answer. If you have a main room, I assume this is a client-server game. If so, where is your Context.CurrentState singleton? Client or Server application? Should it be a singleton, or should it be per-game? (The game is where a state is more logical - the main room is just a list of games with open spaces, no?)
Feb 4, 2012 at 21:36 comment added Kal_Torak @pdr, thank you for the detailed example and explanation. I understand what you're saying. My implementation is a little different, I'm going to edit my question with more detail.
Feb 4, 2012 at 16:15 comment added user23157 it's an implementation detail :)
Feb 4, 2012 at 14:02 history edited pdr CC BY-SA 3.0
added 4 characters in body
Feb 4, 2012 at 13:12 comment added pdr @TheMouthofaCow: Honestly, that was a close call. I don't have a strong preference. On one hand, if it's held in the State objects and the application, there is a risk of over-ownership; on the other hand, this way does mean passing context to every method.
Feb 4, 2012 at 11:41 comment added user23157 +1 - I'd probably stick the context in the constructor, but yes you need the State object that controls the logic and the context that holds the data.
Feb 4, 2012 at 11:18 history edited pdr CC BY-SA 3.0
added 92 characters in body
Feb 4, 2012 at 11:09 history edited pdr CC BY-SA 3.0
added 51 characters in body
Feb 4, 2012 at 11:02 history answered pdr CC BY-SA 3.0