03 Aug, 2012, Runter wrote in the 21st comment:
Votes: 0
Quote
I'm not sure what the OP means by "code it in Oracle" but maybe we shouldn't infer from this vague statement that he's about to use an RDBMS poorly.


I take people at their word when they say stuff like this:

The OP hasn't yet shared any specific game design reason for wanting an RDBMS, but that doesn't mean he doesn't have one.
Quote
1) The data store will be the RDBMS, so the start and end of the data is the database, so why leave it?
[…]
4) I am a DB coder, which means i do not need to learn another language.
03 Aug, 2012, plamzi wrote in the 22nd comment:
Votes: 0
Runter said:
Quote
I'm not sure what the OP means by "code it in Oracle" but maybe we shouldn't infer from this vague statement that he's about to use an RDBMS poorly.


I take people at their word when they say stuff like this:

The OP hasn't yet shared any specific game design reason for wanting an RDBMS, but that doesn't mean he doesn't have one.
Quote
1) The data store will be the RDBMS, so the start and end of the data is the database, so why leave it?
[…]
4) I am a DB coder, which means i do not need to learn another language.


I'm not sure why you're quoting these, other than to prove my point that we haven't heard any specific game design reasons yet. The only reason that can be said to have to do with game design is something about concurrency, but not what specific features will take advantage thereof.
03 Aug, 2012, chacham wrote in the 23rd comment:
Votes: 0
Tyche said:
Those who program muds are rarely keen on documenting their design and process.
I suspect the best documentation on coding a mud is often the code itself.
So maybe some Perl examples would be helpful:
PerlMud
Akoya
PerlMOO


Thanx for the links.

In general, i do not learn well from example, but by understanding the entire process. Examples are great for elucidation, but not for explaining. Perhaps it is as you inferred, and i won't be able to find what i want. :(
04 Aug, 2012, Runter wrote in the 24th comment:
Votes: 0
plamzi said:
Runter said:
Quote
I'm not sure what the OP means by "code it in Oracle" but maybe we shouldn't infer from this vague statement that he's about to use an RDBMS poorly.


I take people at their word when they say stuff like this:

The OP hasn't yet shared any specific game design reason for wanting an RDBMS, but that doesn't mean he doesn't have one.
Quote
1) The data store will be the RDBMS, so the start and end of the data is the database, so why leave it?
[…]
4) I am a DB coder, which means i do not need to learn another language.


I'm not sure why you're quoting these, other than to prove my point that we haven't heard any specific game design reasons yet. The only reason that can be said to have to do with game design is something about concurrency, but not what specific features will take advantage thereof.


And I don't know why you don't know why I'm quoting these without repeating everything I just said one more time for you. So It looks like we're at a impasse. Also, I'll follow suit and claim you're proving my point regardless of if that's actually the case or not. "You're proving my point." If that's not enough of a declaration of victory, I can do it again. It's free and glib. Not really useful, is it?

It's easy to argue against stuff like this: "There's not enough information to draw conclusion therefore your conclusion, when stipulating certain parameters, is wrong." But that's nonsense. Argue with the parameters stipulated or decline to argue, but don't claim that with the stipulated parameters that I'm wrong because there's not enough information. Either you can stipulate things and get in a productive discussion, or not, but I have no interest in the latter.
04 Aug, 2012, plamzi wrote in the 25th comment:
Votes: 0
plamzi said:
Runter said:
You can maximize the utility of a RDBMS without designing code that uses it poorly.


I thought your point was not to write code that makes the server dependent on a particular kind of storage method. If in fact your point is that we shouldn't write code that uses an RDBMS poorly, then I'm in complete agreement.

I'm not sure what the OP means by "code it in Oracle" but maybe we shouldn't infer from this vague statement that he's about to use an RDBMS poorly.


Runter said:
It's easy to argue against stuff like this: "There's not enough information to draw conclusion therefore your conclusion, when stipulating certain parameters, is wrong." But that's nonsense. Argue with the parameters stipulated or decline to argue, but don't claim that with the stipulated parameters that I'm wrong because there's not enough information. Either you can stipulate things and get in a productive discussion, or not, but I have no interest in the latter.


