Good taste design question about nested FSMs

[Jani Launonen]

Hello everybody,

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 
now...

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 
fully yet.

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 
forward thing.

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.

Cheers,

-+-+-+-
Jani Launonen 
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