09 Aug, 2012, Alathon wrote in the 1st comment:
Votes: 0
Alathon said:
I went ahead and started up a document that'll get filled with more stuff as I go. If you have suggestions for obvious features I'm missing, feel free to poke me about it(Such as, I notice I'm missing a feature on helpfiles of some kind).

Document is available at this link.

The MUD itself is currently on GitHub here, but doesn't yet contain instructions on how to run it ;) Not that theres
much to see yet, except 2 rooms, colors and movement.


Spawning this off here so I don't de-rail the original post any more. JABB is a barebones MUD project I've started (very) recently; source is up on GitHub, and contrary
to the quoted text, it now has installation instructions and such (See the document). I really wanted to provide something that was much more accessible than a lot of
other stuff, and that had a fresh perspective on things. I think theres a lot of untapped potential in MUDs. I'll host up a copy of a MUD using JABB as a base, so people
can check it out if they're interested about whats implemented thus far.

If you do decide to give JABB a try, and need help on anything related to it, I'm around at: martin at itsolveonline dot net .
10 Aug, 2012, Alathon wrote in the 2nd comment:
Votes: 0
Nathan said:
I think it helps to have the intention of world creation when you're writing a codebase, since otherwise you end up implementing things in a haphazard fashion. It helps to know what you want and what isn't important to you. Especially since I've been writing a mud server in Java in my free times across several years now. It has all kinds of problems, especially the kind where things are interrelated and both must be modified to change things up.


In this case, what I want to create is (more-or-less) pretty clear in my head; I've attempted to write most of it down in the google document. I'm trying to stay as game-agnostic as possible, only implementing features I find will be useful for most MUDs, or that are
easy enough to change that it isn't a real time-sink to do. As an example, it is relatively trivial to change rooms to have a dynamic list of exits, instead of N/S/E/W.

Nathan said:
There is a really useful set of questions to help one figure out what kind of mud server you're trying to write, and what you want. It was written up by the guy who coded MUSHclient (Nick Gammon): http://www.gammon.com.au/forum/bbshowpos...

@Alathon By all means, write it down. If nothing else, it'd be an interesting read. I could use some insight on the matter occasionally, especially character creation. I've got some Java code that covers some of the same stuff your does. What language are you writing your code in?
* just saw your next comment, I'll have to see this doc your writing.


Thats a pretty neat thread, for sure :) I'll have to read it through.

In general, the Google document on JABB tries to do a few different things:
- Explain the intention of JABB
- Provide installation and run guidelines for JABB
- Provide some fairly easy documentation on the structure of JABB, and a (limited) introduction to BYOND and the DM language.

Its not anything near a complete document, and its not a fully fleshed out design spec. Because I can implement some of these things faster
than I can write the feature spec in a more detailed manner, I'll both be designing stuff before I write it, and vice versa, depending on the scale.

My choice to go with DM falls on it being very, very fast to write stuff in; as well as more than powerful enough to run any sort of MUD I can think of.
As an example, the JABB MUD, the command parser and the input library it uses, have taken under a week to get up and running so far. Within another week,
I can probably have character saving/loading, area saving/loading, some sort of spawning system, character attributes and equipment done - From scratch,
without a preconcieved notion of exactly how and what I want to implement. Of course, now that I've said that, a meteor is probably going to drop on my head.

Its going to be interesting to see if anyone is willing to give it a shot; MUD programmers aren't exactly renown for their affinity for adopting new / different ways of doing things,
although I remain optimistic :)
11 Aug, 2012, Nathan wrote in the 3rd comment:
Votes: 0
Alathon said:


My choice to go with DM falls on it being very, very fast to write stuff in; as well as more than powerful enough to run any sort of MUD I can think of. As an example, the JABB MUD, the command parser and the input library it uses, have taken under a week to get up and running so far. Within another week, I can probably have character saving/loading, area saving/loading, some sort of spawning system, character attributes and equipment done - From scratch, without a preconcieved notion of exactly how and what I want to implement. Of course, now that I've said that, a meteor is probably going to drop on my head.



Hmm… So are you going to do something graphical or are you just using this because you know it?

My command parser, if I dare call it that, is a set of if/else loops. I added a single command queue at one point so I could just stack stuff in it and wait for it to get handled. In any case i have experimented with having command objects in a hashmap by the command name and moving the code from my cmd_<whatever>(…) functions to the objects so I can just ask the hashmap for the command and then pass it the client and the arguments, but that doesn't always work well because I have stuff that relies on access to things that maybe it shouldn't have direct access too (I try to weed that out, but it's easier to write code that way). That code tends to break if I move it into it's own object. That and I still have to call my send(…) method to chuck stuff at the client. I kinda wish I could figure out classloading so I could just add new commands on the fly, so long as they didn't require any new functionality to exist.

In any case either that language is easy or you're doing pretty well to have that much working in a week (unless you actually have copious free time…).

What I meant by my comments earlier was that how you expect the world and interactions with it to behave helps to shape what commands you need and how much functionality there needs to be. You can implement all kinds of things without, but a unified vision of the finished product is helpful. That thread I posted a link to illustrates the diversity of things there are to consider when creating a server.
11 Aug, 2012, Alathon wrote in the 4th comment:
Votes: 0
Nathan said:
Hmm… So are you going to do something graphical or are you just using this because you know it?


I'm not going to do something graphical, no. I'm using it because I believe its a really strong language for building MUDs.

Nathan said:
My command parser, if I dare call it that, is a set of if/else loops. I added a single command queue at one point so I could just stack stuff in it and wait for it to get handled. In any case i have experimented with having command objects in a hashmap by the command name and moving the code from my cmd_<whatever>(…) functions to the objects so I can just ask the hashmap for the command and then pass it the client and the arguments, but that doesn't always work well because I have stuff that relies on access to things that maybe it shouldn't have direct access too (I try to weed that out, but it's easier to write code that way). That code tends to break if I move it into it's own object. That and I still have to call my send(…) method to chuck stuff at the client. I kinda wish I could figure out classloading so I could just add new commands on the fly, so long as they didn't require any new functionality to exist.


In JABB, commands are only responsible for two things: Letting the parser know how it wants its input (The 'format' of the command), and then executing the command once its been given the correct arguments.

The format of a command is parsed when it is created, and turned into an ordered list of components. Each component will usually signify a single word to match, based on the type of the component. Beyond knowing whether a given user input matches the component or not, it is also responsible for translating the matched text into what the user meant. If you type in 'tell Alathon hi there', what you typed is a String. But what you mean by Alathon is the player Alathon. The format of the tell command in JABB is "tell; ~search(mob@players); any" which creates a 'literal' component only matching the word tell, a 'search' component which matches the full or partial name of a /mob object in 'players', and an 'any' component which will consume the rest of the text. The execution of the command looks like so: command(mob/user, mob/target, text) - The tell commands execution doesn't have to care anything about where its input comes from, it just knows that its correct according to the format set.

Its also possible to add an arbitrary number of new custom component types, that work however you'd like. In case you f.ex want to add a URL component that matches correct URLs only, or (for some reason) an inverse component that extends the search component by reversing user input before it is considered (Thus forcing you to type 'nohtala' to match 'alathon'). Or whatever else wonky situations you can come up with ;)

Nathan said:
In any case either that language is easy or you're doing pretty well to have that much working in a week (unless you actually have copious free time…).


I have 80-90 hour workweeks at the moment, so time isn't something I have much of :) Familiarity with the language certainly helps, but beyond that its the way the language is constructed that allows it. Its easy to pick up certainly, but its also fairly powerful in the context of a text MUD, where 'all' we have to do is send and receive text.
0.0/4