Am reading Horrocks' book. Did you ? > Le 19 mai 2015 à 06:17, Mike Thompson <[email protected]> a écrit : > >> On Tuesday, May 19, 2015 at 3:13:23 AM UTC+10, Daniel Kersten wrote: >> From my understanding of it: >> >> Use higher level states and decouple them somewhat from the data. >> >> For example, games do have lots of dynamically changing data. In a modern >> shooter you might have dozens of characters with positions, orientation, >> velocity, health information, weapons, ammunition, etc all of which can be >> constantly changing. And that's just taking the characters into account. >> >> I wouldn't go and build a state machine that enumerates all of the possible >> transitions from a "twelve characters with done distribution of attributes >> in this location moving in that direction" state. I'd break it down so that >> each character has a high level state like "seeking powerup" or "running". >> >> Probably not a great example although it does illustrate that you might have >> a hierarchy of state machines. In the game example, the highest level might >> be something like "in play" or "paused" and the lowest might be an each >> characters "firing weapon". >> >> In client side web app, you could say that each configuration of data is a >> state (the re-frame readme mentions that you could think of the app-db like >> this), but I think that's too fine grained to be useful. >> >> Instead I'd define higher level states (possibly in a hierarchy). I'd ask >> myself, regardless of the data available, what are the logical states that a >> user could be in and for each one, what are the actions that they can >> perform (and what state does each action transition them to). >> >> This could be as simple as pages and links, but with a rich single page >> application it's more likely finer grained than that. Maybe what dialogs or >> widgets are accessible. >> >> Again, you could then layer these into a hierarchy of state machines. >> >> One advantage of this is you always know what a user can do at any given >> time because you can look at what state they're in. >> >> I think of FSM states as orthogonal to the data, not as the data itself. The >> states dictate what data is accessible and what can be done to it; the data >> doesn't dictate what state the application is in. >> >> I suppose terminology gets confusing, but this is the approach I'm toying >> with. I'll see how that goes :) > > > As Kevin Lynagh said earlier in this thread, the best book around on this > subject is Horrocks': > http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782 > > Kevin also mentions a book I've not read yet: "Practical UML Statecharts in > C / C++". > > -- > Mike > > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to a topic in the Google > Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript.
-- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
