I don't know how teensymud works. Here's a general idea seen in other codebases and still applicable.

character.race = :race_human

### lookup some data for this player

race_table[character.race].some_data

Same thing can be done for class.


Spells/skills get more interesting, but they're more dependent on your intended implementation. It's common to have a table refering to methods to execute (with symbols and send)

$spell_table = [ ["fireball",      :spell_fireball],
                 ["invisibility",  :spell_invisibility],
                 ["magic missile", :spell_magic_missile] ]

These are both common ways for these to be done.

Is there a codebase with these already implemented? I'm not on a computer right now that I can download to.

I'm not looking to reinvent the wheel, and these examples really helped get a better understanding of what I need to do. It's nice to start off with a framework though.

Thanks for the info.

The name of my current project is StarrMud, my personal endeavor is to use Ruby to do things
that in C would take me forever. Personally I found the socket programming section of RocketMud very helpful.
I have been able to use it more or less as a reference, but as far as framework goes i'm experimenting.

I agree with a generic approach, i mean, i see the point in wanting to have everything blank, but what mud dosn't need
a 'who' command, or (get, drop, wield)? That is unless of course you are making a second-life type of mud where you dont
fight mobs or something like that. Not to get off topic with the thread, but IMO it would be cool if there was a Ruby project that we could all unite on and save ourselves months of "reinventing the wheel", instead of us each creating from scratch how we
think things should be laid out, we could pick and choose which modules to lock in to our independent projects.

eh, just a thought.

Every codebase that wants to be useful to end-users has to eventually make some kind of assumptions about how the world works. If you leave everything wide open, you end up with a codebase that is essentially just a driver and requires a lot of work to construct a game on top of. Of course, there is a difference between making these physics assumptions, and tying them into the core functionality, but still it's very hard to have a "generic game engine" that people can customize with radically different approaches (e.g., room-based vs. coordinates).

It's difficult to team up because people have different schedules, and more importantly different goals. Working with other people means making compromises. Most people want to do their own thing more than they want to go quickly, so what usually ends up happening is that people just do their own thing in their own corner until the codebase becomes big enough where it makes sense to collaborate. It's hard to design something from the ground up when you can't very regularly talk "face-to-face" (even if that means over chat instead of actually in person).

I agree. I intend on my codebase to have a fairly playable game in tact. It's fine for people to want to include general tools. I just usually don't buy the 'don't let people be lazy' argument. There's nothing stopping a release from having a stripped down version as well.

I still think all of those things require content. I'll not argue if it's better to have content or not because to each their own. But it was mentioned that it would be nice to have a "get" command. Well, you are right, it would be great to have that functionality already made but consider what it implies.

1 - Items must be implemented.
2 - Some sort of rooms/coordinates/areas must be implemented.
3 - The ability to "see" your current room and contents.
4 - A way of storing the items on the player (inventory).

Now what is implied by each of those things? A lot, that's what. You end up with a lot of basic systems in order to implement even simple functionality like that, a lot of which is the core "design" of content. You might not include the Sword of Doom, but you will include how items are handled, how they are stored, how rooms are made, how rooms are shown to the players etc.. That's what I am saying. TeensyMud's inclusion of OLC DOES force it to include something along those lines. It has the typical "room" (at least outwardly). Which means an automapping system or an overland system, whatever else you may decide to use has to modified to fit within the realm of what is there, or you have to strip it out.

I disagree that you can just say "to each their own" depending on the goals you have.

What have you implemented if you have a codebase that has no notion of objects, no notion of space, no notion of characters seeing things, and no notion of storing things in other things?

Obviously those all imply many things. But if you have nothing there, well, maybe you don't really have much at all. What value is being added to the person who downloads the codebase? They have a framework, but they have to implement not only game logic but the entire game framework.

Basically, if you do this, you're providing a support library perhaps, but certainly not a MUD codebase.

I don't disagree with developing codebases for general purpose. I just don't disagree with people who want to develop a codebase designed to do particular things well, either. Things that may be making baseless assumptions about the kind of game someone wants to make with it. (Also, empirically those codebases have been most used for learning.)

