This gives me a large number of units of concurrency, while allowing the overwhelming majority of the code to be written sequentially since most of the complicated bits (combat etc) happen within a room so I don't have to think about concurrency at all for those. The only communication between processes is moving monster / character data from one room to another when those entities move around the map.
Consider this: bob is closing a door in rooma. A dragon is trying to move to rooma through that exit.
How do you code this such that bob never sees the dragon walk through a closed door? With no deadlocks?
The way I solved this is by creating a new process for coordinating multi-room actions. If a room is part of a coordinating process, it will queue everything from all other processes.
The commentary stops at getting telnet going, basically. The actual project does have some further progress. https://gitlab.com/zxq9/erlmud/-/tree/master/erlmud-0.1
Meanwhile the active muds are all running on systems decades old because player community, governance, lore, and writing quality is what keeps people playing them not server language features.
I'd love to see muds evolve that are scripting/ai friendly. If development is so fun, why not play around with having a wonder api and/or sdk for your mud, to let people control & grow a character or characters programmatically?
