Deep NPC reactions are statements of friendly NPCs and hostile creatures that are tailored to the progress of the individual player. Also, you can give NPCs a memory to react according to the past experience with the player.
How nice would it be, when the gnoll bandit says to the player: “Do you think a new weapon will help you?”. Or when the merchant greets you with: “Long time no see, old fellow!”. And these statements wouldn´t be empty standard phrases, yet truly tailored to the individual player. The player really has a different weapon compared to the last time when attacking that gnoll. The player really met that merchant a long time ago. That´s powerful immersion.
Table of contents
- NPC reactions are a powerful immersion device
- Only vocal NPCs react
- Player properties feed deep NPC reactions
- Loot tables
- Text tables to generate deep NPC reactions
- Effort of creating text tables
NPC reactions are a powerful immersion device
While the world in MMORPGs is static, the NPCs´ “mind” is not. The relation of NPCs to the player is a powerful immersion device. It can be used for individual storytelling.
The most basic NPC reaction system that is in place in every MMORPG is the friend-foe system. Another common mechanic is to give NPCs a number of statements that are randomly or sequentially released. A third common structure is a reputation system that unlocks rewarding trade interactions with a mob when certain conditions are met.
We want to extend these systems in a way that the statements of NPCs are tailored to the progress of the individual player and the experience of the NPC with that player.
Requirement: unique ID for NPCs
The presented system demands that each NPC has a unique ID. Also, NPCs respawn after death with the same ID. For instance, at the river under the oak tree, there are always these three sheep with the ID 1205, 1209, and 1145.
While NPCs are not immortal, the need to be a static part of the world. That means, after death they need to respawn with their same unique ID at the same place.
Only Vocal NPCs react
Only a fraction of NPCs in MMORPGs are able or willing to talk to the player. Let´s call this fraction the vocal NPCs.
Friendly encounter events
Among these vocal NPCs are the friendly ones: merchants, trainers, guards, and so on. What encounter events do friendly vocal NPCs´ have with the player. When:
- contacted (clicked) by the player
- action performed (buying, selling, training, giving an answer)
Hostile encounter events
Also, there are the hostile NPCs: the creatures that can also come vocal. They interact with players in a different way. Yet, there are standard situations that vocal creatures share with players. These encounter events are:
- start of battle
- creature dying from battle with the player involved
- creature reaching a particular battle phase
- player retreating from battle with the creature
You might come up with different encounter events for your game.
Player properties feed deep NPC reactions
There are countless possible player properties, an NPC can react to:
- avatar level
- avatar gear level
- time of day
- avatar wealth
- equipped weapon category
- crafting level
- quest [x] started
- quest [x] finished
- many more…
Current properties are straightforward a value that can be retrieved from the current avatar.
To go beyond immediate reactions, NPCs need a memory. Such a memory stores player status after an NPC encounter. When the same NPC is encountered again, the difference of the current player status with the stored player status is retrieved.
History properties can be the same as current properties. For instance, instead of the current avatar level, the corresponding history property is:
[history property of avatar level] = [current avatar level] - [avatar level when last encountered by this NPC]
So, the history property is generated as a difference from stored data and current data.
Where are properties stored
History properties are not stored with the NPCs. Rather, each player stores his history properties together with the NPC´s unique ID.
What properties are stored
Each NPC has a different selection of properties. You don´t need to store properties for an NPC that this NPC won´t use. Each NPC provides a method that tells players what properties are stored for a particular event. How does this method work? By parsing the text tables of the NPC for this event.
When are properties stored
History properties are updated for friendly NPCs when the player closes the interaction window, and for hostile creatures when the player leaves combat.
To explain how NPCs produce an individual reaction, we need to understand how text tables work. They work almost like loot tables. Instead of loot, they give text. Well, now we simply need to understand how loot tables work? For a very good long explanation read here. For a short version, continue reading.
A loot table holds two columns:
- a weight that gives the chance of getting the entry
- an entry
So when it´s time to give loot, the server sums up all weights.
|50||common lizard loot [loot table]|
|20||rare lizard loot [loot table]|
|300||lizard scale shield|
In the present example, the sum weight of Morlock´s loot table is 470. To estimate loot, the sever bothers a random number generator for a number between 0 and 470. The following results are possible. A number between:
- 0 and 100: no loot
- 101 and 150: roll again on the common lizard loot table
- 151 and 170: roll again on the rare lizard loot table
- 171 and 470: the lizard scale shield
Loot tables are powerful due to their hierarchic nature and due to their flexibility. Both are needed for text tables.
Text tables to generate deep NPC reactions
Text tables come in the form of event tables and property tables. Event tables handle a particular event. They can contain an unrestricted number of property tables. In a tree-like manner property tables itself can contain more property tables.
When processing such table trees, limit the number of iterations to prevent deadlocks by circular references.
We already know that text tables work like loot tables, yet handing out text instead of loot.
Each vocal NPC has a text table for each encounter event. Morlock, the named lizard actually can speak and likes to comment about the player´s weapon at the beginning of a battle. His “start of battle” event text table looks this way:
|10||don´t say anything|
|100||Morlock battle-start avatar-level-difference [property table]|
|100||Morlock battle-start time-since-last-encounter [property table]|
|100||Morlock battle-start current-avatar-level [property table]|
|400||Morlock battle-start current-weapon-category [property table]|
Morlock can say nothing, or “GRRRRRMMML”, or something specific that is calculated with a property table.
Each property table has an additional column that contains a requirement. Actually, they have two requirement columns to allow more complex conditions to be tested. For instance, number ranges need two checks: x > 100 AND x < 200.
A requirement tells whether the entry in the property table is suitable to the player in the current situation. Requirements are checked against the particular property of the table. For instance, on a level table, the two requirements check against the retrieved level value of the player.
|true||< 0||10||You seem weaker today!|
|true||== 0||100||Come and meet my claws!|
|true||== 0||200||I am hungry!|
|> 0||<= 3||100||My claws can still hurt you!|
|> 0||<= 3||350||You again? And even stronger!|
|true||> 3||50||That´s unfair. You are very much stronger!|
|true||> 3||20||You trained hard!|
At a specific encounter, the tables of the NPC are fed with the player´s properties for this particular NPC.
The requirements in the table filter the available selections. It is good practice to create the requirements in a way that always at least one requirement is met. Therefore, a property table will always give a meaningful result.
Effort of creating text tables
The effort to create text tables seems gigantic. For each NPC there are 3 to 4 encounter events. For each event, there are 4 to 5 dimensions. Those are 12 to 20 tables with a dozen or more entries each, so about 240 entries for a single NPC category.
An average MMO has 300 to 500 creature categories and 500 to 1000 NPCs, so we are at 192.000 to 500.000 entries. And that’s the most minimal version.
Don´t worry, these numbers are wrong. Text tables, similar to loot tables, are hierarchical and work by reference. That means you can start small. For instance, you can create a fine merchant greetings table that is used by every merchant.
At any time, you can decide to individualize the reaction of a particular merchant by adding specific entries that have a higher weight. Or maybe you decide to add a specific table with a higher weight. Or you use the same tables, yet change the weights for them, so that a bag merchant always comments on the wealth.
The possibilities and flexibility are unlimited. Some examples:
- Even single creatures and not only creature categories can have specific reactions. Among 10 sheep there can be that one that has a story to tell.
- Thinking of NPC reactions doesn´t need high skills or long training. Rather, good imagination and a witty mind. So why not ask your players for ideas to enrich the world.
- tables with requirements can realize complex reactions. One word: LISP.
Vocal NPCs can react according to the current player status and/or to the difference of the current player status to the player status of the last encounter. This behaviour gives NPCs a memory. Also, NPCs can tell “their story” piece by piece each time they encounter the player.
Player properties and the information about their encounters with NPCs are stored with the player data and given to NPCs in an encounter.
Text tables generate appropriate NPC statements with a random factor, in a way similar to loot generation. Text tables are highly flexible and allow to start with minimal effort.
Loot tables are useful in many ways.
(Last Updated on May 1, 2021)