"oh the beauties of C type declarations"

If you can figure out what I'm referencing in the title, you win a FREE download of the original nethack-3.4.3 source code from www.nethack.org!

...

As I mentioned in a previous post, the psion role is one of the motivations for making a nethack/slashem variant in the first place; the other being, why not?  Basically, the dominate ability will allow a player (or a psion) to willfully control another monster.

When you dominate a monster, you get to control it's moves and actions for, say, 25 turns, plus or minus some random amount.  I realize this can be too powerful in many ways, like walking a tough monster into lava to get rid of it, causing a nymph to drop your precious magicbane, or potentially, having a dominated monster on the astral plane zap a wand of teleport at pestilence to get him away from you.

Anyway, I've had some page views since I shamelessly (shamefully really) plugged my blog on the nethackwiki, so I'm hoping you guys can give me some suggestions.  For example, I can't decide whether to make it a technique or a HIGH level enchant spell.  On one hand, a technique makes sense if I want to restrict it to psions.  On the other hand, do I want to restrict it to psions?  And on the third hand, in implementing the dominate power, I will allow for the possibility of dominating more than one monster at a time.  There is a problem with the third hand though; it will slow down game play... no travel, no run, etc, because you have to control each dominate monster (plus yourself) individually, each step of the way, one step at a time...

Monsters would have a chance to resist, and there'd probably have to be monsters on the no-dominate list--shopkeepers and temple priests, special quest folk--but you'd definitely get a bonus against foocubi.

I've been hacking around the already hacked to death slashem code (I'm very guilty of returning early in functions as a shortcut, but does a function really need 30 return statements?).  I'm pretty close to a functional dominate within the current slashem code, but after going through monmove.c, I decided I need to re-prioritize.

The current game engine cannot support the dominate ability (as I envision it) without gross hacks and workarounds.  Originally I figured I could steal some of the polyself.c code and use gotos in the moveloop in allmain.c; in other words, gross, gross, despicable hacks.

This is about the state it was in when I decided to re-prioritize (the cursor to the northwest is just to show that it's a selection thing.  Nothing new there.  Eventually I'm going to move the cursor over to the kitten):

And then I moved him to the left... or tried.  The kitten is actually one place to the left, but I didn't get the screen drawing/updating working before I temporarily pushed the dominate implementation to the back burner.

Since I plan on restructuring parts of the code anyway, I'm going to do restructuring in parallel with hacking around with new ideas because the current code is too rigid at present for what I want to do with it.

I plan on breaking apart some of the monolithic functions into several more modular functions. The overall goal of the restructuring is to separate the game engine from, well, everything else (items, monsters, roles, races, etc).  I want to keep the interfaces to the game engine as uniform as possible for player and monster alike.  The hope is to make it easier to add new items, monsters, roles, races, and entire systems (bards, music, anyone?) to the game.

Also, a robust interface to monster strategy could pave the way for experimenting with alternative strategies, like monster AI-based strategies, or evolving/adapting strategies.  I will make this a future blog post, because I also have ideas for in-game evolution of both monster strategy and, well, monster creation.  What do you get when you cross a yellow dragon with a silver dragon?  A gold dragon egg.

Anyway, I'm going to start with techniques because that's already a pretty self contained system. Instead of the nearly 1000 line-long switch statement, I'm going to remake the tech struct to contain a function pointer to a function that handles that particular technique's effects.  I figure function-call overhead vs. switch statement efficiency isn't going to make a difference in a turn-based, user-land game.

Besides, who doesn't like to bask in the beauties of C type declarations.