RPI-Engine VS UOX3

I would strongly strongly suggest investigating MUDs if that's your bag. They're non-graphical so they can be built and maintained by small numbers of people with low programming skills and they tend to be almost entirely about community experiences. I'll just leave http://www.middle-earth.us/ here because it's where I met my now SO and it's an absolutely wonderful community - but there are hundreds of them out there. They do take a serious time commitment though, since they're all about building up that interesting social world.

MUDs are a class of game that is terribly underrated. I've played on a few different one (mostly toward the RP focused end of things) but I think the whole family of games shows just how effective imagination can be when coupled solely with text descriptions.

I have extremely strong memories from Shadows of Isildur[1] and met my spouse there!

1. http://www.middle-earth.us/

A MUD I worked (uh volunteered, as a total newbie) on had a soft-reboot implementation for deploys that blew my mind when I first saw it in action. Open telnet connections were all sent keep alives before the MUD launched a new instance of itself from the executable (which may have been a different version from the currently running copy) and then killed itself. To users on the other end a message appeared saying "Relaunching the server" and was followed up shortly by "You may now resume play". Since this engine was designed to constantly fall over due to instabilities and OOMs it stored the current game state in a persistent state (originally on-disk files - most of it was migrated to MySQL) so the only things that really needed hacking were re-acquiring the right sockets and remembering which user is which.

This included, FYI, under development new game elements which were mostly written and launched using a mix of things called RPROGs, OPROGs, CPROGs and Descs (among other things) all of which were written in a custom domain language input into the MUD itself - devs like myself worked only on underlying mechanics and had no need to wander into the specifics of all those triggers.

This probably opened up a number of security holes but, given that the game only ever checked the first six characters of a password (and checked them one by one against a plaintext copy) there were lower fruit available to criticize.

If you want to check it out an older copy is available open-sourced[1] - it's a DIKU variant MUD.

1. https://github.com/webbj74/RPI-Engine

> As someone who got involved in an open-source version of the Ultima Online server, this is a fun read

Ultima Online emulators were what took small interest for me and blew it up into a career. But for me, it was pre-RunUO: SphereServer (aka GrayServer, I think) and UOX3. C++, with its own scripting engine built in. It wasn't exactly closed or open source. It also got me into Linux: while some emulation servers were run on home PCs, others were run on hosted machines. Debugging often meant the server administrators would give you root access to debug their running server. New Ultima Online releases meant being late for school to try and debug the client code changes to be able to quickly update the server, otherwise no one could log in.

It was incredibly buggy and never, to my knowledge, reached feature parity with the full game. The workarounds individual servers made through the rudimentary scripting language was impressive (many of these hacks were then copied into the core emulation scripts).

For trips down memory lane, these sites are still live -- and being updated? Wow.

https://www.sphereserver.com/

https://www.uox3.org/

If you're interested in trying out an Ultima Online emulator with soul, or if you're looking for a project where you can still make your mark as a contributor of code or scripts, check out the Ultima Offline eXperiment 3 at www.uox3.org, visit our GitHub pages or come hang out with us on Discord!