Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old September 18, 2012, 06:11   #11
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,976
Derakon is on a distinguished road
Quote:
Originally Posted by fizzix View Post
I think a hierarchical dependency tree makes sense. Device skill can depend on INT, but INT cannot depend on device skill. The other option is to hard code a way return if the bonus is less than one. Then provided the bonuses decrease with each call you will exit the loop eventually. I much prefer the first approach.

Basically you have the very top level stuff which are the stats. They get derived from XP, racial bonus, class bonus, equipment, effects. On the second level you have the derived stats. These are stuff like prowess, finesse (or just melee), stealth, magic device skill etc. These can depend on all the stuff that the stats depend on, but also on stats. However, stats cannot depend on each other or on any of the derived stats.
I have to say I don't much like the idea of having a hardcoded hierarchy of stats and saying "this stat cannot depend on this other stat", if only because it assumes an awful lot about what is more "integral" than what.

However, it occurs to me that there's a natural hierarchy to the modifiers of stats:

Base > innate > derived > permanent effect > temporary effect

In other words, a base stat ("base modifier") is clearly more fundamental than a modifier that is derived from base stats, while a permanent effect (e.g. from equipping a Ring of Strength) is more fundamental than a temporary one. So what we can do then is to ascribe a tier to each kind of modifier, and only allow modifiers of a strictly lesser tier to be used when calculating that modifier.

For example, say we have a weapon with a modifier that gives a 20% bonus to STR. The character has a base 12 STR (internal score), an innate +3 to that bonus (half-orc or something), and has no derived bonus. The weapon's modifier counts as a "permanent effect", so nothing besides these values can be considered. Thus the weapon gives +3 STR (20% of 15).

If the character had another item that also gave a 20% bonus to STR, then that item would also give a +3 STR bonus, since none of the values it cares about has been affected by this weapon.

I believe this approach should eliminate the possibility of loops while still allowing a good deal of flexibility. The only tricky bit is determining what tier a modifier should get. The above hierarchy works well for determining player stats, but we'll need a subtly different system for determining mods on items (since we need to be able to differentiate between the modifiers on the item itself, which count as "innate" tier, from external permanent modifiers, which count as "permanent" tier). Still I think that ought to fall out without too much difficulty.
Derakon is offline   Reply With Quote
Old September 18, 2012, 12:15   #12
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by Derakon View Post
I have to say I don't much like the idea of having a hardcoded hierarchy of stats and saying "this stat cannot depend on this other stat", if only because it assumes an awful lot about what is more "integral" than what.

However, it occurs to me that there's a natural hierarchy to the modifiers of stats:

Base > innate > derived > permanent effect > temporary effect

In other words, a base stat ("base modifier") is clearly more fundamental than a modifier that is derived from base stats, while a permanent effect (e.g. from equipping a Ring of Strength) is more fundamental than a temporary one. So what we can do then is to ascribe a tier to each kind of modifier, and only allow modifiers of a strictly lesser tier to be used when calculating that modifier.

For example, say we have a weapon with a modifier that gives a 20% bonus to STR. The character has a base 12 STR (internal score), an innate +3 to that bonus (half-orc or something), and has no derived bonus. The weapon's modifier counts as a "permanent effect", so nothing besides these values can be considered. Thus the weapon gives +3 STR (20% of 15).

If the character had another item that also gave a 20% bonus to STR, then that item would also give a +3 STR bonus, since none of the values it cares about has been affected by this weapon.

I believe this approach should eliminate the possibility of loops while still allowing a good deal of flexibility. The only tricky bit is determining what tier a modifier should get. The above hierarchy works well for determining player stats, but we'll need a subtly different system for determining mods on items (since we need to be able to differentiate between the modifiers on the item itself, which count as "innate" tier, from external permanent modifiers, which count as "permanent" tier). Still I think that ought to fall out without too much difficulty.
This looks fine with me - I don't think it will be too hard to differentiate innate from permanent. I think this solves both the percentage problem and the circular dependency problem. I don't think recalculating stats is going to be at all problematic - the only time anyone will notice is when the stats generator starts doing stats on combat, simulating thousands of combats ... and that's quite a long way away.

So, looking good - once I can get noz to explain OO coding to me, I'll get cracking!
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old September 19, 2012, 05:12   #13
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,367
AnonymousHero is on a distinguished road
Quote:
Originally Posted by Derakon View Post
So what defines a character, then? To over-reduce, characters are collections of summations of numbers.
Slightly more generally a character is a monoid formed by a binary associative operator on sets of modifiers (+stealth, combat bonuses, +INT, -DEX, XP drain, etc.). Everything follows from that.

