I've been working on Agony Forge for more than 20 years. No, really! It wasn't always called that, of course. In high school it was Antares (somebody else's MUD I worked on), and then Rogue Winds (my MUD, based on Smaug), then Equinox (my first attempt at a custom MUD codebase). In college it was Divine Right (my first dozen custom Java MUD codebases). A few years ago it became Agony Engine before I finally landed on the name Agony Forge. It has really only been a month or two since I figured out how "Agony Forge" fits into the lore of the game I want to build. But it is true that I've been working on a MUD codebase of some kind on and off since I was in high school around 25 years ago.
This game project was crucial for me in college and throughout my career: the MUD codebase was always using a technology stack heavily influenced by whatever I was doing at work, and so it was a safe place to experiment with ideas I had. Many times throughout my career I would visit my own GitHub page and borrow some code from my own codebase to do something for work, because there was some relevant idea I had tried out earlier (to any employers who might read this: I never ever copied code in the opposite direction). To anyone starting out in their own careers, I definitely recommend having a side project similar to your work stack where you can try out all the things you were thinking about at work and never had time for. It's a great way to learn. Just don't copy code in the other direction, and don't work on your side project on company time or on company equipment. And probably don't talk about it at work, either.
The downside of having a project like this that has followed me for an entire career is that I've never finished it. I've actually never finished any game unless you count the couple of MUDs I worked on in high school that had players. Every time (including this time) I say I'm going to definitely finish it this time. Every time I get part of the way through and decide to start over. Sometimes it's because of a technology change like adopting Spring Boot or switching from an SQL to a NoSQL database, other times I just get frustrated because it gets too difficult to add features or I hate the way I designed something. I feel like it's an albatross around my neck. It makes me feel like I'm not a good developer, even though my career is proof enough that I am. I'm too stubborn to give up even though the demand for this kind of game died out 15 years ago. It's getting built even if nobody ever plays it.
I'm taking a different approach this time and I'd like to go a little bit more in depth about that. In the past I've been very focused on the technology: how to design the code for the game, how to solve problems like routing messages between players or how to manage timers for combat. But I've neglected designing the actual game. I spent quite a while learning about procedural generation, generating mazes, even trying my hand at generating descriptions based on templates before LLMs became widely available. All of it was very interesting and some of my attempts were even actually kind of good, but as I look back now I realize it was ultimately an attempt to program my way out of designing a game. My game is likely to have some procedurally generated things in it, but I've learned the hard way that you can't just generate the entire game.
In the past I've always built a nice engine, or part of one, and I've always gotten to a point where I need to make some rooms, objects and mobs. I'll make some test rooms and a sword and a hat or something to test it out, and then... I stop. And by stop, I mean I stop working on the whole thing. Because I didn't design anything beyond that point, and while I'd never try to say it was "done", I get massive writer's block and can't see a path forward. It was only recently that I started to understand why this keeps happening.
This time I'm designing the game first. I spent some really fun time doing world building. I've been coming up with a story and a world I'd like to build, stories and ideas for how the world works and why it is the way it is. Originally it was going to be for a TTRPG I wanted to run for some friends, but one night the idea came to me that it would be a great MUD setting as well. So I'm probably going to do both. For the first time, it's starting to feel like I have a design for a game, and not just an engine. When I get to the point where I need to make rooms, I actually have a map of a city and the surrounding wilderness. As I build out the rooms for that, I'm sure I will find that I need new features, and that will drive me to add them. As I build the items from the stories I wrote, I'm sure I'll need new features to support those too. I even have NPCs I can build that have backstories and personalities already, and I'll need to build out features to support all of that.
To wrap this up I'd just like to leave you with what led me to better understand why I can easily finish projects at work, and even some at home but never this one, in case you have the same problem. It's simple. I was only designing half the project. At work, I design the whole thing. For small side projects, I design the whole thing. For this I kept designing just the engine, and so all I could ever build was the engine. To build a game, you have to design the game. If you're using something like Unreal or Godot you don't even have to design an engine at all. In my case I do, but I also need to understand the game. It sounds stupid now that I've written it out. It's dumb that this has plagued me for more than two decades, but I suppose that's part of learning engineering. If you have a project like mine and you can't figure out why you can't do it, take a step back and look at what you have actually planned out. Maybe there's some portion of it where you said "I'll figure that out later". Go take a look at that part and see if you can figure it out, because that might be what's missing.