| Your basic description sounds like LambdaMOO (written in 1990, the name is a coincidence). The LambdaMOO server has a main event loop which handles user events, then schedules tasks which execute functions ('verbs' in LambdaMOO parlance) to modify the game state. Verbs are not pure per se but can be thought of as a transaction which executes in an atomic, consistent, and isolated manner. Verbs are attached to objects in the game, and can be modified in-game on the fly by players with their programmer bit set. (Programmers can only modify verbs on objects they own.) The LambdaMOO language is a lot like JavaScript with a Luaesque syntax. It has prototypical inheritance, which meshes well with its concept of objects as physical things. For example, to get a new instance of a duck one would create a Generic Duck named "My Duck" ('Generic' being the conventional prefix for an object specifically intended to be used as a prototype.) There was a time in the late 1990s when it regularly supported 300 active users at once (with a certan amount of lag); on modern hardware it could probably handle significantly more than that.
If you want a modern scalable system then LambdaMOO itself is probably not for you; the server is single-threaded (in fact the whole thing is remarkably similar to NodeJS with async/await support) and state is saved in-memory and checkpointed periodically (hence the Durability missing from the above description of verbs). However, the basic design (prototypal inheritance, in-database verbs, ACI[D] tasks, etc) is extremely well proven, and would lend itself well to being copied into a modern distributed system like AWS Lambda. As long as you had an ACID datastore to back it up, you could scale the task execution as far as you wanted, and with a bit of clever work you could probably come up with a partitioning scheme to make the database scale as well. In fact, I've partially implemented this already; what's stopped me has primarily been that I'm more interested in the technical aspects and have no idea what I would actually use it for once I built it. If you have a use case for this sort of thing I'd love to hear about it. |
I had a pseudo-roguelike server first implemented in Clojure, then in Go that updated 12 frames a second. It could support 250 simultaneous users. It even had Conway's life as an area attack. I had it posted to Show HN.
However, the basic design (prototypal inheritance, in-database verbs, ACI[D] tasks, etc) is extremely well proven, and would lend itself well to being copied into a modern distributed system like AWS Lambda.
All that's needed is pure functions, soft realtime, and good tooling and APIs. ACID takes some doing, in terms of implementation and will also make scaling complicated, as you mention above. Inheritance? Nice but not necessary. Just let developers inject functions into a game loop, then tell them their load and when their simulation tick rate starts to drop.
If you have a use case for this sort of thing I'd love to hear about it.
Yes. Something like that could be packaged into MMOGAAS -- Massively Multiplayer Online As A Service.