wscalf / rpmud Goto Github PK

Implement importing room/transition data from YAML file(s) so it's no longer hardcoded

A Points of Interest (POI) system could help make the rooms of the world feel more cohesive by including descriptions of distant objects in the current room, as well as the exit that goes 'toward' the object

Since rooms are not necessarily fixed to a grid, and exits are not necessarily directional, this will most likely be based on the shortest path from the current room to the POI. This should be computable in O(n) time with a breadth-first search from the room the POI is attached to. This may be baked into the module or may be computed at runtime (decision pending.)

Also some degree of LOD should be in play - descs should be more general at greater distances. And not all distances (or transitions) are equal. It could be good at make metadata about the path from the POI to the current room available, whether as references to the transitions/rooms along the way, or maybe something simplified like a set of tags

A lot of things are currently using raw pointers but should be upgraded to unique/shared_ptr instead

Many MU servers have a separate 'keepalive' feature to prevent connections being broken. This may be a TCP or telnet feature (currently unsure)

Likely follows a similar 'splash'/LOD behavior to POI system, may also need some per-room (or per-transition?) templating (ie: 'from outside, "blah"') to provide context

It's all pretty naive right now. It should check return codes and listen for connection error events

Process would involve a general threadpool and a script threadpool, and a basic job system
Each job has an associated threadpool it can run on
When a job completes, it can output more jobs to be scheduled
This allows event handling to follow roughly the pipeline-

• Decode (turn the event into a job to run the code)
• Execute (run the code)
• Output (run through a template to generate and send output

Though it doesn't necessarily have to follow exactly this pattern- input might decode into an incomplete chunk, and we need more data, so it gets buffered with no additional jobs generated. Or maybe there's an error, so it goes straight from Decode to Output with no need to Execute. An Output job might fork if there are multiple recipients with different client types so there's one job per client type creating and sending separate responses in parallel.

Script code however must run single-threaded, and the data being operated on by parallel jobs must be static, so the decode portion must be possible with minimal data that can be synchronized in some way, and data made available to output jobs must be copied during the execute phase. As long as modifications happen only in the execute phase, this can be done without locks.

Note: this approach requires significant rearchitecture and is intended to increase throughput for high-traffic MUDs on multicore systems. It's worth asking if this is a valid case at all versus leaving the whole system single-threaded. How many players does it take for that to start to introduce lag? And how many players can a game realistically draw?

This will require some design. Existing engines typically use a combination of ownership semantics and/or flags, quotas, and some form of RBAC. The details seem to vary a lot based on who creates rooms (ex: admins only, a dedicated builder class, or all players)

RPMud doesn't necessarily have to be opinionated about this, but C# scripting already is to some degree since code cannot be changed at runtime. Though any data theoretically could be, so creating rooms and editing descs and things is possible.

Likely requirements:

• RBAC and ability to tie a command (builtin or custom) to a required role
• Attribute to mark C# behavior methods/properties as safe for descriptions (to prevent descs from referencing things with side effects)