How hard (or easy) is a foe?

Game Mechanics
#1

Howdy all,

I have been trying to come up with a formula based on the stats of a foe in my game (http://www.indiedb.com/games/fabuladivina) to determine how much more dangerous or how much easier a foe is than any other foe (including you.)

I have tried a bunch of different formulas of attack power, defense, health, skills etc… and I can’t find one that ‘works’ for me.

What I am trying to do is figure out whether certain creatures (like a little field mouse) should run away from the big bad dragon, while it may want to attack the cockroach.

Has anyone else tackled this issue? I was looking for a formula since my spawn are also rolled, and some may be more dangerous, and some may not be.

Thanks.

#2

The brute force approach would be to simulate a battle, and see if the little field mouse would win.

#3

Without having played the game or anything, can’t you just compare the level integers and if monster X is level 5 and monster Y is level 50 then have monster X run away?

#4

A level 1 dragon has different stats than a level 1 mouse. I really need to try and do it at the stat level. Here is what I have tried currently:

public short rating()
{
short r = this.magic_offense();
r += this.magic_offense();
r += this.offense_physical();
r += this.defense_physical()/2;
r += this.hp/10;
return (short)(®>0?®:1);
}

#5

Hmm… why should one entity automatically know that the opposing entity is stronger/weaker?

I think it should decide wheter or not to attack it by how intimidating it is, which is most of the time the opposing entities size. So why not make it simple and just compare the two entitie’s sizes?

#6

You have a good point. I will try that approach. Maybe I just wanted to make it too smart.

Thanks.

#7

I will try this approach:

public static final byte lifeSizeXSmall = 0;
public static final byte lifeSizeSmall = 1;
public static final byte lifeSizeNormal = 2;
public static final byte lifeSizeMedium = 3;
public static final byte lifeSizeLarge = 4;
public static final byte lifeSizeXLarge = 5;
public static final byte lifeSizeGigantic = 6;

#8

I was thinking about just comparing the sprite’s widthheight with the other sprite’s widthheight. Even less effort and more accurate :smiley:

#9

I will ponder that approach as well. I would have to take into account the transparency of the shape as well.

Here is my current approach, I could just switch out the logic in the lifeSize() method if I want to do sprite size

public static class RunAwayFromNearTargetIfStronger extends Thought
{
public RunAwayFromNearTargetIfStronger(LifeFormInventory l)
{
super(l);
this.name = consts.thoughtRunAwayFromNearTargetIfStronger;
}

    public void runAway(LifeForm targetToDistance)
    {
        
    }
    
    
    public boolean action(NPC me)
    {
        if (me.Target != null)
        {
            if (Math.abs(me.Target.lifeSize() - me.lifeSize())>= 2)
            {
                runAway(me.Target);
                return true;
            }
        }
        
        LifeForm l = me.findNearestTarget();
        if (Math.abs(me.gps.distance(l.gps)) <= 2)
        {
            if (Math.abs(l.lifeSize() - me.lifeSize()) >= 2)
            {
                runAway(me.Target);
                return true;
            }
        }
        
        return false;
    }
}
#10

Another top-of-my-head suggestion, if it’s possible due to the stat differences you mentioned, would be to add up the total amount of stat points and then if monster X is below half the amount of monster Y’s stat points then monster X runs away?

#11

I think that’s basically what he’s doing in his second post

#12

Any easy way to count non-transparent pixels? :slight_smile:

#13

Perhaps you want more of an absolute level scale, where bigger and badder monsters start at a higher level. You’re not going to see a Level 1 Dragon, Beholder, or Mind Flayer in D&D after all.

Just simulating the battle for a few rounds and checking the results is a pretty reasonable way to do it too, since it basically models the thought process of “Pray tell, what would perchance be the outcome were I to engage in manly fisticuffs with this Ancient Misshapen Horror From Beyond? Why it would seem I would be fried to a delicate crisp post-haste. What say we run away, old chap?” You’re going to need to run automated sims anyway in order to do game balancing.

#14

@sproingie I laughed so hard at your sample dialogue, I almost asked if you would have done me the honor to write at least one character for me in the game :slight_smile:

#15

Simulation is definitely what he needs… throw in some random numbers when deciding hit/miss, dmg, etc… and then have the computer process 1,000 outcomes. It may take a little work, but honestly I don’t think it’d be that bad.

But truthfully, if you’re going to have a sizeable number of monsters, you want a fast and efficient way to test outcomes.

-Pickle

#16

Yes, the foe system in this game is kind of like a turnbased Diablo, so there are times quite a few creepy crawlies are on the screen at once.

#17

If the intimidation factor is something you’re interested in, you can just give every monster an intimidation stat and automatically level it up with the other stats. Size alone is a bad metric. After all, what would you be most likely to avoid, a scorpion or a panda?

#18

How intimitating an enemy is, depends on the combination and interaction of various stats of the entity.

So… when he asked how to compare two entities, which is incredibly difficult, you say that he should simply calculate it and push it into a stat. That’s no solution, that’s exactly the problem he was needing help with, but phrased differently: how to calculate that ‘intimidation stat’.

I stick with my (first) reply in this thread: just simulate a battle. It takes out all guessing and heuristics, and it will always be correct, whatever you (radically) adjust later on.

#19

The idea would be that you would choose an appropriate base level and level up rate for the intimidation stat the same way you would every other stat. On a per species basis. If you could have a single mouse that was incredibly well equipped with magic abilities and a single dragon with low stats all around or some other random configuration of stats and skills, then intimidation as a stat wouldn’t mean anything. That’s only the case if stats are random. The case is probably that each species of monster is designed with a specific set of skills, stats, and personality.

There main downside to simulation, (used alone,) is that it may become too mechanistic and symmetrical. Intimidation involves perceived danger, not actual danger. Intimidation allows you to factor in an extra variable for more realism. It depends on the combat system, but I can imagine cases where it would be terrible. If it were one of those games where enemies take turns hitting each other, have the option to retreat, and disappear after the screen fades to black, then the game would be too frustrating if the enemy ran away every time its HP was brought down to near zero. If it were an open combat system were enemies could run around, then you would have enemies that would constantly flee from an opponent and an opponent that would constantly chase the first monster. You would end up with chains of monsters running around the screen and little actual fighting.

You really don’t want the computer players to be omniscient. A better method is to use fuzzy logic. A strong intimidating monster may chase opponents weaker than it, a timid monster would avoid risky conflicts, a weak intimidating monster would “trick” it’s opponents into avoiding a fight by bluffing, and ordinary monsters would pick fights with either slightly weaker or slightly stronger monsters based on apparent risks and rewards. Their own aggressiveness/timidity would determine how risk averse they were and their opponents’ intimidation factor would determine how strong their opponent appeared to them.

#20

[quote=“Best_Username_Ever,post:19,topic:40420”]
It’s a non-issue really. There is (most likely) so much randomized action in the simulation, that the outcome is merely a very rough indication on what your chances are.

And whether a ‘timid monster’ would even fit in a game, is a whole different issue. Why generalize the problem to such extend that simple solutions no longer work. When you talk about intimidation and appearance, we’re entering the realm of bluf and deceat. That requires an intelligence stat, as you can only deceat a resonably intelligent entity - with an enemy too dumb, your clever tricks won’t work. Your suggestions are making the problem harder and harder. Keep it simple. As you need to simulate battles at some point, to get the game to function, you could just as well use that existing functionality to make entities estimate their chances among eachother. Added benefit is that, as said, whatever you change in the balance of the game, you don’t have to constantly update your heuristic - with a high chance of getting it wrong, as you cannot imagine all effects in a system with so many (asymmetric) variables.