DavidHaley - A well designed support library is exactly what I want to have! It would be excellent if I could apt-get install mudbase, add in items, races and classes without modifying any code but my own, and fire it up. I bet Teensymuds acceptor/reactor would lend itself to those purposes with some modification.

Basically what you're writing is more of a driver, then, than a codebase. There's nothing wrong with that at all; I just think it's important to make the distinction clear. I completely disagree with the statement that a normal codebase shouldn't build a framework for gameplay; but if you're talking about a driver, that's an entirely different question. A codebase that doesn't provide anything beyond an event framework and network handling will be useless to a very large portion of the MUD community, putting aside the question of whether or not that's a good thing.

This must stem from my misunderstanding of the term "codebase". I always considered it a base on top of which you build a game. In reality it would seem that it is a game with a portion, or all of, the content stripped out. More akin to using the Neverwinter Nights or ElderScrolls editor to build a game on their system than just using something like…Allegro =)

Momma's wrong again.

here's a random thought:
personally i think Tyche's work is great, but i've had a hard time thinking the way he thinks. I think Teensy does things
that not only would i never think of, but in a way that i have a hard time being comfortable with. Now, this may be perceived that
i am just not as savvy with Ruby or as an overall programmer as Tyche, which is of course true. But i think his use of abstraction especially
is just not in anyway natural to me. So, my approach is to develop my own base, so that adding in the game-logic as well as everything else
feels more natural.

I think that is probably the reason that there dont seem to be many projects (i am aware of) that are built off of existing work, everyone wants
their own code base.

(In Ruby anyways. ;P)

This is the ruby forum after all :rolleyes:

Point taken.

I dont mean to be a douche, but you dont make an engine and call it a car do you? Unreal is a game engine, and GoW is a game. NWN is a game, which has an engine. NWN gives you to world to build in on top of the engine yes?

If this is the case, from what you say Chris your looking for the engine not the car. Usually a codebase would be a car, that you modify to your tastes to make it suit you.

Your attempt to not be a douche failed. (j/k!)

Think about what is implied by the term mud code(base). When I hear it, I think "A base of code on which to build a MUD". Using your car analogy, my idea of a codebase would be car with no interior. You have to design and install/implement all of the features you would the vehicle to have. The typical sense(from I've gathered) of a codebase, is a complete car just picked up from the dealer. If you don't like the seats, you have to take them out and put your own in. If you don't like the radio, you have to take it out and put in your own…if it doesn't fit, I guess you need to remold the dash or change your radio design into something that fits. Either way, It's not like I'm going to change the word we use for "mud codebases", nor is it necessary, so I'll go ahead and drop this now :P

But the point I was making is that items, races and classes need coded support, and at the very least would require hooks placed throughout the existing code. If the codebase came with a generic system preinstalled, then those hooks would already be in place, allowing you to easily add in items, races and classes, and minimising your need to modify other parts of the codebase.


I've always viewed it like this: the difference between a mud and a codebase is that the former is a running game, while the latter is publically distributed data. God Wars was a game, but when it shut down and the source code was released, it became a codebase. If it had never shut down, it would be both.

I would refer to a codebase with minimal functionality as a 'barebones codebase', but even that should contain a certain degree of feature support. I know Tyche once said he didn't consider my Gladiator Pits codebase to be a mud because it didn't have any concept of space (no world or movement), and while I don't entirely agree with that I do think you need a minimum amount of functionality to be a (mud) codebase, as opposed to a talker.

Also, as I said before, I differentiate between the game content itself, and the support for that game content. Supporting mechanics for rooms and movement isn't the same as including a stock world. However a codebase can come with any amount of game content included, and while many people frown on providing stock content, it does have its pros as well as its cons.

Even engines like Unreal, Quake, NWN, etc., all have basic assumptions about how the physics work in the world. Classes etc. can be separate but it is quite difficult to have no notion whatsoever of space, or things in space.

I agree with KaVir's statement re: supporting game content and having game content. FWIW, I also think that having a basic example of a game is very helpful as it shows a real application of the engine as opposed to just an abstract potential.