Member Discussions

I've decided to write a MUD codebase from scratch. It's been a while since I've played a MUD, as the ones I played shut down some time ago. (World of Pain, and Lyd's Realm)

I just added a basic zone and room structure to it the other day. Before I can do much more I need to have a basic area to test things in. So... OLC... I've been trying to think of an easy way to do OLC. The one time I used OLC on a MUD, it was menu based, which is great, but seems tedious to program. I thought about the OLC being completely command based, which would alleviate that pain, but add alot of commands with specific parameters. Finally there is alway offline building. My Zones and Rooms are saved in XML atm, and I could probley put together a small graphical application to assist in this.

Gah, my thoughts are a bit scrambled atm, but I would like to know everyone elses thoughts on this. How do you like OLC to be implemented? How does your MUD do it? Any ideas on how this can be done cleaner than a state machine with lots of spaghetti code? All thoughts on the matter welcome.

As for my Zones and Rooms. Zones are contained in a global linked list and consist of a number, name, description, keywords, flags, and a linked list of rooms. Rooms consist of a number, name, description, keywords, flags, possible exits, and an inventory. Exits consist of a name, description, keywords, flags, a target zone number, a target room number, and a pointer to the actual target room. Finally, the room inventory is a linked list of 'targets'. (Actually each of the things listed above are derived from targets, aswell as players, items, etc...)

This is how it's done on the codebase
I maintain, Dead Souls:

http://dead-souls.net/example.html

I find menus tedious to maintain and
no more or less useful than command lines.

-Crat

I have an unwavering bias against OLC. It's nice to have commands to tidy up live data, but I prefer to build off-line.

Not to mention OLC has an incredibly stringent license which Ivan follows through on.

It gets to the point where to attacks those who even use the same command names, like redit, medit, etc.

/shrug

-Syn

*It gets to the point where to attacks those who even use the same command names, like redit, medit, etc.*

Er...there are rooms..and mobs...and you edit them. How many possible terms for that can there be?

For Kyrix - I prefer command-based building over OLC but then I have OLC door building issues. As for the offline idea, I have never enjoyed building offline (I need to be in the rooms I am working on) but a lot of builders prefer it. Have you considered implementing whichever system you like best?

Kitkat - built a sandwich today -

Er...there are rooms..and mobs...and you edit them. How many possible terms for that can there be?

I know, go figure.

Darien, over at Mudbytes, is constructing a new building system that sounds pretty amazing, but he can tell you about the travails of not using any OLC verbiage at all.

-Syn

I've never heard Ivan try saying a word about Oasis, though either way Ivan didn't create OLC, he created ONE of the first types of OLC, but not the first, and certainly not the term. In fact Ivan's OLC is also known as OLC2 for a reason.... Either way the friendliest OLC IMO that I have worked with essentially looks like:

Redit:

-- Room number : [57708]        Room zone: [577]
1) Name        : An unfinished room
2) Description :
You are in an unfinished room.
3) Room flags  : NOBITS 
4) Sector type : Inside
5) Exit north  : -1
6) Exit east   : -1
7) Exit south  : -1
8) Exit west   : -1
9) Exit up     : -1
A) Exit down   : -1
B) Extra descriptions menu
S) Script      : Not Set.
W) Copy Room
X) Delete Room
Q) Quit
Enter choice : 

Medit:

-- Mob Number:  [57714]
1) Sex: neutral          2) Keywords: mob unfinished
3) S-Desc: the unfinished mob
4) L-Desc:-
An unfinished mob stands here.
5) D-Desc:-
It looks unfinished.
6) Level:       [   0],  7) Alignment:    [   0]
8) Hitroll:     [   0],  9) Damroll:      [   0]
A) NumDamDice:  [   1],  B) SizeDamDice:  [   1]
C) Num HP Dice: [   1],  D) Size HP Dice: [   1],  E) HP Bonus: [    0]
F) Armor Class: [ 100],  G) Exp:     [        0],  H) Gold:  [       0]
I) Position  : Standing
J) Default   : Standing
K) Attack    : hit
L) NPC Flags : ISNPC 
M) AFF Flags : NOBITS 
S) Script    : Not Set.
W) Copy mob
X) Delete mob
Q) Quit
Enter choice : 