In my theorycrafting I haven't found anything as of yet which is 1) meaningful as a character mechanic, and 2) cannot be accomodated in the above general model.
AnonymousHero is offline   Reply With Quote
Old September 23, 2012, 05:32   #14
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,976
Derakon is on a distinguished road
That was surprisingly painless. I suppose it helps that only two stats were currently being used by the engine (max HP and speed). All Creatures now have a "stats" field which contains all of their mutable stats except for current HP (I thought about it and couldn't come up with a scenario in which temporary modifiers to current HP couldn't be accomplished some better way).

Note that this doesn't mean I've added support for any player stats; they're still just the monster standards. Stuff like awareness, absorption, evasion, etc. I'm arbitrarily deciding that native depth, rarity, and experience reward are "fundamental" and it doesn't make sense to stick them into the Stats container. I'm open to arguments though. I mean, if you wanted to make summoned monsters be worth 0 experience, then you could stick a permanent StatMod on them that multiplied their stat reward by 0, but again, that's not the only way you could do that...

I pruned the list of stat types down to "inherent", "permanent", and "temporary". I was having trouble distinguishing between fundamental and inherent stats anyway, and figuring out how the program would decide where a fundamental stat is defined vs. where its inherent modifiers should up was simply not worth the effort.

I also implemented Potions of Speed, and they work quite nicely. You can implement any temporary stat modifier you like without having to touch the code at all since there's now a generic "apply temporary stat mod" proc you can use.

Implementing this proc required me to implement some kind of timer, which in turn meant making a new updateable Thing (since the timer passes some number of normal-speed turns), which lead me to realize that I wanted to change how updateable Things are handled. Currently any Thing that wants to be updateable has to manually provide several attributes -- it must have a stats object that has a 'speed' stat; it must have an energy value; it must have a name (for sorting when two entities have the same speed); it must have a getStat() method (to retrieve the speed stat)...all of this is practically irrelevant to most entities; they just want their update() methods to be called.

Now, I could avoid having to re-do this by having "Updateable" be a descendant of Thing, which both Creature and Timer would then descend from in turn. But you start running into problems pretty quickly there if you have several different kinds of capabilities that you want Things to have -- the inheritance trees would get ridiculous pretty quickly, and multiple inheritance is generally a Bad Thing. So instead, you add the updateable "capability" to an entity via mixins. You can think of mixins as inheriting just the functionality you want -- a mixin is an "incomplete class" that can't stand on its own.

So in this case, the Updateable class has update() and addEnergy() methods, and its constructor ensures that the instance has the appropriate fields to use those methods properly, but it doesn't do anything else.

Later on, I may decide that e.g. the ability to carry, equip, and drop items should be a mixin, in which case the "inventory", "equipment", pickupItem(), dropItem(), etc. attributes of the Creature class will be moved out to a new mixin class. This could be useful for e.g. containers (as Item Things that can "pick up" and "drop" other items) or for socketable items (Items that can "equip" other items).

Anyway, this all is on the repo now. Hooray progress!
Derakon is offline   Reply With Quote
Old September 24, 2012, 02:16   #15
ekolis
Knight
 
ekolis's Avatar
 
Join Date: Apr 2007
Location: Cincinnati, OH, USA
Age: 36
Posts: 911
ekolis is on a distinguished road
Send a message via AIM to ekolis Send a message via MSN to ekolis Send a message via Yahoo to ekolis
Quote:
Originally Posted by Derakon
I mean, if you wanted to make summoned monsters be worth 0 experience, then you could stick a permanent StatMod on them that multiplied their stat reward by 0, but again, that's not the only way you could do that...
What kind of operations can a StatMod do? Just addition and multiplication? Or is it more of an "arbitrary function" sort of thing with an input and an output?

Quote:
it must have a name (for sorting when two entities have the same speed)
So if you have two entities with the same speed, the one that's first alphabetically gets to go first? That just seems... wrong... Maybe just pick one at random instead?

