The Mud Connector

Author Topic: Starting a mud: A Software Architect's perspective  (Read 1284 times)

Maeglin - RealmsMUD

  • New to TMC
  • *
  • Posts: 21
    • View Profile
    • Realmsmud
Starting a mud: A Software Architect's perspective
« on: January 26, 2018, 6:59 PM »
So, you want to create your own mud? Fair enough. How do you get started? Let's assume you decide, "I'll learn how to code and write my own from scratch."

What you often see in software development - especially failed software, is that the creator had great ideas. Often times, brainstorming sessions are done and a laundry list of features are turned into requirements. Little cohesive thought is taken as to how everything should work together or the scope isn't correctly planned for. Some things won't work well together. Bugs will flood the game. Corners will be cut. Features hacked. Projects cancelled. AAA titles like Dragon Age: Inquisition, Skyrim, Fallout New Vegas, and so many others are (to me) perfect examples - so close to greatness yet so inherently flawed.

I've seen this very often in software development of any kind. People fixate on the easy things. They come up with the wishlist - the laundry list of requirements and then write some code to do it. They want it all. They want it now. They seem surprised when the outcome sucks and sucks hard. The single-most important question was never asked: Why? We often know what we want the software to do, but toward what goal? Why should it do X? Does the target audience actually WANT to do X to begin with? Writing software is easy (caveat: I've been creating software professionally for well over 20 years) - even writing software that is very good from a technical standpoint. Writing the right software for the task at hand, however, is not and the overwhelming majority of stuff out there at least partially fails. That being said, I'd also add that at least 80% of it also fails to be good from even a technical standpoint, but that's another discussion entirely.

Anyway, one of the techniques for figuring out the goals and the why of software development is to identify some potential users of the software and create personas for them. So, in a mud's case: What do people want out of this game? Why are they using it? What will annoy them? Once the personas are created, I write a series of stories for that persona. These take a single facet of the game functionality and show how each persona would interact with it, knowing full well that some people will not make use of certain features. Once all of these features are identified, I then determine at a high level what I need to do (task) to accomplish each one. From this list of tasks, I then decide if they are a requirement for the initial release of the game, something for a later phase, or a "nice to have but not needed".

An example:
Persona: Bob is a hard-core gamer whose life is fulfilled by sitting at the computer to escape his sad, pathetic life. He lives vicariously through his online personalities - typically a violent, belligerent sociopath. He likes to "play the system" to get the optimal, most powerful character he can and if this means stepping on his friends to accomplish this, so be it. He's not above cheating if he finds a way. He subsists of Cheetos, Mountain Dew, and beer - forgoing simple hygiene as it wastes precious minutes he could be spending advancing himself online. His social skills have long-since atrophied and he's not particularly interested in talking to anybody whilst he plays.

Bob decides to log on to RealmsMUD and he creates a character called "Ralph". In time, Ralph spots a lone merchant caravan coming down the roadway ahead of him. With a wicked grin, Ralph crouches behind a tree and waits in ambush. As soon as a favorable opportunity presents itself, he lunges out with his rusty, makeshift sword in hand and hacks apart the merchants, looting everything he can carry, and leaving their dead, soon-to-be bloated corpses to rot in the baking sun.
Now then, from this one persona, a ton of activities can be discerned - including but not limited to: Characters move around freely in the world, characters emote, characters can employ tactics, characters can wield weapons, characters can fight other characters, characters can take items, time passes, weather... From these high level activities, individual software tasks can be identified. "Characters can wield weapons" might uncover these tasks: 1) characters can carry weapons (specify each type - sword, dagger, bow, etc), 2) character can gain skill using a weapon, 3) characters can use weapons, 4) weapons improve characters' attacks, 5) character can craft weapons, 6) weapons can be of varying quality, and so on... This last list would then be prioritized. To satisfy the ability to fight with weapons, only 1, 3, and 4 are needed. 2 might get added because it's sensible, 5 gets left for version 2 of the game, and 6 is a "nice to have". Come at this with different personas (a role player, those with more cerebral characters, etc) and then build your consensus features first. Also, ask players what they want - not just your friends, but really do your research.

Prioritizing is essential. We do not need to get everything done right away - if we try that, we will fail miserably and what's more, it'll both be really big and it'll take a long time before we write something nobody wants. We can't recover from something like that. Fail early. Fail often. It's a good thing provided that one's ego can be held in check. Failure leads to improvement. Anyway, by prioritizing, we can concentrate on only doing the most important things at first - those differentiators that make people want to choose a mud - any mud - over WoW, a Bethesda game, a Bioware game, or even their D&D group.

When you decide "what", then you move on to "how", and you should spend the time figuring out the "how" (ie: get a good software design) before jumping in to writing code. And then write tests to prove your code works - but those are completely different topics.


  • New to TMC
  • *
  • Posts: 21
    • View Profile
Re: Starting a mud: A Software Architect's perspective
« Reply #1 on: January 26, 2018, 8:12 PM »
The single-most important question was never asked: Why? We often know what we want the software to do, but toward what goal? Why should it do X? Does the target audience actually WANT to do X to begin with?

I couldn't agree with this more. When I was first interested in developing a MUD, I got involved with a project where I asked this question and two of the other collaborators got super defensive and started flaming. The truth was, they didn't have an answer. Needless to say, I retreated into the background on this project (still an opportunity to learn, right?). Since then, the project has pretty changed multiple fundamental elements and is starting to look like a bit of a circle jerk. Can I say "circle jerk" here? Oh well, I just did. Anyway, I'm basically just kinda expecting/hoping they flame out when they realize they aren't getting anywhere and have no idea why. Pun intended.

In any event, I think an orienting philosophy is essential, not just for a mud, but for any design project. It's the same in tabletop gaming. Not defining the "why" and having everyone on the same page as that "why" is a surefire way to kill any project. I've lost count of the number of projects I've worked on that flopped because people just didn't think the "why" was important.

(If this was reddit, I'd upvote this thread.)