I admin/dev on an old LDMud, which means the "game" is written in LPC: https://en.wikipedia.org/wiki/LPC_(programming_language) https://en.wikipedia.org/wiki/LP

I admin/dev on an old LDMud, which means the "game" is written in LPC: https://en.wikipedia.org/wiki/LPC_(programming_language) https://en.wikipedia.org/wiki/LPC_(programming_language) Perhaps not a terribly interesting addition to your list, since the reason is obvious: I keep using it because it's the language the game is written in. That said, I'll play along and discuss what I like about the language: One of the fun things about working on an LDMud or in LPC is that the game driver (written in C, compiled) gets loaded and serves as the virtual machine for your game, and the parser/compiler for your game's LPC code; this means that once the game is up and running, as long as you aren't editing some really foundational game objects, you can create/load/destroy/update/unload most of what you use inside the game environment without a recompile/restart of the game. There's very little friction when you can quickly play with the new objects/npcs/environments you're creating as you iterate. You can see the age/heritage of the game as a glass half full, or half empty. You can be frustrated that some relatively modern concept/module/support doesn't exist, but you also have the opportunity to learn from writing it (and not just as an exercise; for production!) Because it's got such a long legacy, you get plenty of chances to rub up against old code and reason about what constraints may have shaped it, and whether it is worth refactoring. Chances to become conscious of the extent to which decisions you make in the present will someday look as curious and smell as musty as the legacy code you're griping about. It's very OO, and code re-use is a big deal. There are some really complex inheritance trees, and while a lot of issues you'll run into are the sorts of problems you'd expect, I feel like it's pretty good training for breaking down and reasoning about complexity of any sort. This gets ratcheted up by the interesting concept of allowing a certain kind of object to "shadow" another object at any time. A shadow object will intercept calls to the object it is shadowing, giving it the opportunity to modify how the shadowed object will behave. So, for example, most classes, subclasses, boosts/buffs/curses/etc. are implemented as shadows you apply to a player object, or to some piece of their equipment.