Quote:
You can think of mixins as inheriting just the functionality you want -- a mixin is an "incomplete class" that can't stand on its own.
I've heard of mixins before - I thought they were more along the lines of mixing code in several different languages to accomplish a task, though? What you describe sounds more like interfaces in C# and Java, except that (perhaps) you can combine two or more mixins to get the full functionality of a class, without actually having to inherit from said class in whatever is implementing the mixins...
__________________
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!
ekolis is offline   Reply With Quote
Old September 24, 2012, 03:31   #16
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,976
Derakon is on a distinguished road
Quote:
Originally Posted by ekolis View Post
What kind of operations can a StatMod do? Just addition and multiplication? Or is it more of an "arbitrary function" sort of thing with an input and an output?
They have built-in support for addition and multiplication, and they can also link to an arbitrary function. The results of all these operations are added together to get the overall modifier.

Quote:
So if you have two entities with the same speed, the one that's first alphabetically gets to go first? That just seems... wrong... Maybe just pick one at random instead?
Not just the same speed but also the same energy. So long as you generate monsters with random energy (could be between -1 and 0 if you want to ensure the player goes first) name should practically never be a problem.

Quote:
I've heard of mixins before - I thought they were more along the lines of mixing code in several different languages to accomplish a task, though? What you describe sounds more like interfaces in C# and Java, except that (perhaps) you can combine two or more mixins to get the full functionality of a class, without actually having to inherit from said class in whatever is implementing the mixins...
Nope, what you heard is wrong.

Mixins are similar to interfaces in a way, though. Interfaces say "Inherit from me and you are required to implement these functions." Mixins say "Inherit from me and you automatically implement these functions."
Derakon is offline   Reply With Quote
Old September 24, 2012, 09:21   #17
ekolis
Knight
 
ekolis's Avatar
 
Join Date: Apr 2007
Location: Cincinnati, OH, USA
Age: 36
Posts: 911
ekolis is on a distinguished road
Send a message via AIM to ekolis Send a message via MSN to ekolis Send a message via Yahoo to ekolis
Hmm, "added together"? Do you mean literally added, or just applied sequentially? What about order of operations?
__________________
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!
ekolis is offline   Reply With Quote
Old September 24, 2012, 16:21   #18
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,976
Derakon is on a distinguished road
Literally added together, so order of operations isn't an issue.

Did you read the earlier post on enforcing a tier system to stat mods? Every tier of modifiers is only allowed to take into account prior mods if they have a strictly lower tier, thus there's no issue of circular dependencies or concern about ordering.
Derakon is offline   Reply With Quote
Old September 24, 2012, 16:48   #19
ekolis
Knight
 
ekolis's Avatar
 
Join Date: Apr 2007
Location: Cincinnati, OH, USA
Age: 36
Posts: 911
ekolis is on a distinguished road
Send a message via AIM to ekolis Send a message via MSN to ekolis Send a message via Yahoo to ekolis
Added a couple mini-patches to the patch queue - one of them (finally) fixes the message window sizing issue, while the other just adds a batch file that's useful for testing on Windows!

Are you notified of new patches added to the patch queue? I'm getting a bit annoyed with Bitbucket lately at all the missing/broken features...
__________________
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!
ekolis is offline   Reply With Quote
Old September 24, 2012, 16:50   #20
ekolis
Knight
 
ekolis's Avatar
 
Join Date: Apr 2007
Location: Cincinnati, OH, USA
Age: 36
Posts: 911
ekolis is on a distinguished road
Send a message via AIM to ekolis Send a message via MSN to ekolis Send a message via Yahoo to ekolis
Quote:
Originally Posted by Derakon View Post
Literally added together, so order of operations isn't an issue.

Did you read the earlier post on enforcing a tier system to stat mods? Every tier of modifiers is only allowed to take into account prior mods if they have a strictly lower tier, thus there's no issue of circular dependencies or concern about ordering.
Oh, sorry, I must have missed that one!

So let me get this straight - the stats API calls a modifier's code, and instead of REPLACING the current stat with the return value of the modifier, it just adds it to the current stat value? So if I just returned the current value of the stat from a modifier function, it would not mean "no modifier", but instead it would mean "double the stat"? I guess that makes it much easier to deal with order of operations!
__________________
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!
ekolis is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Pyrel dev log, part 2 Derakon Variants 126 September 11, 2012 23:03
Pyrel dev log Derakon Variants 64 June 8, 2012 11:58
Play FAangband part II Fendell Orcbane AAR 6 November 29, 2010 21:53
JBand progress log. PaulBlay Development 38 June 27, 2009 10:19
Quill, Part II Sirridan AAR 9 June 25, 2009 04:51


All times are GMT +1. The time now is 13:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.