Oedit:

-- Item number : [57790]
1) Keywords : unfinished object
2) S-Desc   : an unfinished object
3) L-Desc   :-
An unfinished object is lying here.
4) A-Desc   :-
Not Set.
5) Type        : UNDEFINED
6) Extra flags : NOBITS 
7) Wear flags  : TAKE 
8) Weight      : 0
9) Cost        : 0
A) Cost/Day    : 0
B) Timer       : 0
C) Values      : 0 0 0 0
D) Applies menu
E) Extra descriptions menu: Set.
M) Min Level   : 0
P) Perm Affects: NOBITS 
S) Script      : Not Set.
W) Copy object
X) Delete object
Q) Quit
Enter choice : 

sedit:

-- Shop Number : [57701]
0) Keeper      : [-1] None
1) Open 1      :    0          2) Close 1     :   28
3) Open 2      :    0          4) Close 2     :    0
5) Sell rate   : 1.00          6) Buy rate    : 1.00
7) Keeper no item : %s Sorry, I don't stock that item.
8) Player no item : %s You don't seem to have that.
9) Keeper no cash : %s I can't afford that!
A) Player no cash : %s You are too poor!
B) Keeper no buy  : %s I don't trade in such items.
C) Buy success    : %s That'll be %d coins, thanks.
D) Sell success   : %s I'll give you %d coins for that.
E) No Trade With  : NOBITS 
F) Shop flags     : NOBITS 
R) Rooms Menu
P) Products Menu
T) Accept Types Menu
W) Copy Shop
Q) Quit
Enter Choice : 

Weird it cut the bottom off:

Addendum: It's incredibly user friendly, though may not be your cup of tea as per your mention of possibly not going with menu-based systems.

I have not heard of this "Ivan" before, although I have used various OLCs on different bases for years. It's possible I've used his in the past, but even so I don't really think he has a case to go after the nomenclature. He's not selling the product and is undergoing no trade with it so he has no case for nomenclature trademarks.

He's also almost certainly not patented the procedure of OLC or the process of deriving text-based commands based on the initial letter of the object being editted. This throws out yet another avenue for him to attack people on.

There is the possibility that he has copyrighted his system with the Copyright Office, and doing so may give him some slight ground for pestering people over the terms, assuming there was no prior use of the terms before his use of the system. If he has not copyrighted it through the copyright office though, the most he's possibly able to receive to my understanding is "damages".

The use of the terms in the Original Poster's OLC would almost certainly not contitute any type of "damages" against this Ivan, and as such his use of the terms oedit, redit, medit, etc shouldn't really even be worried about.

If the facts represented are indeed true, it sounds to me like this Ivan is a blowhard who cares more for attention and recognition than he does protecting his hard work. Hopefully he reads these boards though and would be willing to clear up the issue for us?

There's enough license related FUD going around here as it is. We don't need people jumping at the usage of community standardized terms.


-Once

Not to mention OLC has an incredibly stringent license which Ivan follows through on.

It gets to the point where to attacks those who even use the same command names, like redit, medit, etc.

Ivan's OLC was authored by Hans Birkeland and was a derivative of ILAB OLC authored by Jason Dinkel, which in turn was a derivative of TheIsles OLC which was authored by Herbert Gilliand and Chris Woodward (first publicly released in 1993). It was originally written for Merc and ported to Envy and other Merc derivatives. None have restrictive or stringent licenses, at least no more so than than the Diku codebases themselves that it's been ported to.

OLC is a generic term and was in use in both the Diku and Tiny communities well before TheIsles OLC was released. It wasn't even the first OLC released for Dikumuds, let alone written. Dan Brumeleve of Armageddon released an OLC snippet for DikuMuds in 1992. Other Dikumuds independently developed their own OLC systems as well. There are OLC systems on later Diku derivatives such as Circle's Oasis OLC and Smaug OLC that are also not based on TheIsles OLC.

Locke aka Herbert Gilliand is a crank who asserts all sorts of strange things about OLCs and Diku. He's posted here on TMC under the alias "m_m". My own and others interactions have varied from almost normal discussion to psychotic death threats. My own personal theory is it depends on whether he's taken his medication or not. ;-)

