Damage calculator

[Holy_Diver]

Sounds neat.  Wouldn't  it work just as well to use simple math tags like:
Damage=(Attack1-Defense1)+(Attack2-Defense2)... etc

I can see how such labels could fall short for advanced stuff, but it would be quite simple for beginners to pick up.

That's how it works. It's like a calculator. For that you would do:

hit_outcome_quantifier = 1_-2_

Or:

hit_outcome_quantifier = _[1]-_[2]

Or if parameter labels are implemented for extensions:

hit_outcome_quantifier = _[HP]-_[AP]

Or:

hit_outcome_quantifier = _[Attack]-_[Defense]

[HwitVlf]

I think this would be extremely helpful to SoM users.  I just meant using simple terminology in the labels seemed like a good idea. Being a lifelong lover of 'communication through written words', things like "hit_outcome_quantifier" seem needlessly computer-geekish to me (ala concatenation, obfuscation, parse etc). But the functionality is the main part and that's great.

When you get it up and running, please post. I might take the effort to revamp SoM's starting enemy stat slots so that people can start with balanced "leveled" creatures built in.

[Holy_Diver]

I think this would be extremely helpful to SoM users.  I just meant using simple terminology in the labels seemed like a good idea. Being a lifelong lover of 'communication through written words', things like "hit_outcome_quantifier" seem needlessly computer-geekish to me (ala concatenation, obfuscation, parse etc). But the functionality is the main part and that's great.

Well if you call it "Damage" what kind of damage is it? This extension is in the [Damage] section already. If its not called _quantifier then how do you know what it is? That tells you that there are input parameters involved. How do you search for it in the documentation? And how do you differentiate it from 100s if not 1000s of other extensions? Truth is the name here is quite short. It's part of a group of hit_ extensions, of which there are quite a few. There are extensions with much longer names.

