19 Apr, 2013, milkmanjack wrote in the 1st comment:
Votes: 0
I've recently been working on a small project in my spare time. As a lover of MUDs, my first project in a language is usually to try and make a MUD. Especially if it's a high-level languages with a gearing towards game development. I don't have as much interest in writing client I/O, but most languages I have an interest in working in have pretty straight forward socket libraries, so I don't have to do much work on that front.

My most recent project is an Lua MUD server, called lama ("mud" in Portuguese).

I initially intended it to be an all-out playable MUD, but once I got everything set up and documented, I figured I'd leave the project as a simple framework for MUDs to be built on, with some simple gameplay elements that can be used if you intend on building on that foundation to make an actual game.

The original release was just a MUD server with a login process, a flat 2D map structure (with objects meant to interact with the map), and a mob you can move around on the map. The most recent release saw the implementation of a hotboot process, which can be used to reload the game while maintaining the server and client connections. It isn't complete, since the game requires character saving for a hotboot to really be complete, but most of the work is done on that front. The hotbooting process is probably not really necessary, and just a kind of neat feature I should have added later… but, you know.

The thing I think is missing right now is a decent Command structure that can be used to make text commands without a lot of hassle, which would be plugged into the CommandParser. Once that's in, I think it'll be as feature complete as a MUD kit can be.

If you'd like to take a look at the MudBytes entry, I threw it in the /Custom folder as "lama". You can also take a look at the github repo, which I will be pushing updates to from time to time.

MudBytes | Github Repository

I'd appreciate suggestions, complaints, and bug reports reported on the MudBytes discussion section, or possibly emailed directly to me. Any way you can get them to me would be great.

Also, hello! This is my first post. Hope this is the right place for this kind of post.
20 Apr, 2013, yue wrote in the 2nd comment:
Votes: 0
milkmanjack said:
The thing I think is missing right now is a decent Command structure that can be used to make text commands without a lot of hassle, which would be plugged into the CommandParser. Once that's in, I think it'll be as feature complete as a MUD kit can be.

That seems like a stretch. Do you have:
  • protocol implementations (telnet, MXP, MSP, MCCP, etc.)

  • database bindings

  • ANSI colour

  • etc.

  • ?
21 Apr, 2013, milkmanjack wrote in the 3rd comment:
Votes: 0
yue said:
milkmanjack said:
The thing I think is missing right now is a decent Command structure that can be used to make text commands without a lot of hassle, which would be plugged into the CommandParser. Once that's in, I think it'll be as feature complete as a MUD kit can be.

That seems like a stretch. Do you have:
  • protocol implementations (telnet, MXP, MSP, MCCP, etc.)

  • database bindings

  • ANSI colour

  • etc.

?


It is quite a stretch actually, when you put it like that. As a MUD server, it really just accepts raw text as input and sends raw text as output. When I say "a complete MUD kit," I just meant that you can pick it up and begin adding game elements with minimal effort. As it stands, there is no support for any particular protocols, and it might just be impossible to support some protocols. For example, MCCP would require an Lua library of some sort that works with LuaSocket for providing zlib streams. I think other protocols like MSDP or MSP that just involve transfer of a few specific bytes + text would be totally doable.

As for the telnet protocol, I am interested in supporting it. My only concern is that there won't be any particular benefits in writing a client that conforms to the specification. I think if I were going to implement MSDP or MCP or one of those, I'd probably end up having to write all-out support for the telnet protocol just because that'd make it easier to add support for them, but none of those things are implemented just yet. If anyone has any good info on the telnet protocol, what I gain by supporting it, and what I lose by not supporting it, I'd like to hear it.

ANSI colour I don't see as being necessary to call it feature complete though I do intend on adding it at some point. It might be safer to replace what I said with: "I think it'll be as feature complete as the MUD kit can be." – because I only intended for this to really handle client and server communication, provide easy points of entry for handling new events like clients logging in, leaving, input, etc…, and eventually, a really nice template for creating commands without too much hassle.
22 Apr, 2013, quixadhal wrote in the 4th comment:
Votes: 0
Are you planning to go the DikuMUD route of having everything coded in the server, or are you planning a mudlib/driver seperation along the lines of NakedMUD, or even an LPMUD?
22 Apr, 2013, milkmanjack wrote in the 5th comment:
Votes: 0
quixadhal said:
Are you planning to go the DikuMUD route of having everything coded in the server, or are you planning a mudlib/driver seperation along the lines of NakedMUD, or even an LPMUD?


I actually had no intention of writing it as a mudlib-type MUD server. My intention was to act more like DikuMUD I suppose, but I don't think anything I've done so far really rules out writing it to work with individual drivers. It's pretty bare bones.

As per the earlier discussion about telnet protocol support, I've written the basic WILL/WONT/DO/DONT... (which do nothing current because nothing is implemented except for TTYPE… which is something). I'm not sure if I'm following the protocol to a T, but I think the basic premise is correct. It finds IAC messages within the text, attempts to follow the negotiations as described, and then removes it from the client's input before letting the command processors get ahold of it. For now I've decided to keep all of the information related to any negotiations entirely centered on the client, and just ask for information when I need it, or send new information through the player's client as it becomes necessary.
0.0/5