Haunted Light – Base code for Enemies

Hello. Today I’ll be talking about the base for our enemy objects, how it works and how it’s different from the normal GameObject and also why that is. Both of the classes, EnemyObject and EnemyObjectManager, are heavily based on the already existing files PlayerObject, GameObject and GameObjectManager, with EnemyObject being a combination of GameObject and PlayerObject. The key differences are that the Enemy-ones doesn’t have keyboard and mouse as inputs, since you don’t control your enemies, and that EnemyObject doesn’t have an Update-method, but it is in each of the sub-classes, since each enemies have different AI. This time I’ll walk over the differences between these two very similar class-trees in detail, explaining what is different and why it’s different.

EnemyBase

We will be taking a look on only EnemyObject and GameObject+PlayerObject, since there is no real difference between the respective objectmanagers, other than naming(EnemyObject vs GameObject).

The base methods between the classes are roughly the same, but other methods such as Update() and getStamina() have been cut away completely because they aren’t needed or are simply impractical to have in that place, such as Update(). But I’ve added a number of methods that will be used during the AI programming, such as getDistance() and setDistance().

To the “fun part”, the explanation of each of the different methods that are added in the new class-tree.

setDistance() – Takes 3 inputs, maxDistance(float), obj1(float Vector2), obj2(float Vector2). This method returns no value.

Obj1 and obj2 are surposed to represent the position of 2 object. The objects positions then gets compared to each other and calculated the distance between them, if the distance if more that the maxDistance input, set obj1(first objects position) to the maxDistance from obj2(second objects position)
This is useful for programming the AI for our “crawler”, a slow monster that is always after you, so that you never have a safe distance between yourself and that monster.

getDistance() – Takes 2 inputs, obj1(float Vector2), obj2(float Vector2). This method returns a float Vector2 value that is the distance between the two objects.

The inputs represent the same thing in this method as they did in the last method.
This method gives the EnemyObjects the players position, and it’s needed since all of them have behaviors that depends on the players position and/or distance to them. The objects positions then gets compared to each other and calculated the distance between them.
This method is used by setDistance() and is also useful when programming the “critter” and “waller” AIs, since that enemy doesn’t become active untill you are within a certain radius of it.

getPlayerPosition() – Takes 1 input, playerPos(float Vector2). This method returns no value.

I had alot of trouble figuring this one out, since I though backwards. My initial thoughts were to have a PlayerObject as an input, but then that caused a lot of hassle with access to the PlayerObjects methods from an enemy. But after some time with writing down what had to happen and tracing the commonground for the different objects. All that was needed was this line of code in the GameState: critter->getPlayerPosition(player->getPosition());

setHealth() – Takes 1 input, health(float). This method returns no value.

Sets the enemies health. A might-be-used method, depending if the enemies have health or just have their behavior changed based on a timer instead.

setFriction() – Takes 1 input, friction(float). This method returns no value.

With this you can set the friction for specific enemies. Friction is what gives the moving objects a smooth start and stop of their movement. But this is not just a variable like in PlayerObject since not every enemy have friction. The “crawler” moves in a constant speed and the “waller” is stationary.

So that wraps up the overview of the changes and differences between the EnemyObject and GameObject+PlayerObject. Next on the agenda for me is the different enemy AIs, that’ll definitely be an interesting challenge. But enough for now.

With regards
Calle Johansson, Gamedesign and Programming