Procrastination

It’s been a while since I’ve posted, and for a variety of reasons.  One is, of course, the recent holiday, and we went out of town to visit the relatives for a week.  That alone makes it difficult to blog, let alone program on the mud.

Another is that I’ve been putting off several things recently.  The biggest thing I’ve been working on recently is adding damage types to the mud.  This is a corollary issue to implementing religions, mob, types, etc.  Admittedly, “big” is relatively speaking.

Anyway, in adding all of these new features, I had to do some editing to medit.  I originally had the intention of adding a simple for loop (I have 7 damage types) to handle each of the damage resistance types, and I thought it was pretty slick.

Unfortunately, it didn’t work.  In fact, it crashed the mud every time I tried to edit those values.  So…crap.

I knew how to fix the issue (based off of the OBJ_VAL flags in oedit.c), but put it off for a while.  It’s funny how little things – especially one that ended up taking only about an hour to fix, test, and re-fix – are the easiest to put off.

Fortunately, I’m over that minuscule “hurdle” and ready to start some of the more ambitious elements of my overall plan.  Next up is making damage types actually mean something, which will take some doing since I will have to modify the damage() function to include the type of damage sent to the function.

A more ambitious project, yet something I’m more excited about and eager to get done.

Anyway, I’ll be updating in a day or two to say how it’s going.

Religions

I’ve discussed previously how characters can differentiate themselves by class and race in a mud, but both of those characteristics are generally immutable (can’t be changed after it’s set).

But in addition to class and race, it’s my opinion that there should be another way characters can distinguish themselves in the mud, but something that isn’t set in stone (although it need not be easy to change).  One way in doing this is by clans.  The problem with this is that clans are player-controlled, generally either by mortals or by immortals.  There’s nothing wrong with clans being controlled by players, but it’s no basis for adding significant game effects.  Some people may choose not to participate in clans, others may not get invited, and players of certain clans will tend to group with those of their own clan, neglecting other benefits.

One way to get around this is through the use of religions.  Players can choose their religions, religions can be tailored to have different benefits, and players can (relatively) easily switch if they want, without losing too much, socially speaking.

Portals part 5

I finally got around to adding the “portal” spell, which allows players to target a player or NPC and create a 2-way portal.  I’ll include the code below the jump.

My first thoughts in creating the portal spell was to use the spell template for creating objects, MAG_CREATIONS.  However, if you look at the code within MAGIC.C, you’ll find that MAG_CREATIONS really doesn’t give us a whole lot of customizable options.  The function receives, as inputs, the spell level, character casting the spell, and the number of the spell (as defined in SPELLS.H).  No information about a target is passed because the creation spells are intended to just create a static object.

So instead of messing with the MAG_CREATIONS function, I decided to make the portal skill a manual spell, with it’s own ASPELL() function in SPELLS.C.

Swords and Sorcery

I’ve been giving classes some more thought recently.  As discussed previously, I have six classes implemented in the mud, the traditional four plus Paladin (warrior/cleric) and Necromancer (a ‘pet’ class).

I’ve also been working on adding damage type (and corresponding resistances) and that has raised an issue – how to divide up spell damage types so that it makes sense?

More on this process after the jump.

Portals part 4

It seems I was mistaken before.  I had intended to use OBJ_VAL 3 as a timer.  Adding this would require more code to count tics and decrement the timer every round.  Pretty complex.

But when I started testing the code, I realized that there’s already an object that does exactly what I want – player and NPC corpses.  These objects are created, have a countdown timer of some sort, and decay when the timer runs out, exactly what I want!  Of course, spell-made portals may need to have variable timers, but we can handle that pretty easily in the spell function, or more specifically, I don’t want to deal with it now so I won’t.

So lets get on with it.

Portals part 3

OK, this time I mean it, I’ll throw out the code to add to implement this feature.  Keep in mind this is still only for permanent portals, not temporary ones created by a spell, that have a fixed exit set by an immortal using oedit.

I’m also not adding in the ability for immortals to use the SET command to change the target of a portal.  If you want a portal, make one using oedit.  If you just want to move a character, use TRANSFER and/or GOTO.

The fun starts after the jump.

Portals part 2

Well I promised earlier that I’d add an update discussing specific code changes for implementing portals, so I’ll get there shortly.

But before that, I want to briefly discuss VNUMS and RNUMS, because they’re important to understanding how rooms, objects, and mobiles work.

When you create a new room, object, or mob, (herafter “ROM”) you assign to the ROM a unique VNUM.  But that isn’t how the code handles ROMs.  If it were, then there could only be one object for each object VNUM, or one mob for each mob VNUM, or one room for each room VNUM (although rooms are handled differently).

Portals

OK, I think I’ve spent enough time discussing the more esoteric things, I guess it’s time to get down to the nitty gritty.  I’ll post the actual code snippets tomorrow sometime, but for now I’ll go over the general process of thinking to implement a new feature.

First, we start with an idea of what we want to implement.  In this case, it’s a system of portals, a magical way of moving around the mud.  In addition to portals, we’ll later include a system of scrying (remote viewing) and teleporting (reverse summ0n).  Those will be implemented later.  Also, for those who are familiar with the TBAMUD codebase, the teleport skill is already implemented, although it’s a random spell, not targetted.

Crunchy and Fluffy

Crunch and Fluff are generally terms of art in the pencil & paper RPG realm.  They are used less frequently in the MUD context, where things are more often separated into the realms of coding and building.  However, things aren’t always so clear, some coding may be fluffy and some building may be crunchy.

Let me explain.

Crunch generally relates to the structure of the world, how things work, and how players interact with the rules of the world.  Fluff generally relates to the representation of the world itself, areas, plots in the world, and generally things characters interact with.  A coder can add fluff to a mud through special mob programs (in TBAMUD with the SPEC flag), such as the mayor action in specprocs.c.  Alternatively, builders add ‘crunch’ by adding equipment, adding quests (with TRIGEDIT) and other objects that players can interact with.  For roleplaying games, consider most D&D supplements, which are almost all crunch and little fluff.  In contrast, consider WoD books, which are almost all fluff, but no crunch.

Players like fluff in addition to crunch.  A mud that doesn’t innovate is going to lose players.  Likewise, MUDs need to offer something new to players to attract them to the game in the first place.