Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
npc_behaviour [2017/01/04 21:56] – zdimension | trs:npc_behaviour [2017/11/17 11:19] (current) – stohrendorf | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | {{indexmenu_n> | ||
+ | |||
====== Non-Player Character Behaviour ====== | ====== Non-Player Character Behaviour ====== | ||
Line 9: | Line 11: | ||
Lara is unique player character, so she has a large set of both //control// and // | Lara is unique player character, so she has a large set of both //control// and // | ||
- | > **Note** | + | <note> |
- | > | + | In original Tomb Raider source code, notation for collisional and state routines follows two different schemes. For Lara, collisional and control routines are called '' |
- | > In original Tomb Raider source code, notation for collisional and state routines follows two different schemes. For Lara, collisional and control routines are called '' | + | |
- | > | + | For other entity types, there is more generic scheme: collisional routines are called '' |
- | > For other entity types, there is more generic scheme: collisional routines are called '' | + | </ |
===== Entity Scripting ===== | ===== Entity Scripting ===== | ||
Line 19: | Line 21: | ||
Despite the existence of //script files//, here is no any scripting for entity behaviour, like in most contemporary games. This hardcoding makes it difficult to port the earlier Tomb Raider scenarios to the engines of the later games, which could be desirable with their improved hardware support. While textures, models, and animations can be ported, behaviour cannot be. | Despite the existence of //script files//, here is no any scripting for entity behaviour, like in most contemporary games. This hardcoding makes it difficult to port the earlier Tomb Raider scenarios to the engines of the later games, which could be desirable with their improved hardware support. While textures, models, and animations can be ported, behaviour cannot be. | ||
- | However, there is a small change in TR4 and TR5 which indicates that specific entity behaviour can be altered — it’s called //OCB//. It was briefly described in [[meshes_models# | + | However, there is a small change in TR4 and TR5 which indicates that specific entity behaviour can be altered — it’s called //OCB//. It was briefly described in [[trs:meshes_models# |
Sometimes OCB is interpreted as a “packed” field with several values incorporated — like teeth spike OCB contain information about their horizontal and vertical orientation, | Sometimes OCB is interpreted as a “packed” field with several values incorporated — like teeth spike OCB contain information about their horizontal and vertical orientation, | ||
- | > **Tip** | + | <note tip> |
- | > | + | For list of valid entity OCBs in TR4, you may refer to TRLE User’s Manual, although it was written in a big rush, and thus it lacks many existing OCBs for many entities. There are also fan-made OCB lists which are much more comprehensive. |
- | > For list of valid entity OCBs in TR4, you may refer to TRLE User’s Manual, although it was written in a big rush, and thus it lacks many existing OCBs for many entities. There are also fan-made OCB lists which are much more comprehensive. | + | |
- | > | + | As for TR5, no proper OCB list exists for its entity types, so it may be considered a big unknown. |
- | > As for TR5, no proper OCB list exists for its entity types, so it may be considered a big unknown. | + | </ |
However, OCB can’t be seriously called “scripting”, | However, OCB can’t be seriously called “scripting”, | ||
- | > **Note** | + | <note> |
- | > | + | Recent patches for TR4 game engine (used to play custom levels), like //TREP// and //TRNG//, feature some kind of basic scripting functionality. However, there’s still no sign of //real scripting language// in them, and such scripting is basically specifying pre-defined variables to alter entity behaviour, just like OCB does. |
- | > Recent patches for TR4 game engine (used to play custom levels), like //TREP// and //TRNG//, feature some kind of basic scripting functionality. However, there’s still no sign of //real scripting language// in them, and such scripting is basically specifying pre-defined variables to alter entity behaviour, just like OCB does. | + | </ |
===== Pathfinding ===== | ===== Pathfinding ===== | ||
Line 53: | Line 55: | ||
This is presumably the way //TRLE// creates boxes for each level: | This is presumably the way //TRLE// creates boxes for each level: | ||
- | * For each sector, extend one axis until a height difference is reached. | + | |
- | * Then extend this row (or column) perpendicular until another height difference is reached. This is a rectangle with the same height and it //defines a box//. | + | * Then extend this row (or column) perpendicular until another height difference is reached. This is a rectangle with the same height and it //defines a box//. |
- | * Do the same with the other axis first, and you get another box. | + | * Do the same with the other axis first, and you get another box. |
- | * Repeat this process for every sector, maybe extending into neighbor rooms through the portals. | + | * Repeat this process for every sector, maybe extending into neighbor rooms through the portals. |
- | * Make sure that there are no any duplicate | + | * Make sure that there are no any duplicate boxes. |
- | + | ||
- | On a per-room basis, we can have up to 14 boxes. | + | |
There are two variations of box structure — one for TR1 and another for TR2 and any other game version. | There are two variations of box structure — one for TR1 and another for TR2 and any other game version. | ||
Line 87: | Line 87: | ||
}; | }; | ||
</ | </ | ||
- | In '' | + | The '' |
=== Overlaps === | === Overlaps === | ||
Line 155: | Line 155: | ||
Since TR3, in addition to pathfinding data structures, there are now special //AI objects//, which are used in a node-like manner, defining specific action, like wandering between two points, guarding specific point or running to specific place in case Lara is around. For example, MP Guards in TR3’s “Area 51” may patrol specific area when they are limited by special // | Since TR3, in addition to pathfinding data structures, there are now special //AI objects//, which are used in a node-like manner, defining specific action, like wandering between two points, guarding specific point or running to specific place in case Lara is around. For example, MP Guards in TR3’s “Area 51” may patrol specific area when they are limited by special // | ||
- | > **Note** | + | <note> |
- | > | + | Not every NPC is “taught” to work with AI objects — usually, |
- | > Not every NPC is “taught” to work with AI objects — usually, | + | </ |
Specific set of AI objects and their respective entity type IDs are different across game versions, but types themselves largely remained unchanged from TR3 to TR5. Here are they: | Specific set of AI objects and their respective entity type IDs are different across game versions, but types themselves largely remained unchanged from TR3 to TR5. Here are they: | ||
Line 167: | Line 167: | ||
* **AI_FOLLOW** — Used primarily with friendly NPCs, and makes them wait for Lara and then “lead” her to specific point. For such behaviour, one AI_FOLLOW object must be placed in the same sector as NPC, and second AI_FOLLOW object must be placed on target point. If Lara shoots NPC affected with AI_FOLLOW behaviour, he will abandon it and become hostile. | * **AI_FOLLOW** — Used primarily with friendly NPCs, and makes them wait for Lara and then “lead” her to specific point. For such behaviour, one AI_FOLLOW object must be placed in the same sector as NPC, and second AI_FOLLOW object must be placed on target point. If Lara shoots NPC affected with AI_FOLLOW behaviour, he will abandon it and become hostile. | ||
- | > **Note** | + | <note> |
- | > | + | If there is a HEAVYTRIGGER under an AI_AMBUSH or AI_PATROL object, the enemy will activate it only when he gets there. |
- | > If there is a HEAVYTRIGGER under an AI_AMBUSH or AI_PATROL object, the enemy will activate it only when he gets there. | + | </ |
{{: | {{: | ||
Line 192: | Line 192: | ||
==== AI Data Block in TR4-5 ==== | ==== AI Data Block in TR4-5 ==== | ||
- | Beginning with TR4, AI objects are //not kept along with other entities//. Instead, they have their own structure, which is basically simplified [[meshes_models# | + | Beginning with TR4, AI objects are //not kept along with other entities//. Instead, they have their own structure, which is basically simplified [[trs:meshes_models# |
The format of AI object structure as follows: | The format of AI object structure as follows: |