02 Aug, 2012, chacham wrote in the 1st comment:
Votes: 0
I'm toying with the idea of writing my own MUD. This has less to do with anyone ever playing it, and more with my own edification. I'm just interested in writing a MUD server in a database. My idea would be to code it in Oracle, probably with Perl connecting in between the DB and the user.

Now that i have my goal, i have nearly no idea of what to do to code a MUD. I would like to read an article or book on MUD programming that does not use a language for examples, but discusses what needs to be done, such as world and battle ticks, recognizing others users, et cetera,

Is there such a resource? Is this the right forum to ask about it?
02 Aug, 2012, Idealiad wrote in the 2nd comment:
Votes: 0
People have recommended Bartle's book,

http://www.amazon.com/Designing-Virtual-...

And this one,

http://www.amazon.com/Game-Programming-P...

If you're into it it's not a bad idea to go through all the old threads on this forum, Mudlab, Top Mud Sites, and The Mud Connector. Once you get an idea of the topics you want to read about it's easier I've found to Google site search them all.

There's also archives for the mud-dev mailing list and the Imaginary Realities ezine here,

http://disinterest.org/resources.html

There's the mud-dev wiki which has some good protocol information,

http://mud-dev.wikidot.com/

Finally there's just a ton of muds out there. It helps to look at the source code to see how it's organized and what's there. If I were you I'd do that with 10-20 smaller muds. Check Google Code and Github.

Note that there are more pages on that wiki than are immediately obvious, you have to poke around.

Anyway, there's a lot of information out there, not that well organized, but that's to be expected I guess considering how long muds have been around. One thing I'd like to do at some point is put the good stuff into some kind of a mud developer's reference.

You can always ask specific questions here of course, no matter how basic, just fire away :).
02 Aug, 2012, Runter wrote in the 3rd comment:
Votes: 0
Quote
My idea would be to code it in Oracle, probably with Perl connecting in between the DB and the user.


Step away from the ledge
02 Aug, 2012, plamzi wrote in the 4th comment:
Votes: 0
Runter said:
Quote
My idea would be to code it in Oracle, probably with Perl connecting in between the DB and the user.


Step away from the ledge


More specifically, isn't Oracle licensed and expensive? And isn't Perl dated compared to a slew of more modern server scripts? I've written a few Perl scripts in my day and always felt that it's great, up to about 100 lines. For a complex application, it doesn't scale well.
02 Aug, 2012, Runter wrote in the 5th comment:
Votes: 0
I have a few things to say which may help you get on the right path.

First of all, your database technology isn't really important. Or at least has little to do with your game logic, not more than say ram has to with your games logic. So your game is written in the programming language. It's best that your game logic not care about the storage that you use to persist things, and your storage shouldn't care about the game logic. Databases are important particularly because of how important it is to be able to efficiently query for data, but it's just storage. Frankly, I find the detail as uninteresting as what type of hard drive or memory you plan on configuring your production server with. Most of the apps I work on are database agnostic. A lot of people are very interested in database technology, and more power to you if you are, but don't fall into the trap of thinking that's a really important thing. Frankly, whether or not you care for having players.. sqlite3 would work just fine.

Second, I have no comment on perl. If you want to use perl then use it. If you're using it as an opportunity to learn then great.

And last, a good place to start is by making a chat server. It has little state, it broadcasts things to other people connected, but it shares a lot with muds and it's a great place to understand how the input/response logic should work. Once you're comfortable there, start adding features to your chat room that make it more like a game. Have fun with it and it's no work at all.
02 Aug, 2012, chacham wrote in the 6th comment:
Votes: 0
plamzi said:
Runter said:
Quote
My idea would be to code it in Oracle, probably with Perl connecting in between the DB and the user.


Step away from the ledge


More specifically, isn't Oracle licensed and expensive? And isn't Perl dated compared to a slew of more modern server scripts? I've written a few Perl scripts in my day and always felt that it's great, up to about 100 lines. For a complex application, it doesn't scale well.


Oralce XE is free up to 5GB, runs on Linux, and is something i am familiar with. I prefer it over SQL Server and others simply because it allows for PACKAGEs, which are like libraries (session based). It also has over a hundred built-in PACKAGEs doing all sorts of things like fetching webpages and communicating with the underlying OS.

Perl scales extremely well, and for parsing, is of the fastest things out there. It is actively developed, has tens of thousands of custom modules (CPAN) and pretty much set the standard for regular expressions. It is also available on nearly every system. Like any language, Perl has it's own way of doing things (it's credo is "there's more than one way to do it").

