Game Development by Sean

Making a MUD for the Web

Table of Contents

This is more of a quick status update than anything, since I’ve been so quiet lately.

In what little free time I have outside of work and day-to-day life, I’ve been playing around with Web development again. I used to do Web application development professionally. The Web changes quickly, of course, so a good portion of my experience had somewhat bit-rotted and I decided that I should bring it at least a little current. Especially since I’m leading the server team at work and I’m in charge of hiring and directing things that look very much like (if not literally being) Web development.

I also have been wanting to make a little MUD (multi-user dungeon) again. MUD development was one of my first serious forays into releasing open source code (way back when SourceForge was still relevant!) and arguably my first real games development in C++ (rather than BASIC).

My new Web experiences have been a mixed bag. I’ve spent more time wrestling with the popular/recommended tools or trying to figure out the incantations that make clear and simple requirements actually function (CSS and the browser engines are as “magical” as ever; when your platform requires me to read a variable to trigger an animation, you know you’ve utterly failed as a platform engineer) to trying to get builds to work (Gulp is based on the idea of pipes instead of graphs like every other build system ever, because many Web developers ironically like to chant “code not configuration” while writing their declarative Reactive apps) to reading fascinating discussions about just why Node silently ignores some typos inside of asynchronous functions (short version[1]: whining that having diagnostics for many serious errors is not worth a small handful of rare easily-avoided false positives, nor worth mandating that the error-reporting facility be used for diagnostics instead of transmitting application state).

All that aside though, it’s been an entertaining project. I’m most fond of React and how that got my gears turning on how game UIs could or even should be structured[2], rather than how middleware like Scaleform or popular engines like Unity or Unreal want game UI to be structured.

While not working on that project, I’ve also been spending some more time researching error handling mechanisms in Rust and Swift with the intent of writing up some suggestions to the SG14 C++ group about how we might fix the “exception problem” (and also reinforcing to myself the notion that exceptions are conceptually broken misdesigns in any language, managed or unmanaged). Yes, I’m still keenly aware that I need to finish the flat_map proposal.

On that topic, congrats to Brent for getting his (and SG14’s) first proposals officially accepted into a C++ working draft, and congrats to the committee and many other folks who put in a ton of hard work to get C++17 (mostly) nailed down.

Regarding this site, I’ve been considering trying to get into a habit of writing a new article every couple of weeks, perhaps dedicating an evening a week to writing. I’m not sure if that’d be a better use of time than working on guest lectures for DigiPen, though, since past videos have been rather well received. I’d be happy to hear any opinions on which I should devote time to, if either.

[1] The long version would involve a discussion about JavaScript and its terrible misdesigns and the continuing refusal to “break” it, even in backwards-compatible ways that would remove technical debt without breaking existing deployments. Not unlike some of my frustrations with C++ in that regard.

[2] No, React iself isn’t the answer I’m thinking of, but a UI component system driven by functional-reactive state flow is key. Games tend to have a lot more quantity and complexity of animation than Web sites, though, so I’m still ruminating on the details.