A little bit of backstory

This IP has existed in at least one form since late fall of 1996. It is nearly 20 years old at this point. Sadly I don't remember the exact day it started so there wont be a party.

A long time ago over a crummy dialup connection I took the first step in abandoning the drama and bs of trying to help other people manage and code their online games and set out to make my own. I had a copy of the original DIKU Mud codebase in hand and FTPed it into a friend's server and started it up. Up until this point I had been building out content, debugging and augmenting other people's MUDs. I taught myself the C language by getting neck deep in game code (and also networking code before that).

So I had my own online game world. I spent the next year (still in high school I had a LOT of free time) tearing out as much of that code as I could and rebuilding it. At some point the only thing left was the OASIS in-game content editing system and the communications (accepting, managing, closing connections with players) layer.

The game ran (not entirely continuously, but most of it) for 10 years. At its peak I could confirm, to the best of my ability with just IP addresses, just under 2000 unique users and ~50 players online at any given time of the day and night. Between start and finish the code ballooned by ~200k lines of code. (not necessarily good code mind you) 2 CCGs,1 board game, 2 short novels, 1 long form novel, an animated movie script and 2 JRPG designs have been created in that within the same IP in that 10 year span. The "story" bits of the world have been expanded from a 2 paragraph joke in a help file description to 1500 years of various points in lore time.

Life is life

There's a lot of difference between life 20 years ago and now. I could spend upwards of 80 hours a week doing nothing but coding, testing and administrating back then. In college I would spend most of my waking hours working on this stuff.

These days I've got a job. (which is also programming) I've got a family; I've got a grandchild. In the context of all this what I've really got is ~1 hour a night at best which comes after ~9 hours a day of programming for other people and several other hours of commuting, cleaning, etc.

Heavy thing is heavy

Despite all of that I set out to remake the old MUD anyways. The first lesson: Not much of the old code is usable. There is no magic app I can download to turn 15 year old crappy ansi C code into something useful; nevermind the fact that I want this built the way I always wanted the original code: as a generic, elegant platform other people could use to make their own game. There was nothing elegant about a 96k line nested switch statement that's sole purpose was to generate a single paragraph of text out of a round of combat.

Unsurprisingly an entire online world that's had almost a decade of feature creeping ends up being a lot of stuff to do. "Knowing what you're getting into" ultimately does not help for very long. Maybe it's nice to have foresight but it can also be trying to acknowledge something will take years to complete.

Falling back on MMF

I've been in the digital design agency world for roughly 9 years now. Everyday is basically coming up with reasonable definitions for MMF. (Minimal Marketable Features) In the choosing two of the triad of Good, Fast and Cheap client design work is always going to be Fast and Cheap. Consequently cheap also means fast when you contract is defined by man hours so really it's just Fast and more Faster, or really "why can't it be done already?"

What is truly MMF for something like this? Players need to be able to connect to the game, create a character to play, have somewhere for that character to exist and be able to manipulate the world around them.

That's barely anything really. Most would not even call it a game; it's an incredible amount of architecture just to get to that point, though. Truly MMF is more like having NPCs and an AI system, objects, basic commands, a combat system, advancement and in-game communication. Add in requirements like logging, file management, data managment, administrative commands, authentication and system health monitoring. Even then you'd only have the absolute bare bones of a game which no one would likely play much of. We're still standing on the beach trying to see the next continent.

Chopping it up

So the exploration into MMF has handed us an ocean that needs crossing. Cutting it up into tasks is the next logical step. At some point next to the giant world design bible was a text file. In the text file was a long list of words, each word being a system. Each system had children, some children had their own children and so on. It ended up being well into the hundreds of items long.

What about agile! Everyone is doing agile. Each word on the list became an arc or a story. Now instead of several pages of a list of words there was a Kanban board that was really crammed up.

This sort of worked and it mostly didn't. When I had larger blocks of free time it was good. Stories were being completed. Victories were being had. When time was more constrained it was depressing. Pulling up a crammed board knowing I only have 30 minutes and geeze what can I even do in 30 minutes is disheartening.

Splitting the Time

This probably sounds counterintuitive but slowing down the actual progress helped. There are two main tasks here: creating the platform and designing the game. But.. the game is already designed! Sure, I was sitting on 10 years of business logic (game mechanics) encoded into 200k lines of C code but I wrote most of this as a teenager. I hadn't touched the mechanical design in years at this point.

Designing the game isn't progress without the platform to design it into. Sure it basically all just went into spreadsheets and text documents but codifying the mechanics into the actual game was so far down the gantt chart I couldn't see it. Just doing architectural work was no longer cutting it.

Explain things to others

It's been a long time since I've written any help files or translated any of this design into more than just numbers and formulae. I started a subreddit for the platform (https://www.reddit.com/r/TwinMUD/) and have just been making posts outlining the features of the game. Having to explain things not even as decisions just as raw definitions helps quite a bit. Putting numbers into words forces a bit of self-justification.

Being forced to justify design decisions, even only to an empty room/forum, is design work, and ultimately is what is helping push this forward.

Gears have to shift

What use are they unless they do? Maybe it feels like you have to put it into park because you've fallen into neutral but even if you end up in reverse at least you're thinking about the effort.