And if they're not suited for the job, i'd like to discover that. I might be weird, but i consider that fun. :)
02 Aug, 2012, chacham wrote in the 7th comment:
Votes: 0
Runter said:
It's best that your game logic not care about the storage that you use to persist things, and your storage shouldn't care about the game logic. Databases are important particularly because of how important it is to be able to efficiently query for data, but it's just storage.


Let me be frank. Anyone who says a database is just for storage is obviously a programmer who has no idea what an RDBMS can do. Databases are data management. A MUD, ultimately, is just data management; numbers and other data associated with objects. Indeed, a DB is excellent here, because it handles multiple users of the same data very well, resolving conflicts (who was here first), allowing others to see modified data, and keeping keeping multiple data manipulation statements as one atomic unit.

Considering the data starts (user storage, rooms, mobs, items) and ends in the database (when things change), why leave the database to manipulate that data?

My interest was peaked when i read of a gMUD that used SQL Server for everything. Since then, i have though of doing similar things myself. Admittedly, as a DB coder, databases are my hammer. But i do believe them to be particularly suited for MUDs.

Runter said:
If you're using it as an opportunity to learn then great.


Yep. :)
02 Aug, 2012, chacham wrote in the 8th comment:
Votes: 0
Idealiad said:
People have recommended Bartle's book,


OK, that a whole lotta info. :) I plan to take a look at those a bit later today. As i responded to the other two commenters, i wanted you to know i saw your post and indeed intend to look at those resources.

This is my first post here, and i see these detailed responses to someone requesting how to re-invent the wheel. I'm impressed and just have to thank you all.
02 Aug, 2012, Rarva.Riendf wrote in the 9th comment:
Votes: 0
Quote
Let me be frank. Anyone who says a database is just for storage is obviously a programmer who has no idea what an RDBMS can do.

Or a programmer that knows both and knows that there is absolutely no use of any advanced functionality of a database for a mud.
02 Aug, 2012, chacham wrote in the 10th comment:
Votes: 0
Idealiad said:
People have recommended Bartle's book,
http://www.amazon.com/Designing-Virtual-...


From the comments on Amazon, i am under the impression this helps with design in the mud, not of the server itself. IOW, it would be of use after i have the server down.



The comments here says it's heavy on C++. I would like a discussion of required factors. I guess this would do if there nothing else.

Idealiad said:
If you're into it it's not a bad idea to go through all the old threads on this forum, Mudlab, Top Mud Sites, and The Mud Connector. Once you get an idea of the topics you want to read about it's easier I've found to Google site search them all.


That's a lot of searching. :)


Idealiad said:
You can always ask specific questions here of course, no matter how basic, just fire away :).


I'm trying to get my bearings on an approach, so i can ask intelligent questions. When i brought the idea up to a friend, he asked me how i would do world and battle ticks. So, i'm trying to figure out what needs to be handled in a MUD. That is, if i would have a basic view of events a MUD server must handle (both user-caused and autonomous), i could then create a design that encompasses all that. Or so goes my theory.
03 Aug, 2012, plamzi wrote in the 11th comment:
Votes: 0
Rarva.Riendf said:
Quote
Let me be frank. Anyone who says a database is just for storage is obviously a programmer who has no idea what an RDBMS can do.

Or a programmer that knows both and knows that there is absolutely no use of any advanced functionality of a database for a mud.


Well, I think in this case what you "know" is defined by what you want. Maybe you never wanted your world to be made easily editable in a browser, or to serve real-time location data to a web-based automapper, or to post auto-updating leaderboards easily to a web page, or to let people add quests via a web form, or to leverage stored procedures to turn 100 lines of server code into 10 lines of db code, or to balance your mobs / items easily with a db client, (I could go on…) and to have all these concurrent ways of accessing the same data happen with no conflict.

I think it's also true that what you want is defined by what you have. If you don't have an RDBMS, I'm not surprised that you find it of "absolutely no use".
03 Aug, 2012, KaVir wrote in the 12th comment:
Votes: 0
plamzi said:
I think it's also true that what you want is defined by what you have.

That sounds like some sort of sour grapes argument. In practice it's the other way around - what you have is determined by what you need. Specify your requirements, design the game, implement the features. You shouldn't just randomly add functionality to a mud and then try to find a use for it afterwards.
03 Aug, 2012, Runter wrote in the 13th comment:
Votes: 0
I'm not saying databases are of no use to a mud. I'm saying that I wouldn't approve of highly coupling game logic with your data store. And making use of those advanced features plamzi described can be achieved without doing that.
03 Aug, 2012, plamzi wrote in the 14th comment:
Votes: 0
KaVir said:
plamzi said:
I think it's also true that what you want is defined by what you have.

