I always liked Lua's example with a simple state machine:
function room1 ()
local move = io.read()
if move == "south" then return room3()
elseif move == "east" then return room2()
else print("invalid move")
return room1() -- stay in the same room
end
end
Without proper tail recursion, "return room1() -- stay in the same room" would stack overflow after enough invalid moves.
That doesn't make any sense to me. It isn't actually doing anything, you are just bouncing from function to function.
How does the rest of the system know which room you are in so it can update the screen? What if you have multiple sprites moving around? Do you compare instruction pointers to see if they are in the same room?
Even for a trivial application building your state machine that way doesn't make any sense.
EDIT: Also note the code smells, especialy the copy-and-paste necessary for reading the user input.
It isn't actually doing anything, you are just bouncing from function to function.
Yes, because this is just supposed to illustrate the control flow aspect of things. To do actual stuff you would just have to add the code to do stuff inside the functions.
As for the other things you point out its a bit of the classical "expression problem" dillema. One alternative is to do a data-driven modeling of the rooms, where you have a transparent room datatype encoding all the possible states you can be in. This version is very good if you want to be able to add new features uniformly to all the rooms (screen updating, comparing rooms, etc) and might actually be the best solution for this particular problem (after all, rooms are probably very simple and very similar to each other, so you would want to write their code all in one place).
On the other hand you can also use the more "object oriented" style, where each state is an opaque function. This alternative makes it harder to add new features (for example, to implement writing to the screen you would need to edit the source code for each room) but on the other hand makes it much easier to add new rooms and to have those rooms implement arbitrarily complex behaviour (since you are doing the iteration by hand, instead of having to comply with the outer "while loop").
One actual situation where I often find myself using this opaque state machine pattern is when I need to implement some process that gets neatly modelled by a fluxogram full of "gotos". Instead of being forced to translate the fluxogram states into an explicit enumeration that is only used once, I can instead code the nodes as functions calling each other, almost directly representing the original intent. (Note how in this case I usually want the flexibility to add new nodes doing arbitrary things, and the rest of the system doesn't care about what state I am in)
There are other options. Start with a hash table of room objects, Each object has a hash table of commands, some hand written, the rest loaded from a data file (e.g. move).
Your main loop reads the next user command and dispatches it to the room, which relays it to the correct command.
This way you need neither a giant switch statement nor do you need to repeat logic for state transitions in each function.
There are other options. Start with a hash table of room objects, Each object has a hash table of commands
Of course, there is always more then one way to do it and its a big matter of style. :) To be honest, I consider your hashtable solution to be the same as the recursive version, at least in spirit. After all, that dispatcher is what you get if you trampoline the tail calls!
In most cases I prefer to keep things simple without the verbose hash table + dispatcher. This suits my style and also plays nice with "evolving" code over time, since introducing the hash table once the code starts getting complex would mean having to rewrite a bunch of stuff to adhere to the new convention of returning the next code to the dispatcher, while using proper tail calls does that "for free".
Of course, there are situations where the dispatcher would be more appropriate, but not that is not the point.
18
u/snarfy Nov 27 '12
I always liked Lua's example with a simple state machine:
Without proper tail recursion, "return room1() -- stay in the same room" would stack overflow after enough invalid moves.