I've been slow to update recently, since my company is releasing a new version of its software at the end of the week...
But! My next step is to merge struct you with struct monst, or rather, take out redundant data, like location, alignment, intrinsics, etc, etc, etc, etc, etc. I want to treat monsters and the player more equally, though I realize there will be some things that are specific to struct you. the game has a global struct you u, and a global struct monst youmonst, and in some cases, it seems arbitrary which one is used.
On an completely unrelated note, I stumbled across this gem the other day on one of those 'horrors of coding' sites:
static boolean isTrue(boolean b) {
HashMap map = new HashMap();
b = ! !b;
if (!(!(b == !b)) == false) {
map.put(false, !(!(b != !b)));
}
return !map.containsKey(b) & (!true | !false);
}
I believe this is Java code. It may also work in JavaScript but, fortunately, I'm not familiar with JS. It may be the most amazing piece of code I've ever seen, maybe even better than x[strlen(x)] = '\0';.
Wednesday, March 27, 2013
Friday, March 22, 2013
sporkhack
I was inspired by the subject line of a co-worker's email: "+1 Gauntlets of Coding". It was just an email with a link to wrist braces for carpal tunnel syndrome, but I really like the sound of Gauntlets of Coding. I_have a couple ideas: when wearing Gauntlets of Coding, you movement speed will increase only when using the travel command. Or, it gives you jumping. Both are pretty big stretches at puns about using goto statements to either travel faster, or jump through code... yeah... I'll probably make Gauntlets of Coding a compile-time option, defaulting to not include them.
Moving on...
Sporkhack! I've been spending more time playing sporkhack, and I have to say, what a fucking brilliant game. So many changes. From partial resistances, to sacrifice gifts based on XP level, to chaotic Knights, to variable telepathy range, to new items like gold dragon armor, shield of light, Dirge, etc... fucking brilliant.
Where some variants put a lot of effort into nice ncurses interfaces, sporkhack is all about gameplay. I'm seriously considering ditching the slashem source as my code base for my variant and starting with sporkhack instead, since there are just too many features from sporkhack that I like, and most of them are the bag of poo:
I do have two gripes about sporkhack, and they are very, very minor. One, I don't like the new character creation screen. When I start a new nethack game, I know what I want to play as, so I just run: $ nethack -u greg-rog-hum-fem for example, and the game starts. Even if you do that in sporkhack, you still get taken to this screen:
So you have to press "." to start playing. I realize how this starting screen can be helpful to new players, since it lets you know what combinations of role, race, and alignment are allowed, but I guess I'm just old and stubborn and like the vanilla nethack character creation system better. Also, I sometimes run into a bug where, when starting a new game, I get stuck in a corner with no map. I even tried starting as an archaeologist to see if I could dig my way out, but no dice:
Has anyone else run into this? I'm using the sporkhack-svn package from the Arch User Repository, so it's possible that this bug is specific to that code.
...
When it comes to debugging, my strategy revolves entirely around printk (printf if I'm in userland). I don't use gdb because I don't know how. I've always wanted to learn... but it just seems too daunting of an exercise. Sometimes I'll resort to objdump or readelf in a bind, but mostly, I just print out whatever things I'm curious about.
Is there a good way to dump debugging messages in nethack, other than using the pline function? If not, I'll write a patch that will log debug messages to a log file. Then anyone could just call something like nh_trace( LOG_WARNING, "blah blah blah %s, blah %d", ... ) instead of using pline, which interferes with gameplay.
Moving on...
Sporkhack! I've been spending more time playing sporkhack, and I have to say, what a fucking brilliant game. So many changes. From partial resistances, to sacrifice gifts based on XP level, to chaotic Knights, to variable telepathy range, to new items like gold dragon armor, shield of light, Dirge, etc... fucking brilliant.
Where some variants put a lot of effort into nice ncurses interfaces, sporkhack is all about gameplay. I'm seriously considering ditching the slashem source as my code base for my variant and starting with sporkhack instead, since there are just too many features from sporkhack that I like, and most of them are the bag of poo:
I do have two gripes about sporkhack, and they are very, very minor. One, I don't like the new character creation screen. When I start a new nethack game, I know what I want to play as, so I just run: $ nethack -u greg-rog-hum-fem for example, and the game starts. Even if you do that in sporkhack, you still get taken to this screen:
Has anyone else run into this? I'm using the sporkhack-svn package from the Arch User Repository, so it's possible that this bug is specific to that code.
...
When it comes to debugging, my strategy revolves entirely around printk (printf if I'm in userland). I don't use gdb because I don't know how. I've always wanted to learn... but it just seems too daunting of an exercise. Sometimes I'll resort to objdump or readelf in a bind, but mostly, I just print out whatever things I'm curious about.
Is there a good way to dump debugging messages in nethack, other than using the pline function? If not, I'll write a patch that will log debug messages to a log file. Then anyone could just call something like nh_trace( LOG_WARNING, "blah blah blah %s, blah %d", ... ) instead of using pline, which interferes with gameplay.
Tuesday, March 19, 2013
Girl Power!
Who doesn't love numbers? Well, sadly most people, and yet they still remain the best way of measuring things. Go figure.
Special thanks to NetHack 4's maintainer, ais523, for the data.
These numbers do not include games that were started but never finished. The player either had to die, ascend, die, quit, die, escape, die, or be killed. There were 2788 games in total.
First, let's look at starting role vs. max xp level:
Okay, nothing too surprising here. Valkyrie remains a solid choice. Wizard has a tough early game but can become very powerful in the mid and endgame. Tourist did remarkably well, meaning there are quite a few badass NH4 players out there.
One thing I'd really like to point out is that the Monk dominates the early game. Lots of people dump on the monk, I don't know why, because they're not bad. Only drawback, of course, is that they can't wear Gray or Silver Dragon Scale Mail unless at a high enough level to get over the big to-hit penalty.
Role vs. points is pretty similar, no surprise there, so I won't bother with the graph. How about ascensions by role?
Once again Valkyrie, Wizard, and Tourist take the lead! More importantly, I'd like to see role popularity, because that will clearly affect the number of per-role ascensions. (Thanks to the HockeyblogAdventure for pointing out the typo in the below graph title. I'll maybe fix it when I get home from work).
This confirms one of my theories about Barbarians: they're boring to play. Wizards are always interesting, though it's sad to see a lack of love for my favorite role, the Rogue. It also confirms that Valkyries are strong role. They are relatively unpopular (perhaps because they are so strong) yet have the most ascensions.
Also interestingly, people prefer to play Male characters, but Females have more wins. Only ~24% of the players used female characters, but they accounted for ~64% of the ascensions:
I usually play female characters because I figure that if I polymorph into an egg-laying monster, like a dragon or cockatrice, I can make myself lots of awesome pets. On the other hand, if an egg hatches in a male character's inventory, there's a 50% chance of it being tame. On one hand, I don't use the egg-laying trick in most games, but on the other hand, when I do use the trick, I get lots and lots of pets out of it. I'm curious what other peoples' preferences are.
Anyway, this post was just about some fun with numbers. Let me know if there are any other interesting or more complicated stats you want to see. I use the R project for a stats program, and it is superb. Here are the fields with which I have to work:
"points" "deathdnum" "deathlev" "maxlev" "hp"
"maxhp" "deaths" "deathdate" "birthdate" "uid"
"role" "race" "gender" "align" "name"
"charname" "death" "conduct" "turns" "event"
"carried" "starttime" "endtime" "gender0" "align0"
"xplevel" "exp" "mode"
Also let me know if there are questions about what the fields mean. I think the most confusing one might be align0 and gender0 which refer to starting alignment and gender, where as align and gender refer to alignment and gender at the game's end. I don't know what the event field is.
Special thanks to NetHack 4's maintainer, ais523, for the data.
These numbers do not include games that were started but never finished. The player either had to die, ascend, die, quit, die, escape, die, or be killed. There were 2788 games in total.
First, let's look at starting role vs. max xp level:
Okay, nothing too surprising here. Valkyrie remains a solid choice. Wizard has a tough early game but can become very powerful in the mid and endgame. Tourist did remarkably well, meaning there are quite a few badass NH4 players out there.
One thing I'd really like to point out is that the Monk dominates the early game. Lots of people dump on the monk, I don't know why, because they're not bad. Only drawback, of course, is that they can't wear Gray or Silver Dragon Scale Mail unless at a high enough level to get over the big to-hit penalty.
Role vs. points is pretty similar, no surprise there, so I won't bother with the graph. How about ascensions by role?
Once again Valkyrie, Wizard, and Tourist take the lead! More importantly, I'd like to see role popularity, because that will clearly affect the number of per-role ascensions. (Thanks to the HockeyblogAdventure for pointing out the typo in the below graph title. I'll maybe fix it when I get home from work).
Also interestingly, people prefer to play Male characters, but Females have more wins. Only ~24% of the players used female characters, but they accounted for ~64% of the ascensions:
Anyway, this post was just about some fun with numbers. Let me know if there are any other interesting or more complicated stats you want to see. I use the R project for a stats program, and it is superb. Here are the fields with which I have to work:
"points" "deathdnum" "deathlev" "maxlev" "hp"
"maxhp" "deaths" "deathdate" "birthdate" "uid"
"role" "race" "gender" "align" "name"
"charname" "death" "conduct" "turns" "event"
"carried" "starttime" "endtime" "gender0" "align0"
"xplevel" "exp" "mode"
Also let me know if there are questions about what the fields mean. I think the most confusing one might be align0 and gender0 which refer to starting alignment and gender, where as align and gender refer to alignment and gender at the game's end. I don't know what the event field is.
Thursday, March 14, 2013
code restructuring, again
I applied the CK patch my kernel last night to give the Brain Fuck Scheduler and Budget Sector Queue I/O scheduler a try. I'm more interested in the I/O scheduler since disk access is much slower than context switching, though in theory, BFS should give me ~2% better performance... 2%... yay! Also, I know more about storage than CPU architecture, so I have a better idea about what's going on. I gotta say though, I'm impressed with how quickly BFQ hits my external drive.
Moving on...
It's a sad day in Boston. The Pats traded Wes Welker. Everyone's pissed.
Moving on...
I came up with a better way to do code restructuring. First, techniques can stay in their crazy switch block. You can only do one technique at a time anyway, so there's no point in using function pointer madness. However, none should return inside their case, rather, they should just break out instead and a single return will be placed at the end of the function. Each should also specify their own timeouts. Some do, some use the timeout at the end, some don't even have timeouts:
This is true of techniques and magical effects in general. Being effects, all they do is modify data, so they can return void. If it matters whether you succeeded or not, you can always check the condition after it returns. Instead of linked lists for weapon effects, it will just be a dynamically sized array of effects, and I can loop over the switch blocks and apply each effect in turn.
Moving on...
It's a sad day in Boston. The Pats traded Wes Welker. Everyone's pissed.
Moving on...
I came up with a better way to do code restructuring. First, techniques can stay in their crazy switch block. You can only do one technique at a time anyway, so there's no point in using function pointer madness. However, none should return inside their case, rather, they should just break out instead and a single return will be placed at the end of the function. Each should also specify their own timeouts. Some do, some use the timeout at the end, some don't even have timeouts:
This is true of techniques and magical effects in general. Being effects, all they do is modify data, so they can return void. If it matters whether you succeeded or not, you can always check the condition after it returns. Instead of linked lists for weapon effects, it will just be a dynamically sized array of effects, and I can loop over the switch blocks and apply each effect in turn.
Tuesday, March 12, 2013
random thoughts
I haven't had much time lately between a Bruins double header that started last night and heading up to VT to ski last weekend. By the way, don't get stuck in chest deep powder, it fucking sucks.
Anyway, some ideas:
- Weapons dipped in potions of sleep have a chance of putting a non-sleep resistant monster to sleep on a hit.
- Weapons dipped in potions of acid do some acid damage on a hit.
- Weapons dipped in potions of paralyze have a chance of paralyzing a monster for a random, short duration on a hit.
- I'm sure there are some other cases.
- Lenses of Infravision
- Sunglasses (Lenses of Shade?) that would protect against blinding light-based attacks, and maybe give you +1 charisma when worn because they are so cool.
- Artifact lenses that give you some sort of gaze attack when invoked at the cost of some magic power.
- Shields of fire, ice, acid, whatever, from sporkhack, have a chance of doing passive damage to a monster if the monster does not hit you and you get the message that you deflected the attack with your shield.
Soldier role:
Soldiers can reach expert in firearms, saber, and maybe skilled in long sword and a few other weapons. They would start with a pistol, as well as typical soldier gear: low boots, leather gloves, saber, dented pot, leather armor, tin whistle, and a few K or C rations.
I can't think of a good first sacrifice gift. I don't just want to make it a gun because you'll have plenty of opportunities to pick up a gun later. Maybe a magic magazine, base item bag, that generates a random number of bullets when invoked... but then again, you also have plenty of opportunities to pick up bullets throughout the game. Maybe a special gun, a Magnum, base item pistol, that does more damage than a pistol and has a chance of stunning and/or knocking back an opponent like a monk's stunning strike.
The quest artifact would be The Holy Hand Grenade, generated blessed (since it's Holy), and the base item is a stick of dynamite (it's already in the code, not randomly generated though, so you'd need to wish for one). Instead of the long fuse sticks of dynamite have, an armed Holy Hand Grenade would detonate in 3 turns, "One... Two... Three..." or sometimes 5 turns, "One...Two... Five! I mean Three!" Detonation would not destroy the Holy Hand Grenade, i.e., it can be reused, however, monsters can throw it back at you, of course.
The Holy Hand Grenade would grant some intrinsics when carried, but I've yet to figure them out. I thought maybe fire resistance, but then you could just arm it in your inventory and become a suicide bomber...so you'll have to find another source of fire resistance if you want to do that. Maybe extrinsic telepathy and half physical damage, or drain resistance (since it's Holy?), or something along those lines. I'm open to suggestions.
The quest nemesis would be The Killer Rabbit of Caerbanno, base monster would be a rabbit. It would be fast, or maybe very fast. Would have stoning resistance and maybe some other resistances, but not fire. Maybe I'll give him an extra bite attack or two, or a slim chance (5%) of his attack causing instadeath.
Anyway, some ideas:
- Weapons dipped in potions of sleep have a chance of putting a non-sleep resistant monster to sleep on a hit.
- Weapons dipped in potions of acid do some acid damage on a hit.
- Weapons dipped in potions of paralyze have a chance of paralyzing a monster for a random, short duration on a hit.
- I'm sure there are some other cases.
- Lenses of Infravision
- Sunglasses (Lenses of Shade?) that would protect against blinding light-based attacks, and maybe give you +1 charisma when worn because they are so cool.
- Artifact lenses that give you some sort of gaze attack when invoked at the cost of some magic power.
- Shields of fire, ice, acid, whatever, from sporkhack, have a chance of doing passive damage to a monster if the monster does not hit you and you get the message that you deflected the attack with your shield.
Soldier role:
Soldiers can reach expert in firearms, saber, and maybe skilled in long sword and a few other weapons. They would start with a pistol, as well as typical soldier gear: low boots, leather gloves, saber, dented pot, leather armor, tin whistle, and a few K or C rations.
I can't think of a good first sacrifice gift. I don't just want to make it a gun because you'll have plenty of opportunities to pick up a gun later. Maybe a magic magazine, base item bag, that generates a random number of bullets when invoked... but then again, you also have plenty of opportunities to pick up bullets throughout the game. Maybe a special gun, a Magnum, base item pistol, that does more damage than a pistol and has a chance of stunning and/or knocking back an opponent like a monk's stunning strike.
The quest artifact would be The Holy Hand Grenade, generated blessed (since it's Holy), and the base item is a stick of dynamite (it's already in the code, not randomly generated though, so you'd need to wish for one). Instead of the long fuse sticks of dynamite have, an armed Holy Hand Grenade would detonate in 3 turns, "One... Two... Three..." or sometimes 5 turns, "One...Two... Five! I mean Three!" Detonation would not destroy the Holy Hand Grenade, i.e., it can be reused, however, monsters can throw it back at you, of course.
The Holy Hand Grenade would grant some intrinsics when carried, but I've yet to figure them out. I thought maybe fire resistance, but then you could just arm it in your inventory and become a suicide bomber...so you'll have to find another source of fire resistance if you want to do that. Maybe extrinsic telepathy and half physical damage, or drain resistance (since it's Holy?), or something along those lines. I'm open to suggestions.
The quest nemesis would be The Killer Rabbit of Caerbanno, base monster would be a rabbit. It would be fast, or maybe very fast. Would have stoning resistance and maybe some other resistances, but not fire. Maybe I'll give him an extra bite attack or two, or a slim chance (5%) of his attack causing instadeath.
Thursday, March 7, 2013
code restructuring: technique
Before I talk about the restructuring of the technique code, I want to extend a big thank you to Finland, which is the source of the majority of my blog views, per capita (USA wins out in overall quantity). In honor of your Finnish dedication, I will add a new comestible to my variant: lutefisk (please let me know if this is the wrong term in Finland).
My current thought is that it will behave similarly to royal jelly, but when eaten, will give the message: "This tastes like the worst thing you've ever tasted!" I may change the message for the case when confused by a potion of booze, as I once read a guide to eating lutefisk online, and the first step was "get so drunk that you can't taste it."
...
Moving on, I'm almost done with restructuring the technique code. Instead of a long switch statement, I'm using a function pointer for each technique. This will allow for the potential of techniques having more than one effect, as the new tech struct can have a linked list of function pointers, where each function is called in serial.
For example, say we want a technique that deals cold damage and stuns the target monster, and a technique that deals fire damage and stuns the target monster. The two techniques can share the stun code, so the first would have a linked list containing two function pointers, one to fire damage technique code, and one to stun technique code, whereas the second would have a pointer to cold damage technique code and a function pointer to the same stun code as 'fire-stun'.
Why restructure? Part of the reason is because of shit like this:
A closer look:
This unreachable break statement appears all over tech.c. My guess is that someone made the mistake early, when writing tech.c, then copy and pasted the mistake in several more places. It doesn't make the game not function, but it's ugly.
With the new system I'm implementing, there could also be hybrid/random techniques that randomly select from a couple of the technique function pointers (they'd have to be compatible... combining bless and raise zombies doesn't make any sense). These random/hybrid techniques could potentially be granted as sacrifice gifts, which would add an interesting dynamic to sacrificing.
As a next step, I'm going to take on the scroll/potions/spell effects... i.e., the type of stuff that can be broken up pretty easily. Once again, the new structuring will allow for craziness like scrolls/potions/spells with multiple effects, etc, if I, or someone else, decides to add that in the future.
The point of all this is to make the code much more loosely coupled to make expanding and modifying the game easier.
My current thought is that it will behave similarly to royal jelly, but when eaten, will give the message: "This tastes like the worst thing you've ever tasted!" I may change the message for the case when confused by a potion of booze, as I once read a guide to eating lutefisk online, and the first step was "get so drunk that you can't taste it."
...
Moving on, I'm almost done with restructuring the technique code. Instead of a long switch statement, I'm using a function pointer for each technique. This will allow for the potential of techniques having more than one effect, as the new tech struct can have a linked list of function pointers, where each function is called in serial.
For example, say we want a technique that deals cold damage and stuns the target monster, and a technique that deals fire damage and stuns the target monster. The two techniques can share the stun code, so the first would have a linked list containing two function pointers, one to fire damage technique code, and one to stun technique code, whereas the second would have a pointer to cold damage technique code and a function pointer to the same stun code as 'fire-stun'.
Why restructure? Part of the reason is because of shit like this:
A closer look:
This unreachable break statement appears all over tech.c. My guess is that someone made the mistake early, when writing tech.c, then copy and pasted the mistake in several more places. It doesn't make the game not function, but it's ugly.
With the new system I'm implementing, there could also be hybrid/random techniques that randomly select from a couple of the technique function pointers (they'd have to be compatible... combining bless and raise zombies doesn't make any sense). These random/hybrid techniques could potentially be granted as sacrifice gifts, which would add an interesting dynamic to sacrificing.
As a next step, I'm going to take on the scroll/potions/spell effects... i.e., the type of stuff that can be broken up pretty easily. Once again, the new structuring will allow for craziness like scrolls/potions/spells with multiple effects, etc, if I, or someone else, decides to add that in the future.
The point of all this is to make the code much more loosely coupled to make expanding and modifying the game easier.
Monday, March 4, 2013
"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.
...
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.
Saturday, March 2, 2013
more on #twoweapon
I've been thinking more about the topic of two-weapon combat in slashem, specifically, trying to figure out the reasoning behind the scheme in which certain starting races are not allowed to #twoweapon. This pulled me into the nethack code, which also has some quirks regarding two-weaponing.
I use nethackwiki.com all the time (much of it based on the ol' statslab txt spoilers: http://www.statslab.cam.ac.uk/~eva/nethack/spoilerlist.html). Needless to say, it's generally the the best place to go for your spoiler needs. It tells you the 'what', and though it doesn't always tell you the 'why' upfront, it does openly reference the source code for those who want to dig further, which y'all gotta admit, is pretty awesome. This post will go past the level of 'spoiler' down to the inner workings of the code. This post will delve deeply into the 'why'... or rather, try to figure out why the why is why it is.
To start, I have to explain a little bit about the monst struct and attacks. monst.c contains stats (number of attacks, special attacks, resistances, intrinsics, etc) for all of the monsters in the game. Say for example, you are playing as an orcish rogue. In monst.c, we can see that orcs only have one "weapon type" attack:
To briefly describe the structure, every monst has 6 possible attacks, so in the above picture, you can see that the remaining 5 attacks are NO_ATTK, meaning they just don't have any extra attacks. A mind flayer, on the other hand, has 4 tentacle attacks. The first attack is of type AT_WEAP, so the mind flayer can wield a weapon, but the remaining 3 attacks are tentacle attacks, i.e., of type AT_TENT, so the struct looks like:
Nethack has a C pre-processor macro that checks for whether a monster can, or rather, could two-weapon:
In other words, if the monst has a second "weapon type" attack, it may #twoweapon, as seen here:
So why can your orcish rogue wield two weapons at once? Because the game uses the rogue monst struct when doing the two weapon check, and the rogue monst has a second weapon attack, as can be seen on line 3002:
Now, we've all had the awesome idea of playing nethack as a monk and fighting with both hands, and we were all deeply saddened when slapped in the face with a message like this:
Yet, I could've sworn that, when watching Ong-bak, Tony Jaa hit someone with his left fist. So why, in Nethack, are monks restricted? Turns out, the monk monst in monst.c has a second attack, but it's of type AT_KICK:
This will cause two-weapon combat to fail when that could_twoweapon macro above evaluates to 0 since the second attack is not a weapon attack. Furthermore, the monk does not get the kick attack as an encountered monster monk does, because a monster only gets that extra kick in the hitmas function (short for, "hit monster as" a different type of monsters), which is only called if you are polymorphed. So, the only way to play as a monk and have two attacks, though the second one would be a kick, would be to play as a non-monk, then polymorph yourself into a monk. (Actually, now I kind of really want to do this).
I want to make something clear. I do not want this blog to be about bashing the nethack code. I think nethack is the best computer game ever made. Part of the reason I am starting with the slashem code base is because I'd prefer to leave the nethack code as it is, untouched, in it's full glory. I admit, I use the hpmon and menucolors patch, but the game engine itself is untouched.
I do, however, wonder if this behavior, of disallowing two-weaponing for monks, was intentional or a side-effect of the way the game was coded. Obviously, the dev team would've noticed such behavior in testing, so it's possible that this was intentional, though it's also possible that a developer noticed it, checked the code, and said, "meh, that seems fair, I'll leave it that way."
Slashem seems to handle the monst struct differently, and it's the reason that elves can't two weapon, yet drow can, but I'll leave slashem's two-weaponing for another post.
Anyway, to conclude, my proposal is that anything with two arms should be able to #twoweapon. This will involve fundamentally changing the way attacking is handled and monsters are defined, so that will have to wait for a future post as well.
I use nethackwiki.com all the time (much of it based on the ol' statslab txt spoilers: http://www.statslab.cam.ac.uk/~eva/nethack/spoilerlist.html). Needless to say, it's generally the the best place to go for your spoiler needs. It tells you the 'what', and though it doesn't always tell you the 'why' upfront, it does openly reference the source code for those who want to dig further, which y'all gotta admit, is pretty awesome. This post will go past the level of 'spoiler' down to the inner workings of the code. This post will delve deeply into the 'why'... or rather, try to figure out why the why is why it is.
To start, I have to explain a little bit about the monst struct and attacks. monst.c contains stats (number of attacks, special attacks, resistances, intrinsics, etc) for all of the monsters in the game. Say for example, you are playing as an orcish rogue. In monst.c, we can see that orcs only have one "weapon type" attack:
To briefly describe the structure, every monst has 6 possible attacks, so in the above picture, you can see that the remaining 5 attacks are NO_ATTK, meaning they just don't have any extra attacks. A mind flayer, on the other hand, has 4 tentacle attacks. The first attack is of type AT_WEAP, so the mind flayer can wield a weapon, but the remaining 3 attacks are tentacle attacks, i.e., of type AT_TENT, so the struct looks like:
Nethack has a C pre-processor macro that checks for whether a monster can, or rather, could two-weapon:
In other words, if the monst has a second "weapon type" attack, it may #twoweapon, as seen here:
So why can your orcish rogue wield two weapons at once? Because the game uses the rogue monst struct when doing the two weapon check, and the rogue monst has a second weapon attack, as can be seen on line 3002:
Now, we've all had the awesome idea of playing nethack as a monk and fighting with both hands, and we were all deeply saddened when slapped in the face with a message like this:
Yet, I could've sworn that, when watching Ong-bak, Tony Jaa hit someone with his left fist. So why, in Nethack, are monks restricted? Turns out, the monk monst in monst.c has a second attack, but it's of type AT_KICK:
This will cause two-weapon combat to fail when that could_twoweapon macro above evaluates to 0 since the second attack is not a weapon attack. Furthermore, the monk does not get the kick attack as an encountered monster monk does, because a monster only gets that extra kick in the hitmas function (short for, "hit monster as" a different type of monsters), which is only called if you are polymorphed. So, the only way to play as a monk and have two attacks, though the second one would be a kick, would be to play as a non-monk, then polymorph yourself into a monk. (Actually, now I kind of really want to do this).
I want to make something clear. I do not want this blog to be about bashing the nethack code. I think nethack is the best computer game ever made. Part of the reason I am starting with the slashem code base is because I'd prefer to leave the nethack code as it is, untouched, in it's full glory. I admit, I use the hpmon and menucolors patch, but the game engine itself is untouched.
I do, however, wonder if this behavior, of disallowing two-weaponing for monks, was intentional or a side-effect of the way the game was coded. Obviously, the dev team would've noticed such behavior in testing, so it's possible that this was intentional, though it's also possible that a developer noticed it, checked the code, and said, "meh, that seems fair, I'll leave it that way."
Slashem seems to handle the monst struct differently, and it's the reason that elves can't two weapon, yet drow can, but I'll leave slashem's two-weaponing for another post.
Anyway, to conclude, my proposal is that anything with two arms should be able to #twoweapon. This will involve fundamentally changing the way attacking is handled and monsters are defined, so that will have to wait for a future post as well.
Subscribe to:
Posts (Atom)