watch this  

the official mrchucho blog

ChuchoMUD Updated!

Posted 2005 Nov 02

ChuchoMUD has been updated!

One of the (many) outstanding issues with ChuchoMUD was that it was sort of gratuitously passing around entities. Well, this is great except that when the databases dump to YAML, they dump to different files. Thus more than one copy of a given entity would exist. Clearly this was not right.

I solved the problem by storing only “references” to the entities. This is pretty easy because each entity has a unique database ID and its type can be used to determine which database to check. Unfortunately, you get some yucky code like this:

<pre><code>
    def entity
        db = case @entity_type
            when Character.to_s
                $character_db
            when Room.to_s
                $room_db
            when Item.to_s
                $item_db
            when Portal.to_s
                $portal_db
            when Region.to_s
                $region_db
            else
                $stderr.puts("@{entity_type} not found")
                nil
            end
        if @entity_logic!=nil then
            db.get(@entity_id).find_logic(@entity_logic)
        else
            db.get(@entity_id)
        end
    end
 </code>

You might notice two things: one the “types” are getting stored as Strings (another issue with YAML) and there’s special code for “logic” modules. Basically, logic modules aren’t stored in databases, but are associated with an entity. They can, however, operate somewhat independently.

All in all, it works. Though, it “breaks” the previous YAML files. So, if you happened to create an entire MUD in the last few days, I apologize.

As a bonus, though, I added a day/night cycle example and a wandering, talkative NPC. See: I care.

Responses to "ChuchoMUD Updated!"

2005 Nov 22 at 07:32

Can you provide some idea of ChuchoMUD’s architectural vision? Teensymud has that amazing “Smoking hot T&A Action!” post in comp.lang.ruby, which I can read in parallel with the source to get an idea of what’s going on.

A skim through the ChuchoMUD source shows a completely different philosophy than teensymud’s, but… what is it?

This is important because I want to use it (or teensymud) as the back-end of a graphical MUD.

mrchucho

2005 Nov 24 at 03:17

You are correct, ChuchoMUD is very different from Teensymud. The main design goal of ChuchoMUD is to separate the game engine from the game “logic”. That way, any game with any rules in any genre can be created using the ChuchoMUD core.

To this end, ChuchoMUD has a core “engine” that handles things like movement, speech, creating/giving/using items, etc. All of the game rules (or “logic”) are handled by individual “logic modules” that observe and affect the engine’s processes. These modules interoperate through the game engine via Actions. Actions can be triggered by the user (i.e. a Command), by game entities or other logic modules and by timed events.

Another key element is that all attributes of all game entities (characters, items, rooms, etc.) are “dynamic”. In other words, no system is hard-coded into ChuchoMUD. Want Strength and Dexterity? Add those. Want Fuel and Power? Use those instead. It’s all completely possible.

I can post some examples if that would help, though the code has a bunch! I’ve really found it exciting how easy it has been to extend and customize ChuchoMUD.

I’ll post a more recent tarball shortly.

(p.s. It would be very easy to add a GUI to ChuchoMUD—user input would be translated into Actions and the output would be generated by creating a logic module. In fact, that’s what the “TelnetReporter” does now…)

mrchucho

2005 Nov 28 at 14:39

Adding a “duel” capability would be very easy. First, you’d need to add a “duel” command for initiating a duel. Upon starting a duel, you would give everyone in the room ~~- except the duelists -~~ “score” commands.

Next, some sort of “Dueling” logic would need to be applied to each participant. This logic would record the opponent, score, duration, etc. Timers could be used to implement a time limit. Judges could use their “score” command to add points to the score of either duelist.

Managing the participants would be a matter of intercepting players entering and leaving the room. Logic could also be used to create areas in which duels were allowed or forbiddnen.

The real trick would be implementing the “combat” portion. “Spells”, as it were, should be easy: either add a command for each spell or give a “cast” command. The spell effects are just like any other effect (and are very easy to implement).

I’ll try to focus on adding a base combat system soon. I keep going off on tangents implementing ~~easy~~ clever things.

Thanks for your interest!

2005 Nov 26 at 23:55

Thanks for the response! I’ve been trawling through the source code for the last half-hour or so.

I get how ChuchoMud is basically an “engine” for building games upon. It’s like the Mudlib / driver split in LPC muds.

An interesting example (for me) would be a “duel” between two players, where instead of damaging each other with D&D rules, they are scored by “judges” (other players in the room) who assign an arbitrary numeric value to their verbal descriptions of attacks.

When two players initiate a duel, it creates a lot of context. Suddenly, everyone in the room besides the “duelists” has a “score” command available. And the duelists don’t necessarily have hit-points: who’s winning could be a property of the duel itself.

Is it possible to implement something like this against Chuchomud without hacking it up too much? Where would you start?

Thanks.

PS. about adding a GUI; the front-end would actually be in Flash, via an XMLSocket connection, which is essentially a Telnet connection. It would just be a matter of restructuring the TelnetReporter’s output.

Comments are now closed.

atom rss