Good taste design question about nested FSMs
Fri Dec 17 06:45:05 CET 2004
I'd be very grateful if erlangers of good taste would give me an advice
about how to make a nested FSMs in an OTP compatible manner. I'm in a
process of trying to improve my skills concerning OTP and my judgement for
good erlang code.
Little background: I met couple of friends that I hadn't seen long time and
was surprised that they still used to play MUD (www.icesus.org). Not that
I'm that interested in playing but the game itself ;) Or that at least for
As these fellows described the workings of MUD a thought started to creep
along my spine and I realised how well such a multiplayer game would suit
erlang. Of course I was naive to think that I've done a revelation --- just
yesterday I noticed that Mickaël Rémond and Thierry Mallard had alredy
shown a whole lot more sophisticated ideas about such multiuser games in
http://www.erlang.se/euc/03/proceedings/0950Mikael.pdf. Haven't read it
But the MUD still is a very interesting proving ground for me to improve my
skills. So far I've managed to make a "portmapper" along the Joe's
tcp_server, but implemented in gen_server -behaviour and included in
supervision tree. The portmapper asks player supervisor to start an
"acceptor" child that listens to a tcp port the mapper has opened for
listening and keeps track of number of active childs. Pretty straight
I implemented initially the child as a gen_fsm, but I don't think its that
elegant solution. Firstly one have to ask supervisor to create it and after
that send a message to start listening to the port (gen_tcp:accept) so that
the fsm-process doesn't hang on the init function and make supervisor
nervous. Other than that the fsm should communicate with the tcp port (with
handle_info) and with other player/room processes that is reacted in
"normal" state functions. More over the player could be in different states
(fighting, in a group and such) that should be handled in nested FSMs.
So --- finally --- the question is; apparently I should ditch the gen_fsm
and make my custom fsm that can be attached to the supervisor tree (by
using sys and proc_lib), so that I can make consistent receive loop, but
the inherent "nestedness" is still a mess. Should I make a process for each
substate machine (which would make communicating with other players
difficult as the "active" process is changing) or should I make nested
receive loops that handle the substate machines?
If my explanation of problem was a mess by itself, as for clarification.
Student. . . . . . . . . .University of Oulu, Dept. of El. & Inf. Eng.
"Life is what happens to you while you're busy making future plans."
- Alfred E. Neuman
More information about the erlang-questions