Extending Saving Throws

Login to reply  Page: « < 1 of 1 > »
29 Dec 2010 - 16:233699
Extending Saving Throws
The existing code supports five saving throw types - SAVING_PARA, SAVING_ROD, SAVING_PETRI, SAVING_BREATH and SAVING_SPELL - basically because much of the underlying game mechanics in Diku was based on (A)D&D. In class.c is the function that returns a saving through value on request:

savingthrows(class_num, type, level);

Where you pass the character's class (as a number), the saving throw type, and the character's level. The function returns the base saving throw value as an integer between 0 (saving throw is godlike) and 100 (I know I'm going to die here...). The only place where this is used in the stock code is the for spell saving throws.

Now, there are probably other situations where it would be nice to "save vs strength" or "save vs dexterity" (I have some of these planning for future enhancements), and to me the simplest way is to extend the number of saving types, and allow the saving_throws function to handle these. However, the way this function is written at the moment is to have three levels of switch statements:

switch (class_num) {
    switch (type) {
        switch (level) {
        }
    }
}

This makes adding additional saving throw types a pain to code. Can anyone see any reason why the order of the switch statements couldn't be altered so that the outermost switch is done on type?


29 Dec 2010 - 18:253700
Extending Saving Throws
Quote Maclir:
This makes adding additional saving throw types a pain to code. Can anyone see any reason why the order of the switch statements couldn't be altered so that the outermost switch is done on type?

I dislike the saving throws anyway, and I also hate lookup tables (of which class.c has a few).
I don't know the 'formula' used to calculate saving throws (there are plenty of D&D lookup tables and stats calculators on the internet, but I can't find an actual formula. If a formula could be found, then it could be coded, which would eradicate those class.c lookup tables...
In answer to your question though, yes, you can swap around the switch commands, but will also need to rearrange the lookup tables a little to make them 'correct'...


__________________
29 Dec 2010 - 18:523701
I agree - those lookup tables for saving throws and THAC0 are the pits.

Right now I'm in the middle of rearranging the select depth order (or how ever you describe that), and moving the innermost set of lookup tables so that the same value is returned, but the code is in the priority of saving throw type, then class, then level.

I'll extent it so there is a
case SAVING_DEXTERITY:
     return (GET_DEX(ch));

Now, only just noticed that the character structure isn't passed to that function. Not a problem, as saving_throws() is only called in one place anyway - I'll just make a wrapper function to it.


30 Dec 2010 - 01:443702
Its amazing to think that someone at some point in time was writing the 1000 lines of code for class.c and never once thought, "hey, maybe there is an easier way to do this?!?"


__________________
Member of the tbaMUD Development Team
30 Dec 2010 - 21:103709
Im in the process of removing saving throws and thaco entirely from the game. Ive always hated thaco and when it comes to varying saving throws, I like the idea of "resist vs frost, vs fire, vs acid...." or the D&D3E style of save vs fortitude/reflex/will, but the AD&D "rod/para/petri/breath/spell" setup is terribad, even if it is industry standard in muds for the last 20 years.

- Im using a fairly simple hitroll check comparing level and a small amount of random_number
- Armor reduces damage by a %
- Dodge and Parry skills give a simple % roll chance to miss
- A stat called 'Absorption' basically functions as magical armor, reducing spell damage by a %
- I use one "saving throw", its for all spells, gets a bonus from WIS, and basically functions like dodge

...at least thats the plan. Still in the process of implementing it all.


30 Dec 2010 - 21:263710
I'm not sure how "standard" D&D or AD&D it was, but when I played back in the 80's, quite often the DM would ask us players to roll an percentile check against strength / int / dex or whatever was appropriate. if we failed a dex check, for example, (and he would have his own hidden modifiers), the character would, for example, slip on the ice / oil / mud.

Made for a fun time.


30 Dec 2010 - 21:493711
I think that concept of rolling vs your str/dex/etc became the foundation for the later reflex / fortitude / will setup. The thing you have to be careful of is the difference between "roll vs" and "roll under" systems. With a roll under system, lets say you roll 1d20, if its under your DEX, you succeed. Well youve now limited your DEX attribute in that it can never be raised higher than 20. Whereas in D&D3E, its a "roll vs" system, where you roll 1d20, add DEX (or a modifier based on DEX), and compare the result to a difficulty. The advantage here is that theoretically the DEX can go up to infinity, as can the difficulty. While it can eventually get ridiculous, Ive found it to be much less limiting as a designer.

GM: "You want to backstab him......with a ballista."
Player: "Yeah huh."

- bonus points if you know the reference :)


01 Jan 2011 - 02:253719
Quote Vatiken:
Its amazing to think that someone at some point in time was writing the 1000 lines of code for class.c and never once thought, "hey, maybe there is an easier way to do this?!?"


I'm not 100% sure, but I think that it's written more complexly to make it execute faster. It *could* have been written more simply, but it would be at the cost of some processing overhead. With the power of the computers we have nowadays it's probably insignificant.


01 Jan 2011 - 05:393720
Quote Axanon:
Quote Vatiken:
Its amazing to think that someone at some point in time was writing the 1000 lines of code for class.c and never once thought, "hey, maybe there is an easier way to do this?!?"


I'm not 100% sure, but I think that it's written more complexly to make it execute faster. It *could* have been written more simply, but it would be at the cost of some processing overhead. With the power of the computers we have nowadays it's probably insignificant.


I find it hard to imagine that the CPU power of running a simple formula was that much of deal even back in the "old days". I remember the topic coming up when it regarded changing the points_update() from every game hour to something more rapid like PULSE_VIOLENCE, which made sense because point_update() searched through every character/npc in the game.

Yay 60 posts...


__________________
Member of the tbaMUD Development Team
01 Jan 2011 - 13:193722
Quote Vatiken:
I find it hard to imagine that the CPU power of running a simple formula was that much of deal even back in the "old days".
Oh yes, it was... I first started coding on a 3MHz processor, and remember that I would 'pause' my program with a simple 'for' loop. Looping just 100 times could pause the program for a second!

These were in the days before MUD, but a few years later, when MUDs ran primarily on huge mainframes, it needed a whole room to contain the computing power that most people have in modern mobile telephones.



__________________

Last edited by Jamdog (01 Jan 2011 - 13:23)
02 Apr 2011 - 06:103966
I believe that they were stored as tables rather than formulas for two reasons:

1) Flexibility - Formulas can be quick and easy, but they can also be limiting, and then you can't change one value without either adding an exception, or not using the formula anymore. If using an array of values (which is what I changed the switches in class.c to) you can change any subset of the values without harming the others.

2) Readability - This might be a stretch, but thinking back to my starting point with MUD coding, I found it much easier to read exhaustive switch statements/if checks than the formulas used in, say, the hit() function.

I'm certain that (1) remains a solid reason, and (2) is a possibility, and was an effective reason nonetheless in my case.

And yes, I know this thread is old, but I was away from these forums for a few months, and the post caught my eye because I've given this a lot of thought as well.


__________________
The Augmented Dimension 2.0
mud.themudhost.net port 5000

The Hidden Grotto
(Currently being patched up from Circle 3.0 to tba3.62)
Old version: a-d.codewarp.org 8229
Progress: http://a-d.codewarp.org/~schlittk/grotto_changelog.txt

Last edited by Kyle (02 Apr 2011 - 06:12)
Login to reply  Page: « < 1 of 1 > »