Let me break it down for you: I agreed with you based on the speculation you made about the OP intending to implement an RDBS. Hence the English word "agreement". But because it's a speculation, your point is of limited use. It's also too broad a point. We should all not implement anything poorly. Agreed.

I didn't once say you were wrong. It is quite possible that you are right and the OP is about to implement something poorly. But we don't know either way. If you assume based on insufficient information that other people are idiots, then that speaks more about you than about them.

Runter said:
plamzi said:
I take people at their word when they say stuff like this:

The OP hasn't yet shared any specific game design reason for wanting an RDBMS, but that doesn't mean he doesn't have one.

1) The data store will be the RDBMS, so the start and end of the data is the database, so why leave it?
[…]
4) I am a DB coder, which means i do not need to learn another language.


Simply put, I don't think any of these reasons have to do with game design. You can move the discussion forward by showing how they in fact relate to game design. Or you can keep imagining an "impasse".
04 Aug, 2012, Tyche wrote in the 26th comment:
Votes: 0
chacham said:
In general, i do not learn well from example, but by understanding the entire process. Examples are great for elucidation, but not for explaining. Perhaps it is as you inferred, and i won't be able to find what i want. :(

There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves. - Will Rogers

;-)
04 Aug, 2012, Scandum wrote in the 27th comment:
Votes: 0
Tyche said:
Those who program muds are rarely keen on documenting their design and process.
I suspect the best documentation on coding a mud is often the code itself.


For this reason alone I'd suggest that people create a design document first and release it into the public domain. It greatly increases the chance of some sort of finished product, allows for better feedback from the community, and it might be of great use to other developers.
05 Aug, 2012, chacham wrote in the 28th comment:
Votes: 0
Scandum said:
For this reason alone I'd suggest that people create a design document first and release it into the public domain. It greatly increases the chance of some sort of finished product, allows for better feedback from the community, and it might be of great use to other developers.


I would love that.

Hmm… Instead of a design document, i would think just things that need to be handled, required and optional. If a document like that could be agreed upon, a design can follow. In general, there are many designs for any specific idea, so a single design document might be harder to attain.
05 Aug, 2012, Tyche wrote in the 29th comment:
Votes: 0
Scandum said:
For this reason alone I'd suggest that people create a design document first and release it into the public domain. It greatly increases the chance of some sort of finished product, allows for better feedback from the community, and it might be of great use to other developers.


I found a couple of old design documents and put them up, AmalgaMud and SO2403. I don't know that either were ever implemented. I don't believe I've ever seen a finished mud project that was preceded by a published design document. I would think that ex post facto design documents would be far more useful.
06 Aug, 2012, Alathon wrote in the 30th comment:
Votes: 0
Hi there,

I'm currently in the process of trying to slap something together that provides a very easy starting point for creating a MUD. This thread caught my eye, because I'm still
not entirely certain on what to actually include. I've taken a look at stuff like SocketMUD, but I'd like to hear what those of you still around think. Emphasis is on providing
a framework / a set of libraries that can mold into any kind of MUD, but is feature-complete enough to take immediate focus away from some of the more initially-boring aspects of writing a MUD
from scratch. I think I've reached my goal if the developer can sit down and work on MUD content immediately, or almost immediately. Where content could also be how the combat system works, f.ex.

The libraries / framework will be fully documented, and I'll be hosting things on GitHub.

So far, it deals with the following:
- Networking / Sockets (Handled by the language used automatically)
- A robust, fairly extendable command-parser that can handle most syntax, or be altered to do so. Commands can be 'attached' to objects, rooms, etc as well.
- Various methods of easily grabbing input from a client (Such as querying for a number, or an item from a list, or a yes/no question).
- Color escape codes, and the use of f.ex #rred stuff#n to color things when needed.
- Prompts.
- A basic scaffold for MUD rooms, that can either be used in a standard 'rooms are related by N/S/E/W' fashion, or a dynamic list of exits.

