# Behavior RPG AI and Fairness - player's characters stats public to AI

## Recommended Posts

Hebi    113

What worries me is fairness, I don't want an AI with "god eyes".

In a first attempt, the AI wasn't smart at all. It has a set of rules, that could be customized per possible enemy formation, that makes the AI acts as it has personality. For example: Wolves had a 80% prob of using Bite and 20% of using Tackle.

Then I tried to make the AI do things with sense, by coding a reusable algorithm, then I can use rules to give different enemies formations different personalities, like this one is more raw damage focused and this other more status ailment focused. To achieve this I was trying to make the AI player to collect stats about the human player skills and characters by looking at the log, my game has a console that logs everything like most RPGs (think Baldur's Gate). An attack looks like this in the console:

Wolf uses Bite

Mina takes 34 points of damage

Mina uses Fire Ball

Wolf takes 200 points of damage

The AI player has a function, run(), that is triggered each time a character it controls is ready to act. Then it analyzes the log and collect stats to two tables. One with stats per skills, like how many times it was used and how many times it did hit or was dodged, so the AI player knows what skills are more effective again the human player's team. These skills stats are per target. The second table is for human player's character stats. The AI player is constantly trying to guess the armor, attack power, etc, the enemies have.

But coding that is quite difficult so I switched to a simpler method. I gave the AI player "god eyes". It has now full access to human player's stats, two tables aren't required anymore as the real character structure is accessible to the AI player. But the AI player pretends that it doesn't have "god eyes" by, for example, acting like it ignores a character armor again fire, until a fire attack finally hit that character, then a boolean flag is set, and the AI player can stop pretending it doesn't know the target exact armor again fire.

Currently, the AI player can assign one of two roles to the characters it controls. Attacker and Explorer. More will be developed, like Healer, Tank, etc. For now there are Attackers and Explorers.

These roles has nothing to do with character classes. They are only for the use of AI player.

Explorer: will try to hit different targets with different skills to "reveal" their stats, like dodge rate, armor again different types of damage. They must chose which skills to use by considering all skills of all characters in the team, but I'm still figuring the algorithm so right now they are random but at least they take care to not try things that they already tried on targets that they already hit. Explorers will switch to attackers at some time during a battle.

Attacker: will try to hit the targets that can be eliminated in less turns. When no stats are known they will chose own skills based on raw power, once the different types of armors are known to the AI, they will switch to skills that exploits this info, if such skills are available to them. Attackers will try different skills if a skill chosen based on raw power was halved by half or more and all enemy armors aren't known yet, but won't try for the best possible skill if one that isn't halved by as much as half its power is already known. Attackers may be lucky an select the best possible skill in the first attempt, but I expect a formation to work better if there are some explorers.

This system opens up interesting gameplay possibilities. If you let a wolf escape, the next pack may come already knowing your stats, and that implies that their attackers will take better decisions sooner as the AI requires now less exploration.

So, the description of an enemy formation that you can encounter during the game may be:

PackOfWolves1: {

formation: ["wolf", null,   "wolf", null,   "wolf",

null,   "wolf", null,   "wolf", null,

null,   null,   null,   null,   null],

openStatrategy: ["Explorer", null,      "Explorer", null,       "Explorer",

null,       "Attacker", null,      "Attacker", null,

null,       null,       null,      null,       null]

}

What do you think about these ideas? Was something similar tried before? Would you consider unfair an AI with "god eyes"?

Edited by Hebi
Important paragraph omitted before, correcting.

##### Share on other sites
Alberth    9508

Never programmed an AI, but as far as I know it's horribly complicated, and common practice is to "cheat" like you do.

I believe it is mure important to keep a random element in it, it is very boring if you always get the same set of enemies, and if they always make the same moves.

Random elements also hide somewhat that you're cheating, they have the effect of getting less precise knowledge than you really have.

##### Share on other sites
Hebi    113

So cheating may not be so uncommon. That gives me some confidence.

Same as you, I never programmed and AI, other than implementing A* for 2D isometric prototypes. Enemy actions were always based on some kind of roll. I want a more challenging AI this time, one that does things with sense other than roll for everything.

If a smart player confirmed that an enemy is vulnerable to fire, not exploiting that has no sense, and destroys the illusion you are playing again an intelligence. But, choosing always the same action pattern also destroy that illusion, it's true. I think then, that I need some kind of configurable parameters to make the AI vary behavior. If it looks like the AI is doing that to avoid being predictable then it's fine, I guess.

Edited by Hebi
grammar

##### Share on other sites
conquestor3    1593

Basically don't try to make the game fun for the computer, try to make it fun for the player.

At least part of the joy of playing an RPG (at least for me) is wondering what the enemies going to do, and see'ing whether or not I get screwed over. If the AI is smart enough to always pick the best choice, they feel pointless and I wish I could autoplay the game at 100X the normal speed since I already know what's going to happen.

##### Share on other sites
ApochPiQ    23000

So this is a classic example of the blurry line between game design and game AI.

On the one hand, yes, you have a challenge presented here, in that the AI needs to operate under certain constraints - or at least perceived constraints.

The flip side of course is that this isn't really about how to build an AI, it's about how to design a compelling opponent in the first place.

Many AI decisions rest on game design foundations, as you're finding here. The trick is to solve the game design questions first and foremost, and then do whatever it takes to make the AI play the way you've designed it to.

As far as cheating goes, it's rampant in almost every game from an AI perspective. Sometimes it just doesn't make sense to simulate ignorance. Then again, sometimes it does - and this is back to game design. Stealth games without simulated ignorance would just be shooters, for just one example.

Ultimately you need to plan ahead from a perspective of "what should the gameplay feel like?" and work towards a suitable AI implementation from there.

##### Share on other sites
Hebi    113
7 hours ago, conquestor3 said:

Basically don't try to make the game fun for the computer, try to make it fun for the player.

At least part of the joy of playing an RPG (at least for me) is wondering what the enemies going to do, and see'ing whether or not I get screwed over. If the AI is smart enough to always pick the best choice, they feel pointless and I wish I could autoplay the game at 100X the normal speed since I already know what's going to happen.

I agree, but that doesn't mean that the enemy must do completely random things. am I right? A certain algorithm is still needed.

4 hours ago, ApochPiQ said:

So this is a classic example of the blurry line between game design and game AI.

On the one hand, yes, you have a challenge presented here, in that the AI needs to operate under certain constraints - or at least perceived constraints.

The flip side of course is that this isn't really about how to build an AI, it's about how to design a compelling opponent in the first place.

Many AI decisions rest on game design foundations, as you're finding here. The trick is to solve the game design questions first and foremost, and then do whatever it takes to make the AI play the way you've designed it to.

As far as cheating goes, it's rampant in almost every game from an AI perspective. Sometimes it just doesn't make sense to simulate ignorance. Then again, sometimes it does - and this is back to game design. Stealth games without simulated ignorance would just be shooters, for just one example.

Ultimately you need to plan ahead from a perspective of "what should the gameplay feel like?" and work towards a suitable AI implementation from there.

Then I may be trying to solve a design problem, not AI problem. I definitely want the AI to be able to win, and the game to feel challenging, not impossible of-course. It is an RPG, no doubt, but I imagined battles as very tactical (think Baldur's Gate, where encounters aren't random and you can lose any of them).

Edited by Hebi
Extending last paragraph.

##### Share on other sites

One thing to remember is that players are really good at coming up with explanations for the NPC behaviors even when there isn't one. They will ascribe meaning and intent to what is pouring out of a random die roll. If you start with perfect knowledge and then fuzzy it up a bit, it may look just as plausible as your "exploration and learning" method... but with a lot less work.

##### Share on other sites
frob    44904

There is a balance to it, and the balance is so difficult it is often a big part of what goes in to regular patches for long-term games.

Balancing a game AI is tricky. Make a game too easy and players won't enjoy it. Make a game too difficult and players will hate it.  Generally there are options for different levels of difficulty, often each needs to be fine-tuned individually.

Nobody wants to fight a perfect AI. A machine that always makes the ideal decisions, always follows the ideal path, always makes perfect shots, always makes the perfect corrections and countermoves to the player's actions.  On the other hand, nobody wants a stupid AI. A machine that always makes predictable decisions, that regularly makes the same mistakes, that never really plans ahead.

And as for hidden stuff, you as a player realize things about hidden stuff all the time.  You know the location of all the mines and resources. You have learned all the great positions for being a sniper, or the great positions for picking up tons of loot. That stuff isn't shown on the map, but it is something you have learned.  The AI isn't doing complex machine learning, nor is it likely to retain knowledge between levels. The AI also needs a bit of unpredictability so it doesn't follow the same path around the map every game, always falling for the same traps, always routing through the same funnels.  To compensate, most game AI's look at information that isn't shown to the player.

Further, understand there is more to randomized behavior than a dice roll.  There are many different distribution curves that can be used, various statistical models and probability options.  Numbers can be biased high or biased low. Odds can be heavily skewed. Distribution curves can be modified at runtime, adapting to skew right or left to automatically balance based on how the player is performing.

Consider games like Mario Kart, the series has done well at dumbing-down the AI to make horrible mistakes when the player is trailing, or pushing the AI to perfect or near-perfect performance with full knowledge of the board when the player is performing exceptionally well.  Even if the player understands the computer is 'cheating' and occasionally loses to it, the players still adapt and play the game because it is fun and challenging.

##### Share on other sites
Hebi    113

One thing to remember is that players are really good at coming up with explanations for the NPC behaviors even when there isn't one. They will ascribe meaning and intent to what is pouring out of a random die roll. If you start with perfect knowledge and then fuzzy it up a bit, it may look just as plausible as your "exploration and learning" method... but with a lot less work.

I think I have seen players "filling the holes" with their imagination before. I remember all those fandom wikis trying to explain some characters behavior or tactics. Some are good at reverse engineering and do quite a good work figuring the rules behind some bosses attack patterns.

Am I over-thinking things?

11 hours ago, frob said:

There is a balance to it, and the balance is so difficult it is often a big part of what goes in to regular patches for long-term games.

Balancing a game AI is tricky. Make a game too easy and players won't enjoy it. Make a game too difficult and players will hate it.  Generally there are options for different levels of difficulty, often each needs to be fine-tuned individually.

Nobody wants to fight a perfect AI. A machine that always makes the ideal decisions, always follows the ideal path, always makes perfect shots, always makes the perfect corrections and countermoves to the player's actions.  On the other hand, nobody wants a stupid AI. A machine that always makes predictable decisions, that regularly makes the same mistakes, that never really plans ahead.

And as for hidden stuff, you as a player realize things about hidden stuff all the time.  You know the location of all the mines and resources. You have learned all the great positions for being a sniper, or the great positions for picking up tons of loot. That stuff isn't shown on the map, but it is something you have learned.  The AI isn't doing complex machine learning, nor is it likely to retain knowledge between levels. The AI also needs a bit of unpredictability so it doesn't follow the same path around the map every game, always falling for the same traps, always routing through the same funnels.  To compensate, most game AI's look at information that isn't shown to the player.

Further, understand there is more to randomized behavior than a dice roll.  There are many different distribution curves that can be used, various statistical models and probability options.  Numbers can be biased high or biased low. Odds can be heavily skewed. Distribution curves can be modified at runtime, adapting to skew right or left to automatically balance based on how the player is performing.

Consider games like Mario Kart, the series has done well at dumbing-down the AI to make horrible mistakes when the player is trailing, or pushing the AI to perfect or near-perfect performance with full knowledge of the board when the player is performing exceptionally well.  Even if the player understands the computer is 'cheating' and occasionally loses to it, the players still adapt and play the game because it is fun and challenging.

Mario Kart is also a good example of AI showing personality more than intelligence. I will think about it.

I know that roll a dice is not the only way of doing it. But random() and shuffle() are always good friends and I think a lot of RPG out there are just rolling dices. I always thought that turn based battle systems, or semi real-time ones (with focus and cooldown times that vary per skill) but usually with no free movement, are an attempt to make roll based AI possible. For example, in classic turn based JRPGs, you can roll once to select a target then again to select skill, discarding the ones that are a certain miss. I can't offer a concrete implementation as evidence, it's something I'm guessing.

When using a per formation roll based rules system, I decided that having to test all formations would require too much time, so I switched to a more complex but reusable AI code. The idea is that I don't need to teach the AI player how to win per every possible formation. The AI is able to scan all skills in its own characters and take decisions. I invented a function, that I called rdps, "Relative Damage Per Second", that the Attacker role uses to figure out the best skill. When the target armor is unknown, a middle class armor is assumed, when known the real value is used. Right now the AI doesn't understand status ailments, nor it knows how to counter them.

If I follow ApochPiQ advice and define the game design questions first, so far I have:

• Enemies are able to win.
• Enemies behavior doesn't look random.
• Enemies behavior shows personality.
• No per formation AI scripting/rule set.

Maybe the last is more an optimization and I should just remove it for now, and the third one is more a wish, or a plus if time constraints permit, than something present in my current implementation.

It may be out of place for an RPG, but bringing RTEs to the table, what I have observed is that most AIs have a finite set of possible strategies, some apply to many civilizations and some to a specific civilization, the strategy that will be used is decided at the start of a match, maybe for some titles it can be switched at the middle of the match.

I think a sense of personality may be given to the different formations/enemy species, by removing certain strategies from some formations and enforcing certain strategies to others. For example, a story based forced rule, maybe during a certain boss fight: "If Mina is in the player's formation, lock her as target of all Attackers until she dies at least once. Attackers are free to test for armors but not to change target".

I got from this thread that make the human player's character structures public to the AI isn't a bad practice nor something new.

Edited by Hebi

## Create an account

Register a new account

• ### Similar Content

• I'm building an American football simulation(think football manager), and am wondering about the best way of implementing AI based on various inputs which are weighted based on the personality of the NPC...I have a version of Raymond Cattell's16PF model built into the game to be able to use their various personality traits to help guide decisions.
I am going to use this extensively so I need this to be both flexible and able to handle many different scenarios.
For instance, a GM has to be able to decide whether he wants to resign a veteran player for big dollars or try and replace them through the draft. They need to be able to have a coherent system for not only making a decision in a vacuum as a single decision but also making a decision as part of a "plan" as to how to build the team...For instance it makes no sense for a GM to make decisions that don't align with each other in terms of the big picture. I want to be able to have the decisions take in a wide range of variables/personality traits to come up with a decision.

There is no NPC per se...There isn't going to be any animations connected to this, no shooting, following, etc...just decisions which trigger actions. In a situation like a draft, there is one team "on the clock" and 31 other teams behind the scenes working on trying to decide if they want to try and trade up, trade down, etc which can change based on things like who just got picked, the drop off between the highest graded player at their position/group and the next highest graded player in that position/next group, if a player lasts past a certain point, etc...
There needs to be all of these things going on simultaneous for all the teams, obviously the team on the clock is goifn to have to decide whether it wants to make a pick or take any of the offers to move down in the draft from other teams that might want to move up, etc..
So I am planning on making use of something called Behavior Bricks by Padaone Games( bb.padaonegames.com )which is a Behavior Tree but in conversations with others who have worked on AI in major projects like this(EA sports) they said to combine this with a State Machine.
My question is would I be able to do this using just Behavior Bricks or would I need to build the state machine separately?  Is there something else already created for this type of purpose that I could take advantage of?
• By hpdvs2
I remember seeing a name for this, but I can't find it anywhere now.
In one of my courses, I use a weighted list to decide the choices for an AI.
Basically, each AI class has 2 standard functions:  Value and Do.
[Value] returns a float, a percentage of how imperative it believes it is that it does this.  I.e. when your base is under attack, sending troops to defend returns a high value.
[Do] executes the AI.
Then an AI Manager gets the value for each AI choice, and chooses to do the one with the highest value.
I've seen a more formal name for this, but I don't recall what it was.

• Hi there,
it's been a while since my last post. I was creating a bunch of games but there was always something missing. Something which makes the game (maybe unique)... After a few tries I decided to start a side project for a combat system which should be used for fighting games.
I did a lot of research and programming to finally get something that makes actually fun to play. Well... it is only a prototype and I do not want to share it (yet). Now I decided to share my ideas of the basics of a combat system for fighting games.
Don't get me wrong... This is only my way of doing stuff and I want as many feedback as possible and maybe it will help people with their games.
I will provide a few code snippets. It will be some sort of OOP pseudo code and may have typos.
Content
1. Introduction
2. Ways of dealing damage
1. Introduction
What makes a combat system a combat system?
I guess it could be easy to explain. You need ways of dealing damage and ways of avoiding damage. At least you need something for the player to know how to beat the opponent or the game. As i mentioned before, I will focus on fighting games. As it has ever been there is some sort of health and different ways to reduce health. Most of the times you actually have possibilities to avoid getting damage.
I will focus on these points later on.
2. Ways of dealing damage
How do we deal damage by the way?
A common way to do so, is by pressing one or more buttons at one time in order to perform an attack. An attack is an animation with a few phases. In my opinion, an attack consists of at least four phases.
1. Perception
2. Action
3. Sustain
4. Release
Here is an example animation I made for showing all phases with four frames:

Every one of those has its own reason. One tipp for our designers out there is to have at least one image per phase. Now we should take a closer look at the phases itself.
2.1. Perception
The perception phase should include everything to the point, the damage is done. Lets say, it is some sort of preparing the actual attack.
Example: Before you would punch something, you would get in position before doing the actual action, right?
Important note: the longer the perception phase is, the more time the opponent has to prepare a counter or think about ways to avoid the attack. Like having light and heavy attacks. The heavy attacks mostly have longer perception phases than the light ones. This means, that the damage dealt is likely greater compared to the light attacks. You would like to avoid getting hit by the heavy ones, right?
2.2. Action
The action phase is the actual phase where damage is dealt. Depending on the attack type itself the phase will last longer or shorter. Using my previous example, heavy attacks might have a longer action phase than light attacks. In my opinion, the action phase should be as short as possible.
One great way to get the most out of the attack animation itself is by using smears. They are often used for showing motion. There's ton of reference material for that. I like using decent smears with a small tip at the starting point and a wide end point (where the damage should be dealt). This depends on the artist and the attack.
2.3. Sustain
At first sight, the sustain phase may be irrelevant. It is directly after the attack. My way of showing the sustain phase is by using the same image for the action phase just without any motion going on. The sustain phase should be some sort of a stun time. The images during the sustain phase should show no movement - kind of a rigid state.
Why is this phase so important?
It adds a nice feel to the attack animation. Additionally, if you want to include combos to your game, this is the phase, where the next attack should be chained. This means, while the character is in this phase of the attack, the player could press another attack button to do the next attack. The next attack will start at the perception phase.
2.4. Release
The release phase is the last phase of the attack. This phase is used to reset the animation to the usual stance (like idle stance).
2.5. Dealing damage
Dealing damage should be only possible during the action phase.
How do we know, if we land a hit? I like using hit-boxes and damage-boxes.
2.5.1. Hit-boxes
A hit box is an invisible box the character has. It shows it's vulnerable spot. By saying "Hit-box" we do not mean a box itself. It could be any shape (even multiple boxes together - like head, torso, arms, ...).
You should always know the coordinates of your hit-box(es).
Here is an example of a hit-box for my character:

I am using Game Maker Studio, which is automatically creating a collision box for every sprite. If you change the sprite from Idle to Move, you may have a different hit-box. Depending on how you deal with the collisions, you may want to have a static hit-box.
Hit-boxes could look something like this:
class HitBox { /* offsetX = the left position of you hit-box relative to the players x coordinate offsetY = the top position of you hit-box relative to the players y coordinate width = the width of the hit-box height = the height of the hit-box */ int offsetX, offsetY, width, height; /* Having the players coordinates is important. You will have to update to player coordinates every frame. */ int playerX, playerY; //initialize the hit-box HitBox(offsetX, offsetY, width, height) { this.offsetX = offsetX; this.offsetY = offsetY; this.width = width; this.height = height; } //Update (will be called every frame) void update(playerX, playerY) { //you can also update the player coordinates by using setter methods this.playerX = playerX; this.playerY = playerY; } //Getter and Setter ... //Helper methods int getLeft() { return playerX + offsetX; } int getRight() { return playerX + offsetX + width; } int getTop() { return playerY + offsetY; } int getBottom() { return playerY + offsetY + height; } } When using multiple hit-boxes it would be a nice idea to have a list (or array) of boxes.
Now one great thing to implement is a collision function like this:
//check if a point is within the hit-box boolean isColliding(x, y) { return x > getLeft() && x < getRight() && y > getTop() && y < getBottom(); } //check if a box is within the hit-box boolean isColliding(left, right, top, bottom) { return (right > getLeft() || left < getRight()) && (bottom > getTop() || top < getBottom()); } 2.5.2. Damage-boxes
Damage-boxes are, like hit-boxes, not necessarily a box. They could be any shape, even a single point. I use damage-boxes to know, where damage is done.
Here is an example of a damage-box:

The damage box does look exactly like the hit-box.
The hit-box differs a bit to the actual damage-box. A damage-box can have absolute x and y coordinates, because there is (most of the times) no need to update the position of the damage-box.
If there is a need to update the damage-box, you can do it through the setter methods.
class DamageBox { /* x = absolute x coordinate (if you do not want to update the coordinates of the damage-box) y = absolute y coordinate (if you do not want to update the coordinates of the damage-box) width = the width of the damage-box height = the height of the damage-box */ int x, y, width, height; /* The damage the box will do after colliding */ int damage; //initialize the damage-box DamageBox(x, y, width, height, damage) { this.x = x; this.y = y; this.width = width; this.height = height; this.damage = damage; } //Getter and Setter ... //Helper methods int getLeft() { return x; } int getRight() { return x + width; } int getTop() { return y; } int getBottom() { return y + height; } } 2.5.3. Check for collision
If damage-boxes and hit-boxes collide, we know, the enemy receives damage.
Here is one example of a hit:

Now we want to check, if the damage box collides with a hit-box.
Within the damage-box we can insert an update() method to check every frame for the collision.
void update() { //get all actors you want to damage actors = ...; //use a variable or have a global method (it is up to you, to get the actors) //iterate through all actors foreach(actor in actors) { //lets assume, they only have one hit-box hitBox = actor.getHitBox(); //check for collision if(hitBox.isColliding(getLeft(), getRight(), getTop(), getBottom()) { //do damage to actor actor.life -= damage; } } } To get all actors, you could make a variable which holds every actor or you can use a method you can call everywhere which returns all actors. (Depends on how your game is set up and on the engine / language you use).
The damage box will be created as soon as the action phase starts. Of course you will have to destroy the damage-box after the action phase, to not endlessly deal damage.
2.6. Impacts
Now that we know, when to deal the damage, we should take a few considerations about how to show it. There are a few basic elements for us to use to make the impact feel like an impact.
2.6.1. Shake the screen
I guess, I am one of the biggest fans of shaking the screen. Every time there is some sort of impact (jumping, getting hit, missiles hit ground, ...) I use to shake the screen a little bit. In my opinion, this makes a difference to the gameplay. As usual, this may vary depending on the type of attack or even the type of game.
2.6.2. Stop the game
This may sound weird, but one great method for impacts is to stop the game for a few frames. The player doesn't actually know it because of the short time, but it makes a difference. Just give it a try.
2.6.3. Stun animation
Of course, if we got hit by a fist, we will not stand in our idle state, right? Stun animations are a great way to show the player, that we landed a hit.
There is only one problem. Lets say, the player is a small and fast guy. Our enemy is some sort of a big and heavy guy. Will the first punch itch our enemy? I guess not. But maybe the 10th one will.
I like to use some damage build up system. It describes, how many damage a character can get before getting stunned. The damage will build up by every time the character will get hit. After time, the built up damage reduces, which means, after a long time without getting hit, the built up shall be 0 again.
2.6.4. Effects
Most games use impact animations to show the player, that he actually hit the enemy. This could be blood, sparkles, whatever may look good. Most engines offer particle systems, which makes the implementation very easy. You could use sprites as well.
2.7. Conclusion
By using the four phases, you can create animations ideal for a fighting game. You can prepare to avoid getting hit, you do damage, you can chain attacks and you have a smooth transition to the usual stance.
Keep in mind, the character can get hit at phases 1, 3 and 4. This may lead to cancel the attack and go into a stun phase (which i will cover later).
A simple way to check for damage is by using hit-boxes and damage-boxes.
3. Ways of avoiding damage
Now we are able to deal damage. There is still something missing. Something that makes the game more interesting... Somehow we want to avoid taking damage, right?
There are endless ways of avoiding damage and I will now cover the most important ones.
3.1. Blocking
Blocking is one of the most used ways to avoid damage (at least partially). As the enemy starts to attack (perception phase) we know, which attack he is going to use. Now we should use some sort of block to reduce the damage taken.
Blocking depends on the direction the player is looking. Take a look at this example:

If the enemy does an attack from the right side, we should not get damage. On the other side, if the enemy hits the character in the back, we should get damage.
A simple way to check for damage is by comparing the x coordinates.
Now you should think about how long the character is able to block. Should he be able to block infinitely? You can add some sort of block damage build up - amount of damage within a specific time the character can block (like the damage build up). If the damage was to high, the character gets into a stunning phase or something like that.
3.2. Dodging
Every Dark Souls player should be familiar with the term dodging. Now what is dodging?
Dodging is some sort of mechanism to quickly get away from the current location in order to avoid a collision with the damage box (like rolling, teleportation, ...) Sometimes the character is also invulnerable while dodging. I also prefer making the character shortly invulnerable, especially when creating a 2D game, because of the limited moving directions.
3.3. Shields
Shields may be another good way to avoid taking damage. Just to make it clear. I do not mean a physical shield like Link has in the Legend of Zelda (this would be some sort of blocking). I mean some sort of shield you do have in shooters. Some may refill within a specific time, others may not. They could be always there or the player has to press a button to use them. This depends on your preferences. While a shield is active, the character should not get any damage.
Keep in mind. You do not want to make the character unbeatable. By using shields which are always active (maybe even with fast regeneration), high maximum damage build up / block damage build up you may end up with an almost invulnerable character.
3.4. Jump / duck
These alternatives are - in my opinion - a form of dodging. The difference between dodging and jumping / ducking is, that you do not move your position quickly. In case of ducking, you just set another hit-box (a smaller one of course). While during a jump, you are moving slowly (depends on your game).
The biggest difference in my opinion is, jumping or ducking should have no invulnerable frames.

I hope you enjoyed reading and maybe it is useful to you. Later on, I want to update the post more and more (maybe with your help).
If you have any questions or feedback for me, feel free to answer this topic.

Until next time,
Lukas

• Hello,
I have designed an AI system for games that replicates cognitive psychology models and theories, so that NPCs and other virtual characters can behave in more human-like and interesting ways.
I have built a prototype in the Unity game engine, and it can produce quite complex behaviour, including learning and creativity. I am now wanting to develop it further and am looking for people or organisations to help. I am thinking about how I could present my AI system, and what would be a good way of demonstrating it. If you have any suggestions it would be great to hear them.
I have a website that explains my AI system in detail:

www.electronicminds.co.uk

If you have any comments about the AI system, or know anyone who might be interested in helping to develop it, I would really appreciate hearing from you.
Thanks for the help.

• Hey all,

As the heading says I'm trying to get my head around Goal Objective Action Planning AI.  However I'm having some issues reverse engineering Brent Owens code line-by-line (mainly around the recursive graph building of the GOAPPlanner).  I'm assuming that reverse engineering this is the best way to get a comprehensive understanding... thoughts?

Does anyone know if an indepth explanation on this article (found here: https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793), or another article on this subject?

I'd gladly post my specific questions here (on this post, even), but not too sure how much I'm allowed to reference other sites...

Any pointers, help or comments would be greatly appreciated.

Sincerely,

Mike

• 12
• 10
• 18
• 9
• 10