That sounds like some sort of sour grapes argument. In practice it's the other way around - what you have is determined by what you need. Specify your requirements, design the game, implement the features. You shouldn't just randomly add functionality to a mud and then try to find a use for it afterwards.


In the context of my entire post, I think it's perfectly clear that wanting a specific functionality comes first. But an RDBMS is not a one-trick pony, so once you have it, you will most likely discover that it makes a host of other things easier to do (hence, easier to want to do). That's what happened to me. I'm certainly not the person who implements stuff just to see if they can do it and I've always advised people against such mentality.

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.
03 Aug, 2012, plamzi wrote in the 15th comment:
Votes: 0
Runter said:
I'm not saying databases are of no use to a mud. I'm saying that I wouldn't approve of highly coupling game logic with your data store. And making use of those advanced features plamzi described can be achieved without doing that.


I think the OP makes it clear that he's not looking to write a flexible codebase for MUD games, but his own game. If that's the end goal, what exactly is to be gained from not maximizing the utility of an RDBMS? Are you advising that he spend years reinventing the wheel just so he can boast about being able to switch storage methods? What if the need to switch storage methods never arises?
03 Aug, 2012, Runter wrote in the 16th comment:
Votes: 0
plamzi said:
Runter said:
I'm not saying databases are of no use to a mud. I'm saying that I wouldn't approve of highly coupling game logic with your data store. And making use of those advanced features plamzi described can be achieved without doing that.


I think the OP makes it clear that he's not looking to write a flexible codebase for MUD games, but his own game. If that's the end goal, what exactly is to be gained from not maximizing the utility of an RDBMS? Are you advising that he spend years reinventing the wheel just so he can boast about being able to switch storage methods? What if the need to switch storage methods never arises?


You can maximize the utility of a RDBMS without designing code that uses it poorly. You can do it without spending years, and this doesn't constitute reinventing a wheel. It's more like just actually following a design pattern. And it has nothing to do with being able to switch storage methods, since the decoupling of game logic away from database specific code has nothing to do with that. His scope of interest in doing things the right way doesn't concern the advice I'll give on these forums.

Quote
My idea would be to code it in Oracle, probably with Perl connecting in between the DB and the user.
03 Aug, 2012, plamzi wrote in the 17th comment:
Votes: 0
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.
03 Aug, 2012, Rarva.Riendf wrote in the 18th comment:
Votes: 0
Quote
Maybe you never wanted your world to be made easily editable in a browser, or to serve real-time location data to a web-based automapper, or to post auto-updating leaderboards easily to a web page, or to let people add quests via a web form, or to leverage stored procedures to turn 100 lines of server code into 10 lines of db code, or to balance your mobs / items easily with a db client, (I could go on…) and to have all these concurrent ways of accessing the same data happen with no conflict.

And what exactly uses a perticular database functionality in what you said ? Most of them can perfectly fit your needs. And what exactly is provided by the one you chose that makes tying your hand to it? Abstracting the DB does not mean not using stored procedure, those are supported by many DB and are pretty much standardized. (unless you start using very specific vendor functionality; but then again I really doubt a mud need any of them)
03 Aug, 2012, chacham wrote in the 19th comment:
Votes: 0
plamzi said:
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.


My thoughts are:

1) The data store will be the RDBMS, so the start and end of the data is the database, so why leave it?
2) RDBMS's handle multiple users very well.
3) The UI implements only UI, and not game logic, meaning there are many output formats.
4) I am a DB coder, which means i do not need to learn another language.
5) SPs allows for atomic transactions, making disconnects easier to handle (in my mind).

The reason i choose Oracle is:

1) I generally prefer Oracle.
2) It has PACKAGEs (session-based Libraries)

Ultimately, i just want to see if i can code a mud. This is for fun and edification. My fun is doing it in the DB, which i happen to think is particularly suited for the job.

I also have an idea to implement, that is, the story, and how the characters grow. It's just a file where i keep all my "great MUD ideas".

Anyway, i readily admit that i do not know:

1) how to implement a MUD.
2) if an RDBMS is truly suited for the job
3) if the game i want to implement is playable

Regardless, i just want to have some fun.
03 Aug, 2012, Tyche wrote in the 20th comment:
Votes: 0
chacham said:
Now that i have my goal, i have nearly no idea of what to do to code a MUD. I would like to read an article or book on MUD programming that does not use a language for examples, but discusses what needs to be done, such as world and battle ticks, recognizing others users, et cetera,

Is there such a resource? Is this the right forum to ask about it?


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
0.0/46