Simple isn't always simpler. It doesn't scale. If you do things simple, then you are limited to doing everything simple, and simple can never be more than, you guessed it, simple. Besides just the process of parsing and evaluating an infix mathematical expression with operator precedence (in other words calculator syntax) is an incredibly complicated (this is one of if not the biggest jobs I've yet to do in service of SOM. And just the (1+2)-(3*4) bit alone is a good chunk of it.)

Also consider. I didn't ask what Attack1 and Attack2 means. Why two? How many are there? But if you add them together with just (A-B)+(A-B) you won't get the results you are looking for. You'd have to do something like max(0,A-B)+max(0,A-B) and as you can see that is already far from simple.

When you get it up and running, please post. I might take the effort to revamp SoM's starting enemy stat slots so that people can start with balanced "leveled" creatures built in.

Starting enemy stat slots? What does that mean? The monsters in the King's Field sample? Anyway. I would leave everything alone. The default behavior will be the same as SOM uses no matter what. I would remove the bug where stats are 0 or negative, but I worry it would break existing games because the math is so messed up...

Probably I will fix the bug because its a bug. And older games will just have to turn off the fix. Or better yet, fix their monster's stats. I wonder if any of the monsters in the KF remake have 0 stats.


PS/EDITED: I too love communicating via the written word. That's why the names of the extensions are very literate. Or at least I am not a fan of cryptic configuration files. I'm not sure which is which. But the site I visit the most while I am working is thesaurus.com.

PPS: Literate programming is also a thing, which I am a strong advocate of and adherent too (edited: but don't go by http://en.wikipedia.org/wiki/Literate_programming ... that isn't literate programming, that's programming with literature. No one in the real world does that. I'd never even heard of that. Anyway, literate programming is programming without commentary because the code itself can be read like a book so any comment you could write would just be translating things for non-programmers -- who of course don't read code)

[HwitVlf]

Pardon me if I'm being dense, but I thought the only "damage" in a SoM game was the final uhh... damage total the player receives. If you want to set up a game that has multiple "damage" subgroups(stab slash etc) , they still all end up a single totaled number ..."damage". 

Regardless of what fancy "elemental" label a person slaps on damage ingame, I think it's always going to boil down to three terms: "attack" which is the attacker's ability to inflict damage, "defense" which is the defender's ability to resist attack, and "damage" which is the resulting HP loss after attack and defense are processed.

My term "attack1" and "attack 2" were simple labels for damage sub-groups. For instance "Attack1" could be the attackers fire stat, "attack2" the attacker's stab stat.

Anything that works is fine. This was just my opinion about good labeling practices.

As far as setting "starting enemy stat slots", the default enemy stat/AI values are loaded when you make a new enemy slot in the Parameter Editor. The 'defaults' are read from one of SoM's file. The file's presets are rather useless which means a game maker has to manually adjust a bunch of settings for every new monster. I just meant, I could make an optional file that would make the defaults loaded for new enemies more intelligent and scaled so that game makers wouldn't have to do everything manually. They could still change things if they wanted.

[Holy_Diver]

Pardon me if I'm being dense, but I thought the only "damage" in a SoM game was the final uhh... damage total the player receives. If you want to set up a game that has multiple "damage" subgroups(stab slash etc) , they still all end up a single totaled number ..."damage". 

Regardless of what fancy "elemental" label a person slaps on damage ingame, I think it's always going to boil down to three terms: "attack" which is the attacker's ability to inflict damage, "defense" which is the defender's ability to resist attack, and "damage" which is the resulting HP loss after attack and defense are processed.

My term "attack1" and "attack 2" were simple labels for damage sub-groups. For instance "Attack1" could be the attackers fire stat, "attack2" the attacker's stab stat.

I am not sure what all different sources of damage there are or will possibly be. Damage is a very broadly defined term. Here are all the extensions for traditional whops on the head:

   EX_INI_NUMBER(0,0,INF) hit_point_quantifier;
   EX_INI_NUMBER(0,0,INF) hit_point_quantifier2;
   EX_INI_NUMBER(0,0,INF) _hit_point_quantifier;
   EX_INI_NUMBER(0,0,INF) _hit_point_quantifier2;
   EX_INI_NUMBER(0,0,INF) hit_outcome_quantifier;
   EX_INI_NUMBER(0,0,INF) hit_penalty_quantifier;

The last one is for Poison damage. To reproduce the way SOM works you'd need to setup hit_point_quantifier for physical bonus. hit_point_quantifier2 for magical bonus. And hit_outcome_quantifier for the HP hit after defense.

If you want to do things differently for each affinity that takes extra work. The affinity would probably be in _[3] if there is a demand for that.

Should impact damage work like a whop on the head? What about monster damage? What about monster on monster damage? Should fall damage be distinct from impact damage? Environmental damage? Equipment damage? Internal damage? Brain damage

And don't forget you have to satisfy everyone's needs.

Anything that works is fine. This was just my opinion about good labeling practices.

Don't worry. My decisions are always best. Which is even better than good. I've never regretted anything. I make sure that I won't because it's better to do something right than do something twice. It will be possible to translate the Ex.ini files. I don't think it would help anything. But you could translate hit_outcome_quantifier to "damage". I think ultimately though that the exercise would just help you see why this wouldn't work out so well. You don't really see the problems clearly until you have to define them down to the quantum level of computing.

I think I saw what the Half Life config files looked like the other day in a forum. Those configuration keys were even longer than these.

As far as setting "starting enemy stat slots", the default enemy stat/AI values are loaded when you make a new enemy slot in the Parameter Editor. The 'defaults' are read from one of SoM's file. The file's presets are rather useless which means a game maker has to manually adjust a bunch of settings for every new monster. I just meant, I could make an optional file that would make the defaults loaded for new enemies more intelligent and scaled so that game makers wouldn't have to do everything manually. They could still change things if they wanted.

That's the first I've heard of this. I don't think I've ever noticed any defaults. I assumed everything would be zeroed out. Is that in the PRF files? I think a better system might be to have template projects. I don't think defaults would be useful. But that could make it a lot easier to just make your first map just to test drive the editors.

[HwitVlf]

My vote is for the 'brain damage' label to be:
contactual_cephalic_discombobulation_recursion_index 

If memory serves, its the PRM files that contain the presets. They're not zeroed out by default, but pretty close. Size is set to 1, recognition is off, attacking is off and HP is set to 0.

[Holy_Diver]

If memory serves, its the PRM files that contain the presets. They're not zeroed out by default, but pretty close. Size is set to 1, recognition is off, attacking is off and HP is set to 0.

While I am aware of that. I don't think it would help to change it up. I would say I don't see how, but that sounds even more dismissive. I took you to mean that there were defaults for each PRF's attack and defense ratings.

I think that's something that would be worth adding to the a .PNT (paint) format I am working on. I wish I could remember how that works. It must be either an extension to PRF or a file that indicates a PRF or a PRT. Either way it lets you apply a paint job, decals, change a rock projectile attack to an ice attack, change the PRF name from Giant to Ice Giant. That sort of thing.

[Holy_Diver]

I think I had a good idea to remove the hit_extra_quantifier extensions just now. I never liked the name of those ones. I thought they'd be handy to set things up so that Magic attacks are based on the Magic stat. Which I think probably has a wider appeal than the way SOM (and presumably all of the KF games) work.

I thought it was an esoteric thing, because there is just nothing else in the world like "magic" so that only fantasy games would use it. Anyway. It dawned on me that its very unlikely that you'd want to differentiate between the physical and magical affinities if you were going to play that way. So it makes way more sense to just have the meaning of hit_point_quantifier2 change by switching on some other option.

I'm sure I would've realized this about 1 minute into actually implementing things. But its a big relief. I think I probably got there by working backwards from where I wanted to end up.

As for the others, _hit_point_quantifier is for defense bonus. I don't like to start extensions with an underscore. That's usually just a shorthand. But it represents a minus sign. The formal name might be even longer, but I can't think of anything. There may be some bit in front of hit_point that can just be left off for the traditional stuff (or plain hit_point might be the default formula where other specialized ones are not specified)

[Holy_Diver]

^Per _hit_point_quantifier, leading underscore. It's going to be called hit_offset_quantifier instead. And I am very pleased that this stuff has gradually worked itself out.

It looks like there is going to be a hit_point_mode in addition to the hit_point_model. I think mode 2 will prove popular. It lets you control things based on the kind of attack instead of the kind of affinity. So the Magic stat can give bonuses to magic attacks likewise for defense with hit_offset_quantifier2...

So it would be nice to figure out a system for communicating what monster attacks are Strength vs. Magic based. Never mind that monsters don't have those stats. But for  hit_offset_quantifier in mode 2 its necessary to figure out which extension to use. The initial approach I am sure will just assume that if the attack is direct it is Strength based, and if not Magic based. Whether that is based on animation IDs or just whether or not the damage source is a magical effect it's too soon to say.

[Holy_Diver]

EDITED: Actually. Probably the simplest thing to do would be to just leave hit_offset_quantifier2 alone in mode 2...

That's probably even more practical than having a stat produce a magic wall, even though that is pretty common in video games. By not setting up that extension you'd just be saying that once the magic attack is out of the barn, its a physical phenomenon just like anything else. And so a strong man is in a better position to defend themselves from the attack than a old wizard would be.

Anyway, that would be much more compatible with SOM because monsters don't have Strength and Magic stats as such, and it isn't obvious if their attacks are one or the other based... the same way it is with the player, where you always press the Magic button for Magic attacks.

You could also just combine Strength and Magic for defense as if you can draw from either source to defend yourself.