Thanks for the input. I really do like the menu system as far as ease of use, however I think I'll probably go with command based. It's just easier to maintain the code. Besides I wrote a pretty decent parser for a reason, might as well use it.

I was hoping someone had a god-like method of coding menus easily :p. I've thought of a tree-ish based structure that I could create several different menus on, and help with some of the display and navigation coding... but in the end I think it would end up as hard to maintain.

If anyone else has more info, or comments, feel free.

You're probably not using C++, but I am and I use 'Interpreter' classes that have a common prompt interface. Each character has an Interpreter (e.g., an OLC) that knows how to prompt its user. This way I can have either menu-based interpreters or purely command based ones that play nicely with each other. In the case of the menu-based interpreters, which my users seem to prefer, I use a variable to keep track of the sub-state within the class.

It actually sounds to me like your concern about maintainability probably has less to do with menu-based vs. command-based interfaces and more to do with the way objects (and consequently OLC) are usually constructed on muds. Unless you are looking to revisit your approach to what an object / room / mob is, I think you won't really see much difference no matter what you use for building menus.

I was hoping someone had a god-like method of coding menus easily

The State pattern can be used to design Menu systems. A State has entry and exit routines as well as a routine to handle events (input) while in the particular State. One can link States sequentially or push and pop States off a stack to handle nested menus.

What language is your code base in? If it supports relection you can use that to generate your commands/menus, either at runtime or generate code that you can edit. Mine is in C#, so it uses reflection to figure out what properties a certain object exposes. I have a graphical client to edit the areas.

    > Mine is in C#, so it uses reflection

Java supports that as well, but (for obvious reasons), it's not available in C, which is probably the language he's using.

I'd have to second Tyche's suggestion anyway (in its simplest form), as reflection is (in at least the cases I'm familiar with), resource intensive... As a result, I hate to encourage its use even in cases where extra resource usage might be okay, as many people learn from example and repeat coding patterns. Plus, I think using reflection to pull the elements in a menu adds unnecessary complexity for his particular purpose (which I only suggest because he keeps mentioning that he wants to avoid complexity).

Not to begrudge you for being helpful, but I just figured I'd add my comments. *smile*

Best of Luck,
-Jess

(Comment added by mann_jess on Fri Jan 4 23:06:00 2008)

By the way (forgive me for being off-topic for a second), what tag are you guys using for quotations? Blockquote is broken, and quote seems to have disappeared.

I'm actually coding it in BlitzMax.(http://www.blitzbasic.com/Products/_index_.php)

Scarab_XXX> Well I'm actually open to all ideas, as I -think- my code is actually far from traditional.

Tyche> That's what I've been leaning towards so far, if I decide on a menu system.

BM does support reflection, and I've considered it, but I don't fancy using it.

Well, I actually have more time to think on this, because as I was thinking about it, I decided to change the way zones and rooms are handled in the MUD. My current design is built to allow alot of dynamic creation. (I had ideas for wizards/clerics creating temporary areas with spells.) I think I'm going to switch to a grid-type system with 'virtual' rooms for any area that hasn't been explicitly created. That, and I just got parts to finish a single axis motion controller for the cnc break press at work... which pays more (slightly anyway) than mud coding...

Thats a really strange program.

I am confused as to why they chose to make a strange enhancement to BASIC when something like VB, VB.NET, Java, C++ are available and more powerful.

Weird

Well, I use what I like best. I know VB, Java, and C++, but I prefer BMax. Personally I just don't like VB anymore, and I hate pure OO languages like Java. I do love C++ and C, but I get a bit overwhelmed with all the libraries out there and getting them to work together. I also have a bad habit of trying to reinvent everything. BMax has a wealth of libraries easily usable, done decently well, and is -quite- powerful.

So -personally-, I love C++... but I find that I can get things up and running much faster with BMax. Especially when I want to make something cross-platform.

I would like to eventually move to using C++ more often than not... but I need to get together all the libraries I might use. They need to work together, be decently fast to learn, cross-platform, and so on and so forth.

(Comment added by Kyrix on Sat Jan 5 10:44:52 2008)

EDIT: Actually I should mention that I -know- more languages than I can list here... Everything from COBOL to a few different assembly languages, to LUA, to brainf*ck... so I'm not at all a programming n00b ;)