This might be a fun and useful experiment or it might go down in flames, but I figured why not give it a shot.
What are we doing? We're writing a mud in this thread. But not the 272nd mud in C, or the 103rd in Python. No, not even a mud in LOLCODE…
We're writing PseudoMUD in, you guessed it, pseudocode. It won't be executable by any runtime (yet) known. But pseudocode will be our common ground, our Rosetta Stone, our yadda yadda you get the picture.
Why are we doing it? The goal is a complete, unplayable mud. It's part fun forum game (well, at least I think it's fun), part learning experience, and part learning resource. Think of the children!
How do we do it? We might have to organize later, but for now we'll keep it in one thread.
We're writing a complete mud, so we have to make decisions on code design, game mechanics, content, etcetera. Since making decisions can be hard (TM), here are the rules.
* Anyone can give input. * You make decisionsif you reply, "I want to be an author of PseudoMUD", or words to that effect. * All authors will try to reach a consensus on decisions, but if discussion stalls, I'll call a vote. * Majority rules, I only vote to break ties.
I won't be able to edit this post indefinitely, so I've created an article as a reference.
Before we get to pseudocoding, we need to make some high-level decisions. Like,
* what's our theme and setting? * what's our gameplay like? * what are the big technical decisions? Are we using telnet?
Here are my thoughts:
I think we should try to strike a middle course between making PseudoMUD a basic fantasy H&S Diku-like, and something a little more different. The former is valuable because it's a common foundation that many people can relate to, so it'll serve as a good learning example. The latter is valuable because we'll get to try some new ideas which will keep things interesting IMO.
Technically speaking, I think we should implement websockets and gracefully fall back to basic telnet if players want to use their mud client. I await the flames in this regard :).
The telnet/websocket issue does bring up an interesting question though – how do we handle using external libraries in this PseudoMUD experiment? While implementing telnet and websockets ourselves would be enlightening, I don't think it's the most practical approach.
25 Mar, 2014, Ssolvarain wrote in the 3rd comment:
Votes: 0
Just offhand, I don't think I've ever seen a space mud that wasn't tied to someone's IP. Star Wars, Star Trek, etc.
I'd be pretty happy abandoning telnet completely, and going with some kind of web-based connection. This will force us to design to live in a browser first and foremost. We may lose legacy players who expect to be able to use the same clients they've always used to connect to muds, but if we focus on a good browser experience then we will reduce the barrier of entry for newer players, which will be critical to the success of this pseudo-mud. I'm not totally sold on websockets yet, though. Are they stable enough to build on, yet? Admittedly, I haven't checked for about a year.
Edit: Thinking about it, it might not make sense to choose. We could assume a library allowing us to send the data we need to the client and receive the data we want, and the transport format might not actually matter all that much.
@Nich, IMO websockets are stable enough. There's also the option of falling back to a Flash socket, or using a telnet websocket proxy, or a library like socket.io, etcetera on the browser. I think assuming a library is a good idea. We might have to 'make up' a library in order to program against a 'pseudo' interface. Isolating the transport format will be good design-wise and make PseudoMUD a better learning resource as well.
@Ssol, there are a few, but that's a good point when most of the major codebases with content are fantasy-based. Let's see what other people think.
It might be easier to come up with the features we want in a network layer and assume that we have them (within the bounds of reality, but not with an eye on the features of either telnet or sockets or - whatever). At some point if we were planning on implementing we would have to pick a method that gives us the most of what we want, but we can take advantage of not needing to do that yet here.
For instance, I feel like a must for the network is the ability to send structured data apart from just plain text, so that we can, for instance, send data to display a map, or display health and mana bars. I realize that all of the methods we've been talking about can do that, but I wouldn't consider any ones that didn't. I think we should list features like that, ordered by priority, and then "develop" (read: assume) a library that fits the majority of those needs.
I wouldn't tie it to a web client. I'd just specify a transport protocol that the client and server will use over whatever kind of stream socket you want. In particular, I'd use something like JSON to send structured data packets, rather than this pre-formatted-for-display text we've used since 1990. There is zero point to having the server guess at presentation when it doesn't know what the client environment is like.
So, if you have a classic room, instead of sending the usual formatted thing, you'd send essentially the room data structure (parts of it) and let the client do the work of deciding what gets displayed where, and in many cases how.
I know many of you make the argument for a web client, and in many cases it's because it "removed an entry barrier". Is there really anyone out there in 2014 who isn't used to just clicking "download" to get a game client? If you want to attract the kind of players who will stick around and play your game for months or years, does catering to the ADD crowd that can't take 30 seconds to download and install a client going to help?
It depends whether you mean a custom or customized client, or a generic one that must be configured to work properly. If you have a custom client which auto connects to the mud and has the useful usability features that modern muds need then there's little difference. But I personally find it resist to develop such a client for the web just because html and css are good at that sort of thing.
TBH, I prefer projects that have practical purpose. For example, people collaborating on a modern open-source codebase. You can always turn real code into pseudocode over a weekend :)
In many ways, the choice between Websocket and no Websocket is a false dilemma. Nowadays, adding a Websocket layer is trivial, even for existing MUDs born in the 90's.
I wouldn't tie it to a web client. I'd just specify a transport protocol that the client and server will use over whatever kind of stream socket you want. … I know many of you make the argument for a web client, and in many cases it's because it "removed an entry barrier". Is there really anyone out there in 2014 who isn't used to just clicking "download" to get a game client? If you want to attract the kind of players who will stick around and play your game for months or years, does catering to the ADD crowd that can't take 30 seconds to download and install a client going to help?
I think the point is that if you're sending structured data for key parts of the gameplay, then you've done away with support for generic telnet clients. If you yourself are advocating this move (I know I do), then you have to concede that at that point, a web client becomes very appealing. It is by far less work than any compiled app would be if you wrote it from scratch. And if you don't write from scratch, compare the flexibility of customizing a web UI to the abilities of clients like Mudlet and MUSHClient.
At the end, compare the reach of a new web-based game client with that of a new installable game client. They simply don't compare. A web UI not only has 0 dropout rate at the install step; it can be put on sites like Facebook and Kongregate, made compatible with multiple platforms, updated dynamically with very little hassle.
I agree with you that the server doesn't have to make a choice about the client. But if it does, it can provide a more coherent gameplay experience (as in, a single client ensures that everyone playing the game is on equal footing), and a framework that is easier to maintain (as in, deeper integration between server and client means that server updates may be enough to alter the client flow).
26 Mar, 2014, quixadhal wrote in the 10th comment:
Votes: 0
The problem I have with web based clients is that they also can't know much about your environment. You have to deal with IE vs. Chrome vs. Firefox, and are you running in a window that's in portrait mode or landscape mode. Has the user overridden font choices? Etc, etc…. unless you clamp down and control every single aspect yourself… and then you've done as much work as making a stand-alone client anyways.
I guess if I cared about reaching a fairly broad audience, I'd probably write the client in java. That gets you both stand-alone and web embedded, as well as android with fairly few changes.
And yes, I would write a client that is customized for MY mud, and only MY mud. I'd make the source and specs for my game's JSON packets open, so if somebody else wants to make a better/different client, or adapt it to somebody else's game, they can… but mostly I want to know what the end user's experience is like, and to know that, I have to have some idea what it looks like on their end.
It would be nice to see a collaborative codebase… but the issue usually boils down to langauges. I know I would refuse to work on one coded in C or C++, because I'm done with the whole freeing the mallocs game. I'll reserve that nonsense for writing device drivers, or if someone wants to pay me a decent salary to put up with it. :)
I actually wouldn't mind using C#, as that's next on my list of things to learn. Visual Studio is a much nicer environment than gdb, and it's time I got out of the stone age anyways…. even if that does mean running a server in Windows *shiver*.
@plamzi, I think this project does have practical purpose for the reasons I mentioned – as a learning experience and a learning resource. Quix touched on why pseudocode is a practical choice for it as well – for many reasons people simply won't join a project in a language they don't want to use. Besides, there aremodern open source projects. Evennia, PlainText, Lampost…why not collaborate on one of those? Because the choice of technology is not to your liking :) ? I take your point about being able to convert from a language to pseudocode, however for the purposes of this project I don't think it would work as well, as then we're back to people not joining based on language choice.
Here's my proposal on the communication layer. We punt on the client (we're writing the server first anyway). But I think it makes good sense to make structured data 'native' in the server like quix said. Then we write a telnet adapter which takes our structured data and sends a telnet-compatible version of it. If we have the gumption we can later add telnet protocols (MSDP and GMCP for example) to include structured data in the telnet stream.
Another big choice is genre. Fantasy? SF/Space?
Anyone who would like decision-making power, feel free to add yourself in the article linked in the OP or chime in here.
At the risk of diluting the vote, can I suggest something strange for a theme? Even more rare than space muds would be time travel muds. A neat feature (implemented by lots of hand waving to dodge the complexity of the problem) would be to propagate changes in the past areas to future areas.
I don't know if that would be a great idea for a tutorial MUD, though, since there'd be some unique technical challenges in that domain that wouldn't exist in SF or fantasy. For the sake of a tutorial my vote is fantasy, because it seems more likely to be useful for someone wanting to know what goes into making a MUD, since as a genre it's more popular over all.
@plamzi, I think this project does have practical purpose for the reasons I mentioned – as a learning experience and a learning resource. Quix touched on why pseudocode is a practical choice for it as well – for many reasons people simply won't join a project in a language they don't want to use.
Point taken. But consider for a moment the fact that choosing pseudocode *is* a language choice, and at best only partially mitigates the problem of people being turned off by the language. For example, it's a deal-breaker for me. While I have no doubt that more people here can write in pseudocode than in any other language, that doesn't mean that they would want to invest time and energy into an exercise that will be by definition academic, with (proudly) zero probability of ever being playable.
You can learn just as much, almost certainly more, from writing code that *does* run. While some may have fun writing beautiful pseudocode, to me, the true life (and the true test) of any software begins when it hits an audience. That's when most design flaws become apparent, refactoring enters into the picture, and a whole new kind of learning begins.
The problem I have with web based clients is that they also can't know much about your environment. You have to deal with IE vs. Chrome vs. Firefox, and are you running in a window that's in portrait mode or landscape mode. Has the user overridden font choices? Etc, etc…. unless you clamp down and control every single aspect yourself… and then you've done as much work as making a stand-alone client anyways.
Hmm, sounds like you haven't had any recent experience in web development. Even IE has come a long way, and there are lots of straightforward ways to code a cross-browser game that will work on 80%+ of all web-capable devices.
I guess if I cared about reaching a fairly broad audience, I'd probably write the client in java. … and it's time I got out of the stone age anyways….
You can start by realizing that client-side java is not going to get you a fairly broad audience in 2014. Your time would be much better spent picking up Unity Javascript, e. g.
I'm torn between the two. On the one hand, I agree with plamzi, that this academic exercise is unlikely to produce a quality MUD, because I highly doubt that any current quality MUD sprung fully formed out of its design docs without any playtesting. Never mind verifying that the pseudo code produced actually works in the MUD - how do you know if the MUD will be any fun if you can't play it? This method of design is extremely top down, and not at all representative of how MUDs are actually designed.
On the other hand, as someone in the process of developing a MUD server from scratch, I can attest to the lack of information on how such a thing should be built, and I think it would be a good exercise to list the pieces of a MUD and go over piece by piece how it's designed, why it's designed that way (in order to meet the goals set) and where it fits in the big picture of the MUD. I recognize the absence and need of a tutorial like that and I think that this might be a good way of creating such a tutorial. I'm interested both in contributing the solutions I've used to solve MUD specific development issues, and I'm looking forward to hearing the wisdom of people who have been doing this a lot longer than I have.
As for actually writing pseudocode though… I can see people submitting snippets for sure, but I think that we'll be far from being able to convert all of the pseudocode to, say, Java, and have a working MUD. There's a lot of glue code involved that's required to make a large system like a MUD work, but it's not interesting enough to write out formally, so will probably just be implicit to the design. For example, pseudo code like this:
foreach system in registered_systems { system.process_data() }
is necessary, but vague and useless to someone coming to understand MUD architecture.
@Nich Even a serious, dedicated effort may take some significant effort to produce quality mud, so that point's kind of moot here. How many mud servers (aka codebases) sprung forth from any sort of dedicated design document? I'd bet many were and are subject to the ever-changing "design document" that goes by the name of "mental image of final product in the designer's head".
Quote
On the other hand, as someone in the process of developing a MUD server from scratch, I can attest to the lack of information on how such a thing should be built, and I think it would be a good exercise to list the pieces of a MUD and go over piece by piece how it's designed, why it's designed that way (in order to meet the goals set) and where it fits in the big picture of the MUD. I recognize the absence and need of a tutorial like that and I think that this might be a good way of creating such a tutorial. I'm interested both in contributing the solutions I've used to solve MUD specific development issues, and I'm looking forward to hearing the wisdom of people who have been doing this a lot longer than I have.
Yeah. Although frankly the notion I had when I started has served me well. I started writing a mud server a while ago, some time after I realized that MUs, especially MUCK/MUSH, are essentially a world simulation via database manipulation. Almost everything you do is either a request for stored information or a manipulation of stored information. When you 'look' at something you want description information about a specific object. When you go to a different room, you are just changing data about your location. Once you realize that, then a meaningful way of storing structured data about things is an okay place to start. Then you focus on the actual mechanism of responding to player input and either displaying the data requested or making the changes requested. Eventually you can move on to how to make multiplayer work and whatnot.
A tutorial would be useful, and having something to point people at who make the same insane decision to try and code a mudserver from scratch and then want help to read first and then come back with questions would probably be good.
Any meaningful pseudo code would quickly approach crazy levels of similarity to real code as the difficulty in expressing the concept without code increases. At that point it's just a collaboratively coded server with a really horrendous approach to collaboration. I'd definitely be in favor of discussing the essential components of a mud server and the design aspect of that, although I think a thread per component would make the most sense.
@Nich, I think focusing on a time travel theme might be too niche for this project. However I like the idea and we could incorporate an aspect into the design…perhaps there could be a kind of flashback or history mode where characters could replay some exciting element in the past which would add to their stats/abilities/eq in the present?
@plamzi, pseudocode is not a perfect choice, but this may be a case where the perfect is the enemy of the good. The refactoring issue is, I agree, a bigger flaw in this project, and as Nich said most muds aren't built this way. However we should keep in mind that we don't need to replicate a mud like Bedlam with this project, our product will be much smaller in scope.
For some context I was inspired to start this project by a book I'm in the middle of, Code Complete. It is a dry, C/C++/Java, top-down oriented software construction manual :).
@Tyche, no I didn't, that's an interesting idea. Inform 7 doesn't have any networking facilities, though I suppose we could make it have pseudo networking ;). Gherkin looks interesting, I'm reading up on it now. It seems like it might be too specialized for our needs though?
edit:
Thinking about it, there may be another way to skin this cat. As plamzi mentioned, a codebase could be transcribed to pseudocode. Just out of curiosity, are there forum members interested in this project who would not be interested if we chose a platform, say Javascript/node.js?
I wouldn't be terribly upset if the codebase were in Javascript, but that brings us much closer to actually collaboratively developing a MUD, which, while it would be neat, is a lot more effort than the post originally described. Keeping it in pseudocode makes it nice and theoretical.
Like I said in my last post, there is a lot of uninteresting code that goes into making a MUD, and I guess I'm interested in contributing as long as I'm not tricked into writing any of that code (I have more than my fill of that with my own project). I'm interested in sharing snippets that I've found useful for implementing certain aspects of a MUD, but I have no interest in actually developing another MUD until my own is done.
Based on my experience in trying to get traction for various projects that I thought would be very cool, it seems that the majority of people here are already pretty happy with whatever they're doing. And while they'd gladly stop by to see what you have cooking, getting them onboard with just an idea in hand is hard.
To echo Nich, Pseudocode has a tremendous advantage in that you can skip over all the boring parts if you wish. (Of course, if you do, the final result may not be too educational.) But technically, you can lay out the full groundwork of a MUD in less than a day if you put your mind to it, and you can always "blow up" certain parts later. So, Idealiad, I think if you take a stab at it, you may have easier time finding collaborators. In BusinessSpeak, put some skin in the game.
I didn't mean to suggest that Idealiad was trying to stealthily recruit coders for a personal project. I only mean to say that if that's what this turns into, I won't have time to put in any kind of real effort towards it.
Edit: Here are my votes for this, to move away from the meta stuff:
* what's our theme and setting?
Fantasy hack and slash. This is simply the most ubiquitous example, both of things that people want to make and things that are already made. It also makes a nice jumping point to other genres. H/S gameplay, regardless of how the combat system is implemented, requires a combat system be implemented at all (as opposed to an RP focused mud that might have a strange combat system, a highly lethal combat system, or no combat system)
* what's our gameplay like?
Focus on combat, with the view that social players can more or less take care of themselves. So the game will be basically finding new and exciting monsters to skewer on the end of your sword.
* what are the big technical decisions? Are we using telnet?
The transport format will be considered out of scope, and my vote is for sending structured data over the network and allowing the client to interpret that rather than pre-formatting data on the server side.
What are we doing?
We're writing a mud in this thread. But not the 272nd mud in C, or the 103rd in Python. No, not even a mud in LOLCODE…
We're writing PseudoMUD in, you guessed it, pseudocode. It won't be executable by any runtime (yet) known. But pseudocode will be our common ground, our Rosetta Stone, our yadda yadda you get the picture.
Why are we doing it?
The goal is a complete, unplayable mud. It's part fun forum game (well, at least I think it's fun), part learning experience, and part learning resource. Think of the children!
How do we do it?
We might have to organize later, but for now we'll keep it in one thread.
We're writing a complete mud, so we have to make decisions on code design, game mechanics, content, etcetera. Since making decisions can be hard (TM), here are the rules.
* Anyone can give input.
* You make decisionsif you reply, "I want to be an author of PseudoMUD", or words to that effect.
* All authors will try to reach a consensus on decisions, but if discussion stalls, I'll call a vote.
* Majority rules, I only vote to break ties.
I won't be able to edit this post indefinitely, so I've created an article as a reference.
[link=article]PseudoMUD[/link]
I'll kick this off in the next post!