# What is the difference between Non-Player Characters and Enemy Characters?

Non-Player Character also known as NPC is a character that is controlled by a computer itself with an Artificial Intelligence and friendly behavior. (Ex. Merchant, Blacksmith, Pet)

Enemy Character is a character that also has an Artificial Intelligence but with a different behavior. (Ex. Monster, Troll, Slime)

What is the difference between Non-Player Characters and Enemy Characters?

I need to create a Character class which is divided into three types, a PC, NPC and Enemy Character. I want to know what are the possible attributes or data of NPC and Enemy.

Based on the below code example, I have added a target and steering-behavior data for both Enemy & NPC. As you may have noticed, they both have the same data, the only difference is they have a Good and a Bad or Can attack or Cannot attack.

public class Character {
// Traits or Stats, Skills & Abilities
}

public class NonPlayerCharacter extends Character {
Vector2 target
// friendly behavior, it means it doesn't attack
// can follow, attack, pursue, evade, flee (Some steering behaviors)
// can stall & sell items, save point, bank etc.
}

public class Enemy extends Character {
Vector2 target
// Not friendly, it means it does attack player
// Also have steering behaviors
}

• All of three are all the same. What if the PC attacks an NPC and the NPC decides to attack the PC It'll turn into an Enemy. Give them a "behaviour" component that will control them. The behaviour for the "Playable character" receives the input from the player, while the "NPC" behaviour has 'kind and supportive' behaviour and the "Enemy" attacks on sight.... – Vaillancourt Sep 6 '16 at 1:02

What is the difference of Non-Player Character between Enemy Character?

Interpretation, basically.

From the perspective of data and methods, an "NPC" and an "Enemy" type are almost the same. So much so that I would argue that you should not be creating your NonPlayerCharacter and Enemy types the way you are. Character is generally sufficient on its own. In you case I think this is especially true because you're having trouble coming up with what the distinguishing features of the various types should be: consider that if you can't think of any good reasons to make the types unique, maybe you shouldn't actually make the types unique.

Instead, give the Character class additional properties you may need to represent the desired behavior (for example, you can give it a bool canAttack field, which you always set to true for instances that should be enemies but false for instances that should be non-combat NPCs. Rather than hard-code the behavior of the type as a member function, use a pointer or reference to a script (or if you don't have scripts, a behavior component, object, or member function pointer).

You can, in fact, extend this concept to cover the player character as well.

• I ended up creating an CombatComponent that holds the bool attack and vector target. Thanks for the answer it really helps a lot – ronscript Sep 6 '16 at 23:12

An enemy is also an NPC.

Yes, they behave differently and have different abilities and functionality. But you will likely also have many different kinds of enemies with different behavior patterns and different abilities. The same applies to friendly NPCs. So the AI and moveset is no strict distinction.

The only substantial difference is that one can be damaged by the player and the other can not. Or when your game allows friendly fire then maybe not even that and the only difference is the color of the dot on the minimap.

I would add an attribute for your NPC which says which side they are on. In the simplest case this can be a simple bool isEnemy, in a more complex game you could have a complicated faction system which determines who is fighting with whom. Note that changing that variable at runtime could be a very simple way to have a friendly NPC suddenly attack the player or have an enemy surrender and turn into a friendly NPC.

Shopkeeper, Bank, SavePoint, Questgiver etc. should either be subclasses of NPC or if you want an NPC to be able to fulfill multiple roles it could be a component.

Each NPC should also have another component AI which controls its movement. You could split that into CombatAI and IdleAI to have the NPC act differently depending on whether or not they are currently in combat.

• Except when that enemy is another player :) – Laurent Couvidou Sep 7 '16 at 9:13

adding to Josh's answer, you could do somtething similar to how Dark Souls 1 deals with enemies and allies, the game basically has three teams for the entirety of NPCs:

• ally: this is the player's team, members of this team can not hurt each other.

• neutral: this is the basic NPC team, they are not aggressive by default, and only become aggressive if specifically triggered (game event or player attacking), these can hurt and be hurt by anybody, you could say these are sort of teamless

• enemy: these are the monsters, aggressive by default and cannot hurt team-mates, just like the ally team.

basically when in multiplayer, when you get invaded the other player joins the enemy team, and when summoning help, they join the ally team.

So what does this mean for you? Well, if you can't think of any specific differences between basic NPCs and enemies, you could use a similar team based system by implementing a team attribute.

Hope this helps a bit.