Lately I’ve been playing a lot of online chess. At the same time I’ve been messing around with new mud ideas. I like chess, and I like muds, so naturally I ask myself — can a mud play more like chess?
My answer isn’t an unqualified ‘yes’. To play strictly like chess you’d have to remove chance (notwithstanding some chess variants I guess) and I wouldn’t be happy with a system that totally relies on player skill. Some of the attraction of a mud is playing a character after all.
However injecting chance into chess is really a minor point. What are some of the qualities of chess that might work in a mud?
- You start off equal to your opponent
This seems like the least workable chess-ism, however it’s not unusual to spot another player a piece or two, so there’s some precedent for asymmetrical starts at least.
- You have a variety of pieces with different moves
Different ‘moves’ in a mud aren’t unusual (kick, punch, etcetera), but I think this quality of chess leads to an interesting idea.
You have a variety of abilities, each with a range of moves. Standard stuff. But, as with chess, at any time your abilities will be in some arranged state. There’s a big difference between a white pawn on a2 and a7. Now add a white rook on a1 and the game changes yet again.
This is the essence of chess. One problem doing this in a text mud is visualizing this arrangement without making it look like, well, chess. One simplification would just be to reduce the number of pieces/abilities. Another might be to create a dynamic description of your character in a conflict that updates itself as the conflict continues.
This gets to a personal taste of mine; in many muds the flow of action is very quick, with text whizzing up the screen. It gets even faster when you’re grouped. Many players enjoy this, no doubt, but I’ve always liked a slower pace, or at least more of a reading experience than the virtual text shmup of much mud conflict.
So I’ve seen some muds experiment with a fixed room description window in the client that changes as you move. Why not a ‘fixed conflict description window’ that updates too? Basically this is your ‘chess board’ that shows the arrangement of abilities versus your opponent(s). Thinking of it that way, it probably would work best combined with a fixed room description anyway.
Now as I said, the visualization is one problem. It’s easy for a player to strategise when they understand their options — a pawn moves forward, a rook can protect pieces on its file and so on — but it gets more complicated when you’re in a mud simulating some world model. I don’t have an easy answer to that, but I think it’s an interesting avenue to explore at least.
- You (might) have a time limit
Since I’ve been thinking of doing something turn-based in a mud, an overall time limit (of course you can have each turn take limited time, but I’m thinking for the whole conflict too) might work very well. I’m not sure if modeling this as ‘fatigue’ or some other reserve pool, or an actual extra-diagetic time limit would work. Maybe a combination of the two.
- There’s a tradition of studying games
I think this is an interesting possibility. Usually to ‘get good’ at a mud you just play your character, talk to and group with other players and maybe read a guide or two. What if studying other character’s conflicts was a means to improve as well? It might be cool to put this in the game fiction somehow…say, you could listen to game-generated songs that described a character’s actions in some situation.
At the moment I’m working on an idea where I think some of these concepts could work well, so we’ll see where this goes.
If you’ve played muds for years, can an old mud still be interesting?
I think the last mud I played was ConQUEST (which is back on hiatus it seems). I keep an eye on TMC for new listings but nothing that interesting to me has shown up. Inspired by a tweet from ‘Fmud’ Matt I went back to the listings and from an ‘all original’ + ‘levelless’ search tried Geas.
So, can an old mud still be interesting? Not fun mind you, I have no doubt old muds can be fun. But interesting? According to TMC Geas started in 1998. I think I might have tried it briefly long ago but the memory is old enough that I pretty much was starting from scratch. Can an old mud be interesting when you feel that you’ve played all the old muds have to offer?
Well, a logical question is, ‘what is interesting’, and since I’m using that word a lot I guess it’s on me to define it for the present moment. I admit that interesting is a rather uninteresting, lazy word. But if I tried to define it I wouldn’t be talking about Geas very much, so let’s put that definition aside for a minute. I’ve only played Geas for a couple of hours so this is naturally a first impression rather than a review (though impressions should suffice to say if something is interesting 🙂 ).
Geas is an LP mud, and for me LP muds automatically ‘feel different’. It’s not that I’ve played mostly DIKUs (using the term loosely to encompass all its children in the mud family tree); my first mud was Lost Souls in fact. I think this feel is due to the nature of how people create LPs. Because the LP development tools allow for a great deal of flexibility within areas, the game texture is knottier, more complicated. DIKUs feel more uniform. Maybe LPs are wool, and DIKUs are polyester? I’m worried about what value judgements that might imply, in either direction…
So, Geas feels different, and not always in a good way. For example, some of its command parsing is old fashioned. It doesn’t recognize abbreviations in many cases. It’s a good example of a rich command set that lacks usability.
From my few hours of playing I think this example is an expression of a core property of Geas, and probably of many old muds (and maybe LPs in particular). This is the core property: complicated complexity.
Complexity doesn’t have to be complicated. I think God Wars 2 is a good example. That’s a complex game by most accounts. However the information is laid out cleanly and simply most of the time. Geas seems like the opposite case. However it’s not entirely a fair comparison. GW2 is mostly the work of one developer (who had several other muds to look back on for experience). Geas appears to be a team effort, and it’s twice as old to boot.
On the other hand, many times Geas does feel different in a good way. Your character’s hair grows. You can shave it, or I presume grow a beard (!). This seems like a minor detail, but was quite delightful when I discovered it. The hiding, sneaking, and tracking systems are well developed. There seems to be a generalized climbing mechanic. Again, it’s fun to find this stuff out. The combat system is more slowly paced than most muds (a plus) with multiple tactical options (more plusses). There are no levels or classes, and many skills to learn (by use).
There are many color customization options (good), but limited colors (ansi with some extensions), you have to design your own color theme by hand (no good default packages) and some odd typography like in how the room descriptions are laid out (not good). There are more toggle’able output options than usual (good), but weird design choices where other characters can spam songs or actions like juggling, and it seems like you’re forced to pay attention to it.
This last bit bothered me a little and made me wonder about possible solutions. It’s fairly common to have options to control what combat messages you see (indeed, Geas has some options just like this). I’d like to see a more generalized system where you can control the level of detail your character sees for all actions.
There’s a flexible emote system for RP, it seems like lots of provisions for PC politics, and a somewhat RPI’ish slant toward RP in general (an introduction system, no PCs you don’t know in the who list, no game-wide OOC chat, etcetera), but also an extensive website, and wiki with IC information. It’s an attempt I think to control the IC/OOC split, but from many threads on the OOC web forum I’m not sure how successful that control has been. The web forum has a nifty mud-connected registration process (you generate a key in game to use for registration, presumably to control signups and reduce spam), but there was a bug and it didn’t work for me. Complicated complexity.
Overall I’d say much of this is natural. Muds grow organically. Geas is almost 15 years old, probably older than some of its players. In a way I don’t have a right to criticize it after playing it for a oouple of hours. In the end I found some sewers and fought some rats for a few minutes. It felt very familiar. From what I saw before I’m certain there’s a lot of depth to this game. A lot of complexity. But does it have to be so complicated?
I’ve started to poke at something that’s been on the back burner for too long.
I put out IFURLs (a weekly curation and summation of interactive fiction links) for about a year, and while I enjoyed the process I felt like I reached a natural limit doing everything by hand after a while, so I put it on hold. The new idea (well, it’s certainly not new at this point) was to build a tool that would make the process easier and invite collaboration from like minded folks. I thought that while I was at it I could add feeds from outside the strictly-defined parser IF community, since I did that anyway with the list by hand. Choice-based games, muds, electronic writing of every kind — what I wanted to make was a huge firehose of all that stuff and then develop the tool to make it easy to filter and sort that information for the reader, the ultimate goal always being to present a weekly select list of the most interesting links. So it’s not a planet site, and not an add-a-link Reddit or Hacker News clone; I’ve seen these kinds of sites described as rivers and that’s not a bad description.
I’ve taken the first step of putting about 30 feeds (some are planets as well) on a page.
Clj-rome wraps the rome-fetcher RSS library, and that seems to present the first issue. You can see in the screenshot that some of the items include dates and some don’t. It appears that rome-fetcher isn’t parsing some of the RSS pubdates correctly. The Mudbytes feed items for example includes pubdates, but I don’t get them in the rome-fetcher parsed feed.
I remember 5 or so years ago when I swore I never would touch Java code. I seriously had a natural aversion to it from the first time I had half an idea of what it was all about. I guess Time is the great Trickster, isn’t it?
I’m not sure how to proceed with the pubdate issue. There was a somewhat related issue filed at the rome-fetcher Jira page, and I commented on that. In the worst case I can add my own date based on when I pull down the feed item, since it’s not that important that my date syncs precisely with the actual post date of whatever I’m grabbing.
A nice thing about Java is its layers of abstraction. It feels industrial and solid. Of course that’s also a downside; getting at a problem seems to require a lot more peeling back of layers, though I think (hope) some of this complexity is just a lack of familiarity.
I think development on Lampost started at roughly the same time. Lampost is a Python mud framework with the start of web-based OLC. The author of PlainText has posted in Lampost’s thread at Mudconnector so with any luck we’ll see some collaboration between the two projects. It’d be great to have a reusable web-based OLC or even a common mapping standard.
Matt Adcock, the creator of Fmud and original coder of Maiden Desmodus is pondering new game ideas according to his Twitter feed. Sean Lucas, creator of the fun in-stasis web-based mud Archons of Avenshar, is rewriting that game. I dare say those two would make for a killer mud dev team.
You don’t often see young MUD coders learning about what’s out there before they sit down to write their own codebase. I first wrote that line several weeks ago. For the past few days, the DGD mailing list has been swamped with email from a fellow who has decided that the existing codebases for DGD are too complicated and intricate to bother understanding, so he’ll write his own that works better. He seems to be a quite decent coder, yet he uses that reasoning. Am I the only one who sees that as a fundamental contradiction?
New programmers set out to solve problems, to write a grand new codebase, and that’s wonderful. But why do they read through only a little documentation, and only two or three existing codebases at most?
I believe that the very biggest reason is a lack of existing literate coders. The various MUD camps (MUCK/MUSH/MOO, Diku/Merc/Rom, LP*) don’t mingle much, and few people know a reasonable amount about more than one of them. It’s hard to become literate in existing MUDs if you have no role models, no overviews and surveys, no people who can answer broad questions like “has anybody ever tried this before on a large scale?”. It’s hard to become a literate coder in a vacuum, having nobody to compare notes with. The lack of decent programming documentation for any existing MUD doesn’t help. Reading source code takes a lot of time and effort, and few new coders understand just how important it is. So few of them bother to do it.
At this point, it’s obligatory to mention brash young programmers, considering themselves cowboys, who are going to revolutionize the world of MUDs all by themselves, and how they start over not because the existing code is bad, and not because they know nothing about it, but because that’s their way.
Balderdash. I’ve gone to school with those brash young programmers, worked jobs next to them, trained them in programming, worked with them on open source projects in 3D graphics and 3D modeling… MUD programmers aren’t all that different a breed. They’re just in a deceptively easy-looking discipline and have nobody really impressive to compete against. They are neither good software engineers (who is, when they start?) nor awed. They believe they can do everything that the existing codebases can do, given enough time. And sadly, they’re mostly right. At least, if they had a decade going spare.
Richard Tew, aka donky@MudBytes, recently put up a mirror of the old Imaginary Realities mud zine, containing some of the collective wisdom of developers such as Raph Koster, Richard Bartle, and others; incidentally, a little over a year ago he created an mbox archive of the mud-dev mailing list, covering ten years of mud development discussion.
Mudlab sticks around, like a quietly humming tape drive, full of mud dev ideas; and of course hundreds of muds are out there, some as empty as unmanned lighthouses, but their light still flashing if you care to look for it. Rom, Merc, Mush, Cold, LP…decades of ideas expressed in code and (perhaps) source documentation, waiting to be found again.
It rather reminds me of the endless questions you see on stackoverflow and Hacker News on how to learn programming. Usually the answers revolve around which languages to learn and what books to read. But very, very rarely will anyone suggest what programs to read or what software to use (beyond learning version control or one of the canonical text editors). Would anyone tell an aspiring author they just should read Stephen King’s book on storytelling and a manual on Microsoft Word and get cracking?
In mud forums developers will discredit anything with a DIKU stamp as hopelessly antiquated — yes, old code rusts, but then again, all that glitters isn’t gold.
If you continue the analogy with the writing world you see part of the problem with reading code rather than just writing it; most writing isn’t that good, and a lot of it is terrible. But it seems like it’s a lot more work to find the good code compared to finding the good writing.
Maybe that’s because code is not just meant to be read, but to do useful work — and while it may be less elegant to hammer a trim nail with a framing hammer than a finish hammer, you still get the job done (as I can well attest).
What’s more, the better you are at hammering, the less it matters what kind of hammer you have. Indeed, there’s a bit of pride involved in making rough, crude tools do fine work, and I’d guess it’s even more fun to do it yourself, rather than throwing some expensive (in terms of effort to learn or obtain) tools at the job.
I don’t deny it’s necessary for people to reinvent old ideas, but my opinion is that the successful developers will have an acute awareness of what’s come before them. At a certain point, if you’re serious about what you’re doing, you need to dive down deep.
Have you seen a hundred people gathered in one spot? A hundred people
is a lot of people! If you, as one person, can make something a
hundred people enjoy, is that not an amazing achievement in itself?
Especially, as often in roguelikes, that the hundred people aren’t
just friends and relations pressured into “enjoying it”, but instead
random individuals with theoretically better things to do.
I would never advocate intentionally limiting your audience. You had
expressed dismay that a game had only reached 10,000 people, however.
While we can all likely agree it would be better to reach 100,000, it
isn’t necessary. And one shouldn’t feel dismay.
Turn it around – there are only so many games *you* can play in your
life. So how many people can expect to have you be a player of their
game? In some ways it would be tragic if all games hit 1 million
players, for that would mean there would only be a few thousand
games! Us humans are way too diverse to limit ourselves that way.
On Github the other day I randomly did a search for ‘mud’ and was knocked over by the number of mud projects I found. Of course, most of these were half-finished (more like half-started). But in light of that and some other notable discussions lately the gears got to grinding.
While there’s a vast amount of mud information out there, it’s widely scattered, buried in archives, or surfaces once every umpteen years like that Scottish castle I can’t remember the name of when someone asks a relevant question on a forum somewhere.
None of this is particularly bad or even unusual. Information has a habit of filtering down like groundwater into the substrate of a community. But to beat a bad analogy a bit more, I feel like the wells are starting to run a bit dry.
Between the whole fiasco with ‘mudstandards.org‘ and the general sorry state of protocols with respect to server and client development, if a young coder decides to make a mud or a mud client — a worthy, attractive project, and based on the number of repos on Github I’m not the only one with that opinion — they are going to have a frustrating experience and are not going to get much support from the state of the existing resources.
The mud community doesn’t gain then the resources or energy of those developers in return, and this reinforces a negative feedback loop: projects that could be promising don’t overcome the friction of their early development, and the mud community rolls on without as much progress or evolution as it could have.
And this is just my personal feeling now, but I’m a little unsure there’s that much value in having shared standards in this field in the first place. In the end of the day this is about making games, and if you can provide a good client that people use to play your (good?) game, that’s all you need. Past are the days of only using telnet from a relatively dumb terminal to connect and therefore there being value in standardized connection. How many of the successful games (not just MUDs) out there support more than one client?
While there’s an important truth here (don’t lose sight that we’re making games) I think it misses an important point. Muds came of age within a strong tradition of free games and shared resources. To now lump muds in with the general field of games essentially ignores that history. While commercial text muds are extremely important in my opinion to the health of the mud community, and not just commercial muds but ambitious games with custom clients, the history of free games and shared resources shouldn’t be consigned to the past or simply salvaged and scavenged like you would a shipwreck.
But back to the point and the title of this post. At the moment there exists no comprehensive, current reference for the aspiring mud developer, but this information does exist and I think could be assembled with some work. With promotion I think new mud devs could find this reference fairly easily, and within a short amount of time (on the mud time scale anyway) we would have a document that, simply because nothing else like it exists, would be the ‘go-to’ reference for new mud developers and a touchstone for the rest of the mud community.
My plan now is to contact a few people and start to pull together resources to see how this takes shape.
Warning: serious rambling ahead.
For a while I’ve been kicking around a 3D mud idea, but certain problems seemed intractable. Sure, I could write graphical building tools and incorporate maps into the client, but the more I explored that the more I felt a deep disconnect between that and the experience I wanted in the text game itself. I had to ask myself if I wanted Godwars 2 with a z layer, and somewhat to my own surprise, the answer was…not really. What I did want was a more dynamic space than what you’d get with a classic room-based mud.
Some muds base their room layouts on coordinates (Dead Souls I think does this as well as the in-development Lithmeria), other muds such as Maiden Desmodus use pathfinding algorithms and landmarks to make navigation easier. The old Legends of Karinth, as well as many other muds, had a dynamic wilderness system in addition to a room-based layout.
What do I mean by dynamic space exactly? I’m talking about characters scaling buildings and cliffs, racing across rooftops, running rapids in a river, jumping off a waterfall…you could certainly simulate this with a 3D coordinate space, or you could write specific systems for what you wanted — rooftops code, or river-running code — or you could even create all of these spaces with a room-based layout.
But to step back even further for a moment — what is the text experience I want to create? My ideal is something between an open world game, and a path-driven game (think of a gamebook or a classic cRPG). In an open world game there’s always something else to explore, new territory to cross. In a path-driven game — let’s call it a directed game — the choices are constrained but each choice gets more weight and narrative and interactive impact.
At first glance this looks like a dynamic wilderness system plus a room-based layout. But when you’re in the room-based world you don’t really gain the advantages of the wilderness space, and vice-versa.
Not to say it wasn’t fun in Karinth, it was. But my thesis here will be that wilderness plus rooms doesn’t offer as many dynamic possibilities as a more integrated approach, and that a full 3D coordinate system the player interacts with directly provides a text experience different from what I’m aiming for.
First a little summary of how most muds handle it. The space of room-based muds is defined by rooms/nodes and exits. Rooms commonly have a sector/terrain type and an indoor/outdoor flag. Some systems use internal room coordinates, dynamic furniture, portals within the room (somewhat distinct from exits), allow missile combat between rooms, define an air/sky space above rooms, and so on.
As you move through the world, you get a room description (or not if you’ve turned room descriptions off in your configuration) and (sometimes) a list of exits, you choose an exit, get the next room description, and so on.
Karinth’s dynamic wilderness used an ASCII map that basically substituted for the room description, only it was a much lower scale view. The game generated the wilderness map from a large graphic map (reading the pixels); traditional room-based zones were placed on the map (much like Godwars 2 places dungeons on its world map, though those dungeons aren’t really room-based).
Two things stand out from this summary for me. First, that once a player has read a room description a couple of time, they’re unlikely to read it again. At that point rooms are purely containers to define the space (with a caveat for dynamic descriptions, which I’ll address in a moment). Second, once this happens, the player’s main interaction with the room is to use it to know where they are.
Of course this is blindingly obvious. But allow me to talk like an idiot for a while (if I haven’t been already). Disregarding coordinate-based muds for a moment, are rooms the only way to know where they are?
What is ‘where’ in a mud anyway? Where can mean a lot of things. It can be where you are in relation to something you’re hunting, or something hunting you. It can be on the way to a destination, or it can be a somewhere you run to or through while trying to escape. It can be a location in a quest or a safe haven where you can rest without fear of attack, a place of quiet work or a gathering spot.
It so happens that rooms are a simple and flexible way to make this work. Coordinate systems extend this concept and add a lot of functionality, at the price of some interface hurdles and other technical challenges. Rooms on a coordinate grid is a third possibility. But is there another way to do it?
Going back to an open world + a directed world. How could you abstract the space in a mud in such a way to create the environment where that experience would develop? I think you could use four elements.
Spaces are containers of any size, arranged in a tree. These aren’t rooms as we know them in muds — I don’t know of any room systems where you can examine the outside of a room, for example. They’re more like a basic thing in a mush; the base thing in Godwars 2 also works similarly I believe, as a container you can put things into (and examine from the outside). I’m not calling them things or containers because I don’t want to pin them down in such a way; a space could be a treasure chest, a house, an ocean, or an atmosphere just as easily.
Surfaces are 2D surfaces (in the mathematical sense) related to spaces, such that they don’t exist on their own. A surface always is in or on a space, in other words. A surface would be a ground or wall plane, for example.
Paths connect spaces, and usually lie on a surface.
Finally, features are interactive or dynamic elements that are not necessarily spaces, though they may be spaces themselves, and relate to paths, surfaces, and spaces. For example, a path might cross a chasm. The chasm could be modeled as a space itself, but often it would be more convenient to make it a feature of the path.
So, why bother? What can you do with this model that is harder to do with rooms or coordinates?
Consider the ideal again — open world plus directed paths — in light of this example: A group of players want to go explore a ruined castle they’ve heard of up in the mountains. They find a path to the mountains and set out.
Now, if they’re not moving through rooms, or coordinates, what are they seeing? Back to dynamic descriptions. The game, using the properties of the path, the characters, the space and the surface the path relates to, its features, etcetera, describes the experience of travel. The path has a distance which determines the amount of RL time this process takes. It’s like a pen and paper game where the DM leads a party through encounters and choices.
In other words, there are no room descriptions, but periodic messages that describe the experience. However, this seems to create a problem related to the discussion above — how do the players know where they are? Fortunately the answer is quite simple. Based on how far along the path they’ve traveled, where they are is a slice of the path at that moment, much like the description you see in Godwars 2 at any one moment as your character is traveling.
If that’s the case, though, isn’t this just a very circumscribed coordinate system? What makes a path better for this experience?
I think the advantage is that the path is especially created as a directed experience for the players. The encounters, the messages, can all be tailored for this experience as well. Of course, you could accomplish much the same thing in a coordinate system by adding paths to it — but what is the interesting part here? The path or the rest of the coordinates? I would argue the path.
But, that ignores the open world I was talking about. Indeed, straying off the path often is just as interesting! Laying out many, many paths from the ‘current path’ at every point of that path doesn’t seem ideal.
This is where spaces take over. In our example, the players are on the path, now in a forest (a space). A couple of characters have the idea of exploring…what happens?
The forest space now takes on some of the functionality of a path. It provides encounters, messages, and choices as the players explore. Whereas on a path the player doesn’t have to worry about direction (always either going forward or back), in the open space the players do need to make navigational choices presented by the space. However there are naturally other paths in the game world, and what happens is the other paths ‘pull’ the players towards them. So, the forest is a possibility space; once you stray from the current path, the forest presents multiple choices that lead you in the direction of other paths.
So our characters wandering in the forest come to a steep cliff wall. Here is a surface. The cliff could be a space of its own, but in this example it’s more likely that it’s a surface within the space of the forest. This surface has properties of its own — the difficulty of climbing it, what players may find on it, and so forth.
The cliff also brings up the question — once the players climb it, where are they? How far are they from the original path? How much time would it take to return? Could they return by some other way, not climbing down the cliff if it’s too dangerous?
Ultimately this question is asking, are spaces, surfaces, and paths actually related in space in a logical way? How would players map this ‘experience’ so it wouldn’t be blind wandering every time they wanted to enter the forest? Certainly it would be a frustrating experience if space wasn’t somewhat predictable.
The answer is that the elements are related in 3D space, but the player doesn’t interact with the coordinates at all. Their framework is basically time and spatial relations (how long does it take to go from this to that and in what direction, that is, a vector) and choice (what do I go to, and how). So in the case of descending the cliff, the players really are wanting to go back to the path from which they came, and so the game would offer them the option of finding another way around the surface, taking time and spatial relations into account.
By completely abstracting the 3D world, yet maintaining it in the underlying simulation, the player gets the dynamic movement of an open world and the directed experience more similar to a classic room-based layout. The game stresses what’s important — time, spatial relation, and choice — while not bothering the player with micromanaging coordinates.
It should be clear that the text experience you get here probably won’t be appealing to many players used to room-based layouts, but I feel that it could attract a different group of players with its ‘directed freedom’.
So, where to go from here? With any luck, a prototype, using Pants for networking.