This basically provides a 'blank' MUD right now - You can walk around in rooms, execute commands, its multiplayer. There is no combat, no character attributes,
no saving/loading, no editing rooms, etc.

Some things missing that I'd like to look at how to provide a generic way to deal with:
- A simple way to define menu structures and navigating through them, for f.ex allowing the easy creation of a login sequence with character creation.
- A versatile system for spawn points / respawning things.

And some things which aren't necessarily part of the framework, but could serve as demonstrations / utility stuff:
- One or two different ways to save both MUD state and player characters.
- A tool to convert .are files of various formats, and import them into the MUD.
- A standard, boring turn-based combat implementation that shows how it can be done, but is meant more as a demo showcase than something to use.

My question then: What else should I provide? I'll try to plot these things down into a document, if there really is the desire for one.
07 Aug, 2012, chacham wrote in the 31st comment:
Votes: 0
Alathon said:
My question then: What else should I provide? I'll try to plot these things down into a document, if there really is the desire for one.


Sounds interesting. I'm curious how that will go.
07 Aug, 2012, Idealiad wrote in the 32nd comment:
Votes: 0
If you're looking to provide 'a better SocketMUD', I'd look at the 'better SocketMUDs', and…do them better :). So, NakedMUD, Evennia, TinyMUX, PennMUSH is probably a good set to look at.

I think you can make your mud stand out with the packaging. A bundled network appliance/VM sort of thing with a built-in web admin console that someone could instantly deploy to a free AWS or Heroku tier, or a VirtualBox, could be kind of neat.
07 Aug, 2012, Alathon wrote in the 33rd comment:
Votes: 0
Idealiad said:
If you're looking to provide 'a better SocketMUD', I'd look at the 'better SocketMUDs', and…do them better :). So, NakedMUD, Evennia, TinyMUX, PennMUSH is probably a good set to look at.


Thanks, I'll try and take a look at those if I have the time. Between full-time work, full-time Uni and part-time dad, time spent looking at those is time away from features implemented in the framework :)

Idealiad said:
I think you can make your mud stand out with the packaging. A bundled network appliance/VM sort of thing with a built-in web admin console that someone could instantly deploy to a free AWS or Heroku tier, or a VirtualBox, could be kind of neat.


I'm not 100% sure what you mean here - Do you mean supply a VirtualBox image, that runs Linux with everything needed for the MUD set up before-hand, so you can simply fire it up and watch it go?

If so, I think thats a bit beyond what I'd like to supply. The MUD is already very easy to get up and running.

I'll give a go at writing up some initial list of desired features / stuff, and document some circumstances about the framework (Such as the language used, how to run it, why you'd bother with this project as opposed to SocketMUD or one of the others, etc).
08 Aug, 2012, Alathon wrote in the 34th comment:
Votes: 0
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.
08 Aug, 2012, chacham wrote in the 35th comment:
Votes: 0
Nice start.
09 Aug, 2012, Alathon wrote in the 36th comment:
Votes: 0
Is it possible for someone to split off my tangent, so I don't crowd this thread more? I wouldn't mind being able to update a thread as I make progress on JABB, at the same time
I don't want to take over the thread. If not, I guess I can start a new thread.
09 Aug, 2012, Idealiad wrote in the 37th comment:
Votes: 0
I'm not sure if you need a minimum number of posts to do it, but there's a 'Spawn' button in the top right of posts to split threads here.
10 Aug, 2012, Nathan wrote in the 38th comment:
Votes: 0
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.

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.
10 Aug, 2012, Idealiad wrote in the 39th comment:
Votes: 0
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...


That is an awesome thread Nathan, nice link.
10 Aug, 2012, Alathon wrote in the 40th comment:
Votes: 0
Hi Nathan, thanks for the comments. I've spawned off a new thread from here, so I don't bloat this one any longer - With the added benefit of that thread being in a more appropriate forum :)

I'll respond to your post over there.
20.0/46