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 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.
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. :(
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.
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.
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.
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".
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
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.
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.
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.
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.
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.
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 :)
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).
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).
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.
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.
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.
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...
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 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.
[…]
4) I am a DB coder, which means i do not need to learn another language.