Training

All these practices, and nothing to spend them on, right?  You gain 8 practices a level (if you have max wis), and only spend 2 every level (maybe) to get a new skill or spell.  How about training abilities?  Increase your con/int/wis to get more mana, or increase your str to get more damage; all without having to take up gear slots!

So, how does it work?

I experimented with a couple of ideas.  First was a simple “train” command – added a do_train command, put something in interpreter.c, and called it good.

But I didn’t like that idea.  It doesn’t make sense to walk out into the middle of nowhere and still be able to train your abilities.  So I decided to require players be before a trainer in order to train.  Only certain mobs will be designated trainers, so players will have to seek them out in order to improve their abilities.  This could be either someone in newbie school, or a dedicated trainer somewhere out in the middle of nowhere.

More after the jump

Regen and Bleed

Given that I haven’t updated the blog with fun bits of code in a while, here’s a bit to add to the community: BLEED and REGEN affects.

I’m not going to go too in depth here, if you need help adding AFF_ flags to the stock code, leave a response and I’ll get into it in more detail.  Also, you should know how to add bitvector values to spells (see the Sanctuary spell).

Bleed and regen affects are unlike most other affects, instead of applying every tick (how useful is hp/tick when fights last less than 1 tick), they are applied every round (but only when you’re fighting).

Code after the jump.

Building areas

…is a pain in the arse.

I understand the temptation to go ahead and use stock areas.  But I’m a trooper, I’ll struggle through.  Heck, I’ve already got 3 areas written.  And stock TBA comes with…oh…crap.  Yeah, I’m never going to write hundreds of areas like TBA comes with standard.

It sure would have been nice if I had changed the code so that new areas would be backwards compatible (I didn’t).  Maybe I’ll work on that sometime soon.

As it stands, right now I’m working on making mobs behave more like characters – casting spells, using skills, and generally being more difficult to kill than random bags of hitpoints.

Coding is a lot more fun than building areas.  At least, it’s less repetitive.

Scanning

I haven’t posted for a while, but then again, I haven’t been doing a lot of coding recently.

I am working from TBAMud 3.56, and as you may see from the TBA homepage, the current code is on version 3.61.  I’ve done some fairly extensive changes to the code, and I haven’t been using version control (bad coder, BAD!), so updates aren’t exactly easy.

I was perusing the changelog recently and noticed that version 3.61 (or somewhere around there) had added a “scan” command.  Scan is a fairly ubiquitous mud command, and offers the ability for players to look around in adjacent rooms and see what mobs are there.

I didn’t like the old version, so I decided that I would change it.  Feel free to swipe.

Multi-wielding

Dungeons and Dragons, lets face it, the ultimate source upon which most MUDs are built (it is a Multi User Dungeon after all).  D&D is a bit more limited in what you can do, generally only 1 item per hand.  MUDs traditionally allow more variations, characters can wield a weapon, hold an item, use a light, and wear a shield, miraculously all with only 2 hands!

I had intended to add dual-wielding to my MUD, particularly for Rogues or Warriors.  Giving characters a fifth hand seemed a little silly, in the abstract.  So I figured I would also have to add checks to make sure characters dual-wielding weren’t also using shields or holding items.  With off-hand weapons, I could also add two-handed weapons, possibly giving characters a damage bonus for using weapons in this manner.

Almost all of the code is contained in act.items.c, and is handled under the do_wear, do_grab, and do_wield functions.  As an addendum, you’ll note that a lot of the code refers to character size (GET_SIZE(ch)) or weapon size (GET_OBJ_VAL(obj, 0)).  I’ll discuss the rational behind this later, and give some suggestions as to how to implement it.  But for now, you could easily add a weapon flag (WEAPON_2HAND or (WEAPON_OFFHAND).

Also, you’ll note that I’m checking based on class, as opposed to skill checks to wield offhand items.  The reason is simple: no one is going to waste more than 1 practice on these skills.  So instead, I just limited the options (2hand, offhand, shield) to various classes.

Anyway, code after the jump.

Aggro Part III

Two updates in a single night!  The gods must be crazy.

Or at least the IMMs.

Anyway, as I pointed out last time, calling check_aggressive() in char_to_room() in handler.c turned out to be a bad idea.  In testing, a character would move into a room, get smacked, and then look.  Additionally, certain mob scripts called for a character to be pushed out of a room if he wasn’t welcome.  So the character would move into the room, get smacked, and then get pushed out.  Again, not what I intended.

Solution after the jump.

Aggro Part II

I discussed last time the idea of an aggressive mob function.  The function (at least a bare-bones type) wasn’t difficult to implement, but I ran into a couple of difficulties along the way.

First, one sub-function that is now called in mobact.c (aggressive_mob_on_a_leash()) checks whether the mob is charmed and whether the mob’s master can control it.

Unfortunately, since I put my function (check_aggressive()) in handler.c, and aggressive_mob_on_a_leash is a locally declared function (which I should make a note of to discuss at a later date), I had to do some shifting around.

I initially added a call to check_aggressive() in char_to_room(), but once I implemented the function, I realized that a character would move into a room, get attacked, and then look to see what’s around.

Sub-optimal to be sure.  Code after the jump.

Aggressive mobiles

Most people who have played MUDs are familiar with the AGGRESSIVE type mobile.  These are mobs (NPCs) that are so anti-social that they attack on sight.

The problem is, the AGGRESSIVE flag is only checked every 10 seconds or so (comm.c calls mobile_activity in mobact.c).  To me, this doesn’t sound very aggressive.  A player can walk into a room and out again without the so-called aggressive mob raising his head.  Totally unacceptable.

There are a couple of ways to change this, either increase the frequency of checking, or do the checking in a different way.  I’ll discuss each below the jump.

lvalues, rvalues, and eigenvalues, oh my!

OK, maybe not eigenvalues.

But understanding rvalues & lvalues are important to any understanding of C programming.  Even if this isn’t a C programming blog (I’ve no allusions about my ability to program independent of useful examples), these components are important to understanding how a MUD works.

Traditionally, lvalues and rvalues were defined based on their proximity to the equal sign in an equation, for example in the statement:

x = 7;

x is an lvalue and 7 is an rvalue.  The statement:

7 = x;

wouldn’t make any sense to a C compiler (even if it makes sense algebraically) because 7 can’t be an lvalue (it is not an address).

Orthoganal

There are a ton of blogs out there, as I’m sure everyone is aware, but one of my personal favorites is the Volokh Conspiracy, a blog written by a number of law professors about legal issues, bears, song lyrics, and a variety of political topics.

Recently, in an argument made by the Supreme Court, an advocate used the word “orthogonal” to describe an issue that was independent of or irrelevant to the issue being decided before the court.

I haven’t heard the term used outside of engineering (where it means at a right angle to) or mathematics (where it means independent variables), so while I understood the point being made, it sounded strange to me.  Races and classes (and in my case, Religions) can be thought of as orthogonal issues in a mud, something that helps in understanding how the elements interact.

More after the jump.