PSwiki - User contributions [en]

Tribe Scripting

2011-09-22T15:03:59Z

Zee: Added info about recipe logic

= Recipe Logic =

== Recipes ==
'''A recipe database entry'''
{| border="1"
!id
!name
!requirements
!algorithm
!persistent
|-
|used for db storing
|Name of the recipe
|requirement string containing all requirements
|algorithm string containing all algorithm steps
|If this flag is on, the recipe won't ever be deleted from the recipe tree. After parsing it, if no other recipe has a higher priority... it will be reparsed.
|}

== Usage of Recipes ==

On tribe initialization, a tribal recipe is first loaded in respect of the information indicated by the 'tribal_recipe' field. (see tribes.sql). The tribal recipe is formed from 'Tribe Info' functions. (see below)

Based on those functions the npctype for each tribe is created and initial recipes are loaded.

Further on, each Recipe has two important sections: requirements and algorithm. Each of those two is represented by a long string (the maximum is set in the database to 1000 characters) of functions separated by a semi-colon ';'. Upon parsing the long string is split in respect of the semicolons (;) and the recipe manager analyzes each resulting function.

== Recipe-Tree Nodes ==

Inside a tribe object, recipes are stored as Recipe Tree Nodes. This class was created to facilitate the management of recipes and the way recipes are selected to be parsed.

All recipes are stored as leaves in a tree. This way we can always know their hierarchy and precedence.

Besides the obvious usage as a tree, recipe tree nodes also hold vital data for recipe parsing: last requirement parsed, last algorithm step parsed, remaining waiting time.

Let's consider an example of a tribe which has some building spots available and the task to build on those spots.

<uml>
scale 0.8
TribalRecipe *-- BuildingSpots
TribalRecipe *-- ThreeBuildings
ThreeBuildings *-- Breed : Not enough members
Breed *-- GatherFood : Not enough food
ThreeBuildings *-- GatherWood: Not enough wood
ThreeBuildings *-- GatherStone: Not enough stone
ThreeBuildings *-- LearnMasonry : knowledge masonry needed
</uml>

Having the tree above, it's easy to select the actions required to complete the task. We first get some more food. After that we get the required members, search for wood and stone, and finally build the buildings.

= Tribe Info =

== Brain ==

Syntax: brain(x);

Known Arguments: x in { civilised, savage, inhuman }

Effect: Decides the advancement of this tribe. At the moment it acts only as a token. An expression with the same syntax (e.g. "brain(civilised);") can be placed as a requirement.

== Aggressivity ==

Syntax: aggressivity(x);

Known Arguments: x in { warlike, neutral, peaceful }

Effect: Decides the way the tribe reacts to other entities around it's members:
* Warlike -- Attack anything on sight.
* Neutral -- Attack only if members are attacked.
* Peaceful -- If tribe members are attack they flee, trying to escape.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype in respect of this function's argument.

== LoadRecipe ==

Syntax: loadRecipe(x);

Arguments: 'x' is a Recipe Name

Effect: Loads a recipe into the recipe tree. The new recipe's priority will be the current recipe's priority + 1.

== LoadCyclicRecipe ==

Syntax: loadCyclicRecipe(x,t);

Arguments:
* 'x' is a Recipe Name
* 't' is an int, representing the number of ticks between recipe executions

Effect: Loads a recipe into the recipe tree once every 't' ticks, with highest priority.

== SleepPeriod ==

Syntax: sleepPeriod(x);

Arguments: x in { diurnal, nocturnal, nosleep }

Effect: Makes the tribe members sleep at the given period of day.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype. The reaction should react to timeofday perceptions.

= Requirements =

== Tribesman ==

Syntax: tribesman(x,y);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' with the current behavior equal to the tribe's idle behavior. (e.g. "do nothing" behavior) If 'y' members are found idle, the requirement is considered met.

== Resource ==

Syntax: resource(x,y);

Arguments:
* x is the resource name
* y is the resource quantity required

Effect & Mechanics: The tribal object checks for a 'y' quantity of 'x' resource. If this quantity is found then the resource is considered complete.

Judging by the way natural resources are defined, any string declared in natural_resources.sql as a resource can be parsed and mined by the tribe. By default, any new mine found by the tribesmen is stored as a memory named 'mine'. Upon it's first mining action done on the 'mine' memory, a reward is granted to the npc. When the NPC gets home and gives that to the tribal object, the memory 'mine' is renamed after the reward. In conclusion, having a resource named 'Space Shuttle' is valid and works.

Note: The resource requirement just checks if enough resources are available. Use 'alterResource' function in your recipes in order to actually substract resource from the tribe bank.

== Knowledge ==

Syntax: knowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: As described in the [[Tribes]] document, knowledge are tokens that keep track on technologies developed by the tribe. It's valid to request any string as long as it would be possible for the tribe to develop the knowledge. Otherwise the requirement will never be met.

== Item ==

Syntax: item(x,y);

Arguments:
* 'x' is an item/building name.
* 'y' is an int defining the quantity of items needed.

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the item 'x' of quantity 'y'.

== Recipe ==

Syntax: recipe(x,y);

Arguments:
* 'x' is a recipe name.
* 'y' is an int defining the quantity of recipes needed.

Effect & Mechanics: Upon parsing this requirement, the parser just adds an 'y' number of 'x' recipes to the recipe tree.

This requirement isn't quite practical and should be avoided.

== Trader (Not available) ==

Syntax: trader(x);

Arguments:
* 'x' is an item name

Effect: This requirement should check the traders array for a nearby trader giving item 'x'.

== Memory ==

Syntax: memory(x);

Arguments:
* 'x' is a memory name

Effect & Mechanics: Upon parsing this requirement, the parser checks the memory array for a memory called 'x'. If it is found, requirement is considered met.

= Algorithm Steps =

== AlterResource ==

Syntax: alterResource(x,y);

Arguments:
* 'x' is a resource name
* 'y' is an int describing quantity

Effect & Mechanics: Upon parsing this function, the parser modifies the quantity of resources available in the tribe.

Note: The 'y' value will be added to the current value in the tribe's bank. Use negative value to represent costs. (e.g. alterResource(gold,-20); in order to pay for a building)

== AddKnowledge ==

Syntax: addKnowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: Adds the 'x' token as a piece of knowledge in the knowledge array.

== Select ==

Syntax: select(x,y);

Arguments:
* 'x' is a tribe member type.
* 'y' is an int defining the number of members to be selected.

Effect & Mechanics: The 'select' function is probably the most important algorithm step. It selects the members passed as arguments and keeps them in a temporary npc array so they can accept orders from the next algorithm steps. It actually works like selecting units and commanding them in a strategy game. After a 'select' function, all next algorithm steps apply to selected members only, until another 'select' command is issued or the recipe is completed.

Example:
// Will send 3 miners to mine for gold.
select(miner,3);
locate(gold);
mine();

== Locate ==

Syntax: locate(x);

Arguments: 'x' is a memory name.

Effect & Mechanics: This function works like the 'locate operation' from the NPC Scripting. It looks in the tribe's memory array for the memory called 'x' and loads it into the previous selected npc's buffers. It is vital to use it before basic functions like mine,gather,guard,attack that use the npc buffers to execute.

== LocateResource ==

Syntax: locateResource(x);

Arguments: 'x' is a resource name.

Effect & Mechanics: This function works like the above-mentioned 'locate' function. The sole difference is that this function tries to locate resource 'x', and it case it fails it tries to locate memories 'mine' or 'field'. (which are the standard names of unprospected/undiscovered resource zones). In case nor 'mine' or 'field' are found, it sends the previous selected npcs to explore for them.

== LocateBuildingSpot ==

Syntax: locateBuildingSpot(x);

Arguments: 'x' is a building name.

Effect & Mechanics: This functions locates a building spot previously reserved via 'reserveBuildingSpot' function. It searches for in the asset array and uploads it's position in the npc's memory buffers.

== ReserveSpot ==

Syntax: reserveSpot(x,y,z,bname);

Arguments:
* 'x', 'y' and 'z' are coordinates in the same sector as the tribe
* 'bname' is the building name we want to reserve the spot for

Effect & Mechanics: This function is used so the scripter (you) can arrange the future village of the tribe. When creating a tribe, a recipe containing building spots should be wrote in order to pinpoint where building should be constructed in the future.

== GoWork ==

Syntax: goWork(x);

Arguments: 'x' is an int defining the number of seconds the npcs should work for.

Effect & Mechanics: The 'goWork' function sends previously selected npcs to a previously selected location and activates their 'work' behavior on that location for 'x' number of seconds.

== Wait ==

Syntax: wait(x);

Arguments: 'x' is an int defining number of ticks to halt recipe for.

Effect & Mechanics: This function sets the wait time for a recipe. By default, no recipes with a wait time bigger than 0 are reparsed. As a consequence, applying wait time to a recipe will make the parser halt the current recipe at the current algorithm step and parse other recipes that wait in line.

== Mine ==

Syntax: mine();

Arguments: None.

Effect & Mechanics: It sends previously selected members to a previously selected mine and fires their 'mine' behavior.

== Gather ==

Syntax: gather();

Arguments: None.

Effect & Mechanics: It sends previously selected members to a previously selected field and fires their 'gather' behavior.

== Mate ==

Syntax: mate();

Arguments: None.

Effect & Mechanics: It sends previously selected members to their home and fires their 'breed' behavior.

Note: By default, the 'mate' functions requires no resources and has no checks. Use it in a recipe that checks that enough resources for breeding are available.

== Attack ==

Syntax: attack();

Arguments: None.

Effect & Mechanics: It sends previously selected members to attack a previously selected location. If the selected location is not an attackable entity they will simply move there and attack whatever is near.

== Guard ==

Syntax: guard();

Arguments: None.

Effect & Mechanics: It sends previously selected members to guard the selected location. Members will just patrol the area and attack whatever poses a threat.

Tribe Rework

2011-09-22T14:19:50Z

Zee: Blanked the page

Tribe Scripting

2011-09-22T13:52:00Z

Zee: Created page with the function list and short explanations.

= Tribe Info =

== Brain ==

Syntax: brain(x);

Known Arguments: x in { civilised, savage, inhuman }

Effect: Decides the advancement of this tribe. At the moment it acts only as a token. An expression with the same syntax (e.g. "brain(civilised);") can be placed as a requirement.

== Aggressivity ==

Syntax: aggressivity(x);

Known Arguments: x in { warlike, neutral, peaceful }

Effect: Decides the way the tribe reacts to other entities around it's members:
* Warlike -- Attack anything on sight.
* Neutral -- Attack only if members are attacked.
* Peaceful -- If tribe members are attack they flee, trying to escape.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype in respect of this function's argument.

== LoadRecipe ==

Syntax: loadRecipe(x);

Arguments: 'x' is a Recipe Name

Effect: Loads a recipe into the recipe tree. The new recipe's priority will be the current recipe's priority + 1.

== LoadCyclicRecipe ==

Syntax: loadCyclicRecipe(x,t);

Arguments:
* 'x' is a Recipe Name
* 't' is an int, representing the number of ticks between recipe executions

Effect: Loads a recipe into the recipe tree once every 't' ticks, with highest priority.

== SleepPeriod ==

Syntax: sleepPeriod(x);

Arguments: x in { diurnal, nocturnal, nosleep }

Effect: Makes the tribe members sleep at the given period of day.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype. The reaction should react to timeofday perceptions.

= Requirements =

== Tribesman ==

Syntax: tribesman(x,y);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' with the current behavior equal to the tribe's idle behavior. (e.g. "do nothing" behavior) If 'y' members are found idle, the requirement is considered met.

== Resource ==

Syntax: resource(x,y);

Arguments:
* x is the resource name
* y is the resource quantity required

Effect & Mechanics: The tribal object checks for a 'y' quantity of 'x' resource. If this quantity is found then the resource is considered complete.

Judging by the way natural resources are defined, any string declared in natural_resources.sql as a resource can be parsed and mined by the tribe. By default, any new mine found by the tribesmen is stored as a memory named 'mine'. Upon it's first mining action done on the 'mine' memory, a reward is granted to the npc. When the NPC gets home and gives that to the tribal object, the memory 'mine' is renamed after the reward. In conclusion, having a resource named 'Space Shuttle' is valid and works.

Note: The resource requirement just checks if enough resources are available. Use 'alterResource' function in your recipes in order to actually substract resource from the tribe bank.

== Knowledge ==

Syntax: knowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: As described in the [[Tribes]] document, knowledge are tokens that keep track on technologies developed by the tribe. It's valid to request any string as long as it would be possible for the tribe to develop the knowledge. Otherwise the requirement will never be met.

== Item ==

Syntax: item(x,y);

Arguments:
* 'x' is an item/building name.
* 'y' is an int defining the quantity of items needed.

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the item 'x' of quantity 'y'.

== Recipe ==

Syntax: recipe(x,y);

Arguments:
* 'x' is a recipe name.
* 'y' is an int defining the quantity of recipes needed.

Effect & Mechanics: Upon parsing this requirement, the parser just adds an 'y' number of 'x' recipes to the recipe tree.

This requirement isn't quite practical and should be avoided.

== Trader (Not available) ==

Syntax: trader(x);

Arguments:
* 'x' is an item name

Effect: This requirement should check the traders array for a nearby trader giving item 'x'.

== Memory ==

Syntax: memory(x);

Arguments:
* 'x' is a memory name

Effect & Mechanics: Upon parsing this requirement, the parser checks the memory array for a memory called 'x'. If it is found, requirement is considered met.

= Algorithm Steps =

== AlterResource ==

Syntax: alterResource(x,y);

Arguments:
* 'x' is a resource name
* 'y' is an int describing quantity

Effect & Mechanics: Upon parsing this function, the parser modifies the quantity of resources available in the tribe.

Note: The 'y' value will be added to the current value in the tribe's bank. Use negative value to represent costs. (e.g. alterResource(gold,-20); in order to pay for a building)

== AddKnowledge ==

Syntax: addKnowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: Adds the 'x' token as a piece of knowledge in the knowledge array.

== Select ==

Syntax: select(x,y);

Arguments:
* 'x' is a tribe member type.
* 'y' is an int defining the number of members to be selected.

Effect & Mechanics: The 'select' function is probably the most important algorithm step. It selects the members passed as arguments and keeps them in a temporary npc array so they can accept orders from the next algorithm steps. It actually works like selecting units and commanding them in a strategy game. After a 'select' function, all next algorithm steps apply to selected members only, until another 'select' command is issued or the recipe is completed.

Example:
// Will send 3 miners to mine for gold.
select(miner,3);
locate(gold);
mine();

== Locate ==

Syntax: locate(x);

Arguments: 'x' is a memory name.

Effect & Mechanics: This function works like the 'locate operation' from the NPC Scripting. It looks in the tribe's memory array for the memory called 'x' and loads it into the previous selected npc's buffers. It is vital to use it before basic functions like mine,gather,guard,attack that use the npc buffers to execute.

== LocateResource ==

Syntax: locateResource(x);

Arguments: 'x' is a resource name.

Effect & Mechanics: This function works like the above-mentioned 'locate' function. The sole difference is that this function tries to locate resource 'x', and it case it fails it tries to locate memories 'mine' or 'field'. (which are the standard names of unprospected/undiscovered resource zones). In case nor 'mine' or 'field' are found, it sends the previous selected npcs to explore for them.

== LocateBuildingSpot ==

Syntax: locateBuildingSpot(x);

Arguments: 'x' is a building name.

Effect & Mechanics: This functions locates a building spot previously reserved via 'reserveBuildingSpot' function. It searches for in the asset array and uploads it's position in the npc's memory buffers.

== ReserveSpot ==

Syntax: reserveSpot(x,y,z,bname);

Arguments:
* 'x', 'y' and 'z' are coordinates in the same sector as the tribe
* 'bname' is the building name we want to reserve the spot for

Effect & Mechanics: This function is used so the scripter (you) can arrange the future village of the tribe. When creating a tribe, a recipe containing building spots should be wrote in order to pinpoint where building should be constructed in the future.

== GoWork ==

Syntax: goWork(x);

Arguments: 'x' is an int defining the number of seconds the npcs should work for.

Effect & Mechanics: The 'goWork' function sends previously selected npcs to a previously selected location and activates their 'work' behavior on that location for 'x' number of seconds.

== Wait ==

Syntax: wait(x);

Arguments: 'x' is an int defining number of ticks to halt recipe for.

Effect & Mechanics: This function sets the wait time for a recipe. By default, no recipes with a wait time bigger than 0 are reparsed. As a consequence, applying wait time to a recipe will make the parser halt the current recipe at the current algorithm step and parse other recipes that wait in line.

== Mine ==

Syntax: mine();

Arguments: None.

Effect & Mechanics: It sends previously selected members to a previously selected mine and fires their 'mine' behavior.

== Gather ==

Syntax: gather();

Arguments: None.

Effect & Mechanics: It sends previously selected members to a previously selected field and fires their 'gather' behavior.

== Mate ==

Syntax: mate();

Arguments: None.

Effect & Mechanics: It sends previously selected members to their home and fires their 'breed' behavior.

Note: By default, the 'mate' functions requires no resources and has no checks. Use it in a recipe that checks that enough resources for breeding are available.

== Attack ==

Syntax: attack();

Arguments: None.

Effect & Mechanics: It sends previously selected members to attack a previously selected location. If the selected location is not an attackable entity they will simply move there and attack whatever is near.

== Guard ==

Syntax: guard();

Arguments: None.

Effect & Mechanics: It sends previously selected members to guard the selected location. Members will just patrol the area and attack whatever poses a threat.

Tribe Design

2011-09-18T21:47:59Z

Zee: /* Runtime */

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
deactivate Tribe
activate Tribe
Tribe -> Tribe : AddCyclicRecipes
deactivate Tribe
loop For each member
alt For NPC's that have the tribe's idle behavior
activate Tribe
Tribe -> Tribe : Get highest priority recipe
deactivate Tribe

Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager

end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

Additionally, tables for extra tribe info need to be created:
*sc_tribe_assets
*sc_tribe_knowledge
*sc_tribe_memories
*sc_tribe_resources

== Tribe day-to-day life ==

Tribe members are normal NPCs. They all expand a base NPCType called 'AbstractTribesman', on which each tribe adds it's own particularities (e.g. when to go to sleep, what to do when they meet a stranger, etc). [[NPC_Behavior_scripting|Read more on NPCTypes]]. The 'AbstractTribesman' contains behaviors that describe generic actions: breeding, gathering, mining, fighting, exploring and working. (trading to be added soon). These generic behaviors use some data buffers to read data from during runtime in order to execute the same behavior on different data. (different mines, different fields, different building places, etc)

Upon parsing recipes, different perceptions are fired on the tribesmen. This process simulates a working society on which a superior entity assigns tasks to the population.

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

= Runtime =

==Step #1 (Loading)==

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*assets from mysql:'sc_tribe_assets'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

==Step #2 (RunTime)==

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top-priority recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
It checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list.
Requirement parsing can be done two ways:
* Distributed Parsing : The parser takes the first requirement and checks it + tries to achieve it. When the same recipe gets parsed again, the parser takes the second requirement (even if the first is still not met) and tries to achieve it. This way, the parser loops through requirements and tries to achieve all in parallel.
* Concentrated Parsing : The parser tries to achieve the first requirement on each recipe parse until it is met. After that it picks the second requirement and applies the same principle.

E.G.: We want our tribe to gain 150 of Coal, Silver, Gold and Platinum.

Using Distributed Parsing:
*Step 1: Assign miner to Coal.
*Step 2: Assign miner to Silver.
*Step 3: Assign miner to Gold.
*Step 4: Assign miner to Platinum.
*Step 5: Assign miner to Coal.
...

Using Concentrated Parsing: (in this example we consider each step gets the tribe 1 quantity of resource)
*Step 1: Assign miner to Coal.
...
*Step 150: Assign miner to Coal.
*Step 151: Assign miner to Silver.
...

==Step #3 (Recipe's Algorithm)==

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs. A complete set of algorithm and requirements functions can be found [[Tribe_Scripting|here]].

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2011-09-18T21:46:35Z

Zee: Added runtime description.

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
deactivate Tribe
activate Tribe
Tribe -> Tribe : AddCyclicRecipes
deactivate Tribe
loop For each member
alt For NPC's that have the tribe's idle behavior
activate Tribe
Tribe -> Tribe : Get highest priority recipe
deactivate Tribe

Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager

end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

Additionally, tables for extra tribe info need to be created:
*sc_tribe_assets
*sc_tribe_knowledge
*sc_tribe_memories
*sc_tribe_resources

== Tribe day-to-day life ==

Tribe members are normal NPCs. They all expand a base NPCType called 'AbstractTribesman', on which each tribe adds it's own particularities (e.g. when to go to sleep, what to do when they meet a stranger, etc). [[NPC_Behavior_scripting|Read more on NPCTypes]]. The 'AbstractTribesman' contains behaviors that describe generic actions: breeding, gathering, mining, fighting, exploring and working. (trading to be added soon). These generic behaviors use some data buffers to read data from during runtime in order to execute the same behavior on different data. (different mines, different fields, different building places, etc)

Upon parsing recipes, different perceptions are fired on the tribesmen. This process simulates a working society on which a superior entity assigns tasks to the population.

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

= Runtime =

'''Step #1 (Loading)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*assets from mysql:'sc_tribe_assets'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top-priority recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
It checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list.
Requirement parsing can be done two ways:
* Distributed Parsing : The parser takes the first requirement and checks it + tries to achieve it. When the same recipe gets parsed again, the parser takes the second requirement (even if the first is still not met) and tries to achieve it. This way, the parser loops through requirements and tries to achieve all in parallel.
* Concentrated Parsing : The parser tries to achieve the first requirement on each recipe parse until it is met. After that it picks the second requirement and applies the same principle.

E.G.: We want our tribe to gain 150 of Coal, Silver, Gold and Platinum.

Using Distributed Parsing:
*Step 1: Assign miner to Coal.
*Step 2: Assign miner to Silver.
*Step 3: Assign miner to Gold.
*Step 4: Assign miner to Platinum.
*Step 5: Assign miner to Coal.
...

Using Concentrated Parsing: (in this example we consider each step gets the tribe 1 quantity of resource)
*Step 1: Assign miner to Coal.
...
*Step 150: Assign miner to Coal.
*Step 151: Assign miner to Silver.
...

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs. A complete set of algorithm and requirements functions can be found [[Tribe_Scripting||here]].

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2011-09-18T21:20:20Z

Zee: /* Tribe day-to-day life */

Tribe Design

2011-09-18T12:45:58Z

Zee: /* Setting up tribes */

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
deactivate Tribe
activate Tribe
Tribe -> Tribe : AddCyclicRecipes
deactivate Tribe
loop For each member
alt For NPC's that have the tribe's idle behavior
activate Tribe
Tribe -> Tribe : Get highest priority recipe
deactivate Tribe

Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager

end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

Additionally, tables for extra tribe info need to be created:
*sc_tribe_assets
*sc_tribe_knowledge
*sc_tribe_memories
*sc_tribe_resources

== Tribe day-to-day life ==

=== Behaviour ===
A tribe has a set of needs, which are nothing, explore, dig, reproduce and walk. These needs are increased by a rate set in the code for now. When a need is activated, it may also trigger a perception for the next npc.

Tribe members are ordinary [[NPC Types|NPCs]], with an additional set of [[Behavior Operations]] and perceptions to be used in [[Behaviors_and_Reactions|Reactions]]. These perceptions are defined by the needs defined in the tribe_needs table and might be:

* tribe:explore
* tribe:dig
* tribe:reproduce (should result in a reproduce op).
* tribe:resurrect
* tribe:guard
* Or anything else

=== Reproduction ===
The reproduction need will only increase if the number of tribe members is below the maximum. When reproduction is triggered, the tribe resources are decreased by reproduction_cost and the next NPC receives the tribe:reproduce perception. If the NPC then performs the reproduce op, it causes a server-side clone. Everything is cloned and the new cloned NPC will be a member of the tribe.

=== Resurrection ===
When a member dies, it will be resurrected according to the tribe need and will also take a reproduction_cost. However, no cloning will take place.

=== Resources ===
A tribe member can be set to use the [[Behavior_Operations#Locate_Operation|Transfere Operation]] to locate the memory of a tribe resource and use the [[Behavior_Operations#Locate_Operation|Dig Operation]] or [[Behavior_Operations#Locate_Operation|Harvest Operation]] to get resources when for example a ''tribe:harvest'' perception is triggered. The [[Behavior_Operations#Locate_Operation|Transfere Operation]] needs to be used when the npc is back home to transfer it to the tribe.

=== Locations ===
The tribe:resource and tribe:home locations can be used with tribe members. For example in the [[Behavior_Operations#Locate_Operation|Locate Operation]].

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

[[Category:Engine documents]] [[Category:NPCClient Design]]

TribesTable

2011-09-18T12:15:17Z

Zee:

{| border="1"
|-
! field
! type
! foreign key
! description
|-
| id
| integer
|
|
|-
| name
| varchar
|
|
|-
| home_sector_id
| integer
|
|
|-
| home_x
| real
|
|
|-
| home_y
| real
|
|
|-
| home_z
| real
|
|
|-
| home_radius
| real
|
|
|-
| max_size
| integer
|
|
|-
| wealth_resource_name
| varchar
|
|
|-
| wealth_resource_nick
| varchar
|
|
|-
| wealth_resource_area
| varchar
|
|
|-
| reproduction_cost
| integer
|
|
|-
| tribal_recipe
| integer
|
|
|}

[[Category:Engine documents]]

{|
!Field
!type
!Description
|-
|id
|int
|The ID of the tribe.
|-
|name
|string
|The name of the tribe.
|-
|home_sector_id
|int
|The ID of the sector where the tribe home is located
|-
|home_x
|float
|X-coordinate of the tribe home location
|-
|home_y
|float
|Y-coordinate of the tribe home location
|-
|home_z
|float
|Z-coordinate of the tribe home location
|-
|home_radius
|float
|The radius of the tribe home
|-
|max_size
|int
|The maximum number of tribe memers allowed for this tribe.
|-
|wealth_resource_name
|string
|Name of the resource this tribe treasures most. Collecting this will enable growth capability in the tribe.
|-
|wealth_resource_nick
|string
|Commands like dig use the nick of the resource instead of the name.
|-
|wealth_resource_area
|string
|The name of the Location Type that represents location where the wealth resource might be found.
|-
|wealth_gather_need
|string
|The name of the tribe need that will enable collection of wealth resources. Made the primary need when the tribe has dead members.
|-
|wealth_resource_growth
|float
|When there are no members of the tribe we need a push of resources at this rate to enable reproduction.
|-
|reproduction_cost
|int
|The cost to reproduce.
|-
|tribal_recipe
|int
|the id of the tribal recipe to load on each npcclient startup
|}

Tribe Design

2011-09-18T12:13:31Z

Zee: /* Setting up tribes */

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
deactivate Tribe
activate Tribe
Tribe -> Tribe : AddCyclicRecipes
deactivate Tribe
loop For each member
alt For NPC's that have the tribe's idle behavior
activate Tribe
Tribe -> Tribe : Get highest priority recipe
deactivate Tribe

Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager

end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

== Tribe day-to-day life ==

=== Behaviour ===
A tribe has a set of needs, which are nothing, explore, dig, reproduce and walk. These needs are increased by a rate set in the code for now. When a need is activated, it may also trigger a perception for the next npc.

Tribe members are ordinary [[NPC Types|NPCs]], with an additional set of [[Behavior Operations]] and perceptions to be used in [[Behaviors_and_Reactions|Reactions]]. These perceptions are defined by the needs defined in the tribe_needs table and might be:

* tribe:explore
* tribe:dig
* tribe:reproduce (should result in a reproduce op).
* tribe:resurrect
* tribe:guard
* Or anything else

=== Reproduction ===
The reproduction need will only increase if the number of tribe members is below the maximum. When reproduction is triggered, the tribe resources are decreased by reproduction_cost and the next NPC receives the tribe:reproduce perception. If the NPC then performs the reproduce op, it causes a server-side clone. Everything is cloned and the new cloned NPC will be a member of the tribe.

=== Resurrection ===
When a member dies, it will be resurrected according to the tribe need and will also take a reproduction_cost. However, no cloning will take place.

=== Resources ===
A tribe member can be set to use the [[Behavior_Operations#Locate_Operation|Transfere Operation]] to locate the memory of a tribe resource and use the [[Behavior_Operations#Locate_Operation|Dig Operation]] or [[Behavior_Operations#Locate_Operation|Harvest Operation]] to get resources when for example a ''tribe:harvest'' perception is triggered. The [[Behavior_Operations#Locate_Operation|Transfere Operation]] needs to be used when the npc is back home to transfer it to the tribe.

=== Locations ===
The tribe:resource and tribe:home locations can be used with tribe members. For example in the [[Behavior_Operations#Locate_Operation|Locate Operation]].

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2011-09-18T12:02:32Z

Zee: /* Advance Sequence */

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
deactivate Tribe
activate Tribe
Tribe -> Tribe : AddCyclicRecipes
deactivate Tribe
loop For each member
alt For NPC's that have the tribe's idle behavior
activate Tribe
Tribe -> Tribe : Get highest priority recipe
deactivate Tribe

Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager

end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 2 main database tables that need to be populated.

* [[TribesTable]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_needs
** Each row is a need associated with a tribe
** Consists of: type, name, perception, depend, need_start_value,need_growth_value, arguments

== Tribe day-to-day life ==

=== Behaviour ===
A tribe has a set of needs, which are nothing, explore, dig, reproduce and walk. These needs are increased by a rate set in the code for now. When a need is activated, it may also trigger a perception for the next npc.

Tribe members are ordinary [[NPC Types|NPCs]], with an additional set of [[Behavior Operations]] and perceptions to be used in [[Behaviors_and_Reactions|Reactions]]. These perceptions are defined by the needs defined in the tribe_needs table and might be:

* tribe:explore
* tribe:dig
* tribe:reproduce (should result in a reproduce op).
* tribe:resurrect
* tribe:guard
* Or anything else

=== Reproduction ===
The reproduction need will only increase if the number of tribe members is below the maximum. When reproduction is triggered, the tribe resources are decreased by reproduction_cost and the next NPC receives the tribe:reproduce perception. If the NPC then performs the reproduce op, it causes a server-side clone. Everything is cloned and the new cloned NPC will be a member of the tribe.

=== Resurrection ===
When a member dies, it will be resurrected according to the tribe need and will also take a reproduction_cost. However, no cloning will take place.

=== Resources ===
A tribe member can be set to use the [[Behavior_Operations#Locate_Operation|Transfere Operation]] to locate the memory of a tribe resource and use the [[Behavior_Operations#Locate_Operation|Dig Operation]] or [[Behavior_Operations#Locate_Operation|Harvest Operation]] to get resources when for example a ''tribe:harvest'' perception is triggered. The [[Behavior_Operations#Locate_Operation|Transfere Operation]] needs to be used when the npc is back home to transfer it to the tribe.

=== Locations ===
The tribe:resource and tribe:home locations can be used with tribe members. For example in the [[Behavior_Operations#Locate_Operation|Locate Operation]].

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2011-09-16T14:21:23Z

Zee: /* Classes */

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the hart of the Tribe system. The NPCClient will advance the brain 4 times a second. If some NPCs don't have task the Tribe will select a new task and Trigger a perception to start one of the NPCs behaviors.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
activate Tribe
Tribe <-- Tribe
deactivate Tribe
loop For each member
alt For NPC's that "do nothing"
Tribe -> Tribe : Brain
activate Tribe

Tribe -> Tribe : GetNeedSet
activate Tribe
Tribe -> NPC : GetTribeMemberType
activate NPC
Tribe <-- NPC
deactivate NPC
Tribe <-- Tribe
deactivate Tribe

Tribe -> NeedSet : UpdateNeed
activate NeedSet
Tribe <-- NeedSet
deactivate NeedSet

Tribe -> NeedSet : CalculateNeed
activate NeedSet
Tribe <-- NeedSet
deactivate NeedSet

Tribe -> TribeNeed : GetNeed
activate TribeNeed
Tribe <-- TribeNeed
deactivate TribeNeed

Tribe <-- Tribe
deactivate Tribe

alt There is a perception
Tribe -> NPC : TriggerEvent
activate NPC
Tribe <-- NPC
deactivate NPC
end
end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 2 main database tables that need to be populated.

* [[TribesTable]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_needs
** Each row is a need associated with a tribe
** Consists of: type, name, perception, depend, need_start_value,need_growth_value, arguments

== Tribe day-to-day life ==

=== Behaviour ===
A tribe has a set of needs, which are nothing, explore, dig, reproduce and walk. These needs are increased by a rate set in the code for now. When a need is activated, it may also trigger a perception for the next npc.

Tribe members are ordinary [[NPC Types|NPCs]], with an additional set of [[Behavior Operations]] and perceptions to be used in [[Behaviors_and_Reactions|Reactions]]. These perceptions are defined by the needs defined in the tribe_needs table and might be:

* tribe:explore
* tribe:dig
* tribe:reproduce (should result in a reproduce op).
* tribe:resurrect
* tribe:guard
* Or anything else

=== Reproduction ===
The reproduction need will only increase if the number of tribe members is below the maximum. When reproduction is triggered, the tribe resources are decreased by reproduction_cost and the next NPC receives the tribe:reproduce perception. If the NPC then performs the reproduce op, it causes a server-side clone. Everything is cloned and the new cloned NPC will be a member of the tribe.

=== Resurrection ===
When a member dies, it will be resurrected according to the tribe need and will also take a reproduction_cost. However, no cloning will take place.

=== Resources ===
A tribe member can be set to use the [[Behavior_Operations#Locate_Operation|Transfere Operation]] to locate the memory of a tribe resource and use the [[Behavior_Operations#Locate_Operation|Dig Operation]] or [[Behavior_Operations#Locate_Operation|Harvest Operation]] to get resources when for example a ''tribe:harvest'' perception is triggered. The [[Behavior_Operations#Locate_Operation|Transfere Operation]] needs to be used when the npc is back home to transfer it to the tribe.

=== Locations ===
The tribe:resource and tribe:home locations can be used with tribe members. For example in the [[Behavior_Operations#Locate_Operation|Locate Operation]].

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2011-09-16T14:20:08Z

Zee: /* Classes */ Added info for each.

= Tribe Design =

The tribe design is done using NPC Behaviors and Recipes. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime to be used like an AI for the tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the hart of the Tribe system. The NPCClient will advance the brain 4 times a second. If some NPCs don't have task the Tribe will select a new task and Trigger a perception to start one of the NPCs behaviors.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
activate Tribe
Tribe <-- Tribe
deactivate Tribe
loop For each member
alt For NPC's that "do nothing"
Tribe -> Tribe : Brain
activate Tribe

Tribe -> Tribe : GetNeedSet
activate Tribe
Tribe -> NPC : GetTribeMemberType
activate NPC
Tribe <-- NPC
deactivate NPC
Tribe <-- Tribe
deactivate Tribe

Tribe -> NeedSet : UpdateNeed
activate NeedSet
Tribe <-- NeedSet
deactivate NeedSet

Tribe -> NeedSet : CalculateNeed
activate NeedSet
Tribe <-- NeedSet
deactivate NeedSet

Tribe -> TribeNeed : GetNeed
activate TribeNeed
Tribe <-- TribeNeed
deactivate TribeNeed

Tribe <-- Tribe
deactivate Tribe

alt There is a perception
Tribe -> NPC : TriggerEvent
activate NPC
Tribe <-- NPC
deactivate NPC
end
end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 2 main database tables that need to be populated.

* [[TribesTable]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_needs
** Each row is a need associated with a tribe
** Consists of: type, name, perception, depend, need_start_value,need_growth_value, arguments

== Tribe day-to-day life ==

=== Behaviour ===
A tribe has a set of needs, which are nothing, explore, dig, reproduce and walk. These needs are increased by a rate set in the code for now. When a need is activated, it may also trigger a perception for the next npc.

Tribe members are ordinary [[NPC Types|NPCs]], with an additional set of [[Behavior Operations]] and perceptions to be used in [[Behaviors_and_Reactions|Reactions]]. These perceptions are defined by the needs defined in the tribe_needs table and might be:

* tribe:explore
* tribe:dig
* tribe:reproduce (should result in a reproduce op).
* tribe:resurrect
* tribe:guard
* Or anything else

=== Reproduction ===
The reproduction need will only increase if the number of tribe members is below the maximum. When reproduction is triggered, the tribe resources are decreased by reproduction_cost and the next NPC receives the tribe:reproduce perception. If the NPC then performs the reproduce op, it causes a server-side clone. Everything is cloned and the new cloned NPC will be a member of the tribe.

=== Resurrection ===
When a member dies, it will be resurrected according to the tribe need and will also take a reproduction_cost. However, no cloning will take place.

=== Resources ===
A tribe member can be set to use the [[Behavior_Operations#Locate_Operation|Transfere Operation]] to locate the memory of a tribe resource and use the [[Behavior_Operations#Locate_Operation|Dig Operation]] or [[Behavior_Operations#Locate_Operation|Harvest Operation]] to get resources when for example a ''tribe:harvest'' perception is triggered. The [[Behavior_Operations#Locate_Operation|Transfere Operation]] needs to be used when the npc is back home to transfer it to the tribe.

=== Locations ===
The tribe:resource and tribe:home locations can be used with tribe members. For example in the [[Behavior_Operations#Locate_Operation|Locate Operation]].

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2011-09-16T13:46:39Z

Zee:

Behaviors and Reactions

2011-08-28T20:17:37Z

Zee: /* Behavior */

As discussed earlier in [[NPC_Behavior_scripting]], any [[NPC Types]] are really simply a collection of behaviors and reactions to events. At the most meta level, all of us fit this definition. How we act and how we respond to stimuli determines everything about our activities over time. Thus it seems sufficient and general to model npc behavior this way also.

Each behavior gets a script made of [[Behavior_Operations]] as documented in the previous sections. For now we will neglect those, however and just talk about the behaviors themselves.

== Example ==
Here is an example of an NPC Type’s behavior/reaction list:

<npctype name="Wanderer">
<behavior name="walk" decay="0" growth="0" initial="50">
<behavior name="turn" completion_decay="100">
<behavior name="fight">
<behavior name="chase" completion_decay="100">
<BR>
<react event="collision" behavior="turn" delta="100" />
<react event="out of bounds" behavior="turn" delta="100" />
<react event="attack" behavior="fight" delta="150" />
<react event="damage" behavior="fight" delta="20" weight="1" />
<react event="target out of range" behavior="chase" delta="0" />
<react event="death" behavior="fight" delta="-1" />
</npctype>

This collection of behaviors and reactions is sufficient to have a basic outdoor wandering monster who will avoid collisions, stay in his boundary region, fight back if attacked and stop attacking if he dies.

=== List of priorities for NPCs ===

Similar to the way the hate list maintains a prioritized list of enemies for each NPC, each NPC also maintains a set of priorities for the list of behaviors in its npctype. The priority list starts out with 0 as the default score, unless an “initial” attribute is specified. (One behavior should have this attribute so the npc has a place to start.) Thus, any “Wanderer” NPC will start with the following priority list:

P-List: walk-50, turn-0, fight-0, chase-0

Thus on startup the NPC will begin by walking and using the operations inside that behavior tag to do something until an event occurs which preempts the behavior by making something else higher priority. For example, if he goes out of bounds, he will get an “out of bounds” perception, which he has a <react> tag for. It says to add 100 points to the “turn” behavior priority, which results in:

P-List: walk-50, turn-100, fight-0, chase-0

So his “walk” behavior is interrupted and the “turn” behavior and script is activated. This script starts running and the npc starts turning. Turning to point back into the boundary region should only take a couple of seconds. When the script complets for this behavior, the “completion_decay” of the behavior kicks in and affects the P-List again:

P-List: walk-50, turn-0, fight-0, chase-0

There are many real-world examples of how “completion_decay” exists in humans. Many actions are the top priority until they are completed, and then one simply doesn’t need to do them anymore. “completion_decay” is modeling that change in priority when an action is performed.

Now that the priority for turn has gone back to 0, “walk” again is the highest priority behavior and the npc starts walking again.

So now the npc is attacked by a player in the forest. “attack” is a perception sent by the server, as discussed in a previous section, and one for which this npctype has a <react> tag, telling him to add 150 to his “fight” priority, resulting in:

P-List: walk-50, turn-0, fight-150, chase-0

So now the npc stops walking and starts his fight behavior, which probably has the <melee> operation in it, using the hate list to fight back against one or more attackers. As the attack progresses, damage perceptions come in. A damage perception of 10HP has a <react> script also, which adds 10 points to the fight priority and also has a “weight” attribute which affects the hate list instead of the behavior list:

P-List: walk-50, turn-0, fight-160, chase-0

Since the fight behavior is already the highest, it might be redundant to keep increasing it like this, but personally I view it as the npc getting more enraged, which means it will take him longer to calm down when he runs out of enemies. The weight=”1” attribute means that the attacker’s hate score will go up by 1*HP.

Now imagine that the attacking player is losing the fight, and decides to run away. Very quickly, the “target out of range” perception will fire, created by the melee operation when the most hated enemy is farther away than the melee_range but within the seek_range. This NPC is scripted to chase after hated enemies if they run away with his <react event=”target out of range”> tag. The “delta” specified of 0 is a special delta which means “Make the named behavior the highest no matter what.” When reactions are coded with 0 deltas, NPCs are really acting like state machines again.

P-List: walk-50, turn-0, fight-160, chase-185 (Highest means at least 25 higher than the next highest to cause a preemption and switch.)

So now the NPC stops attacking and begins chasing the most hated enemy. The <chase> tag has a range specified for the chase to be completed (probably 2m again), so when the npc has caught the player, the chase behavior completion decay hits. The chase behavior has a specified completion decay of 100, but since chase was escalated artificially high by the 0 react, it is restored intead back to its original value.

P-List: walk-50, turn-0, fight-160, chase-0

So the npc stops chasing and resumes fighting the player immediately when he catches him. Now the npc finally kills the player and the fight is over. The “fight” behavior is still the highest one, so the npc keeps looking around for other enemies to fight, such as group members. If none are found, his fight behavior keeps decreasing by 10 points per iteration.
P-List: walk-50, turn-0, fight-160, chase-0
P-List: walk-50, turn-0, fight-150, chase-0
P-List: walk-50, turn-0, fight-140, chase-0
P-List: walk-50, turn-0, fight-130, chase-0
And so on…

Eventually, “walk” behavior becomes the most active again and the npc resumes his wandering of the forest.

The key concepts here are that the NPC constantly maintains a priority list of behaviors and a priority of list of enemies to attack. <react> tags can affect behavior priority, hatelist priority or both.

The interactions of events, behaviors and reactions can become very complex. The npc can be interrupted by an attack while moving, turning or even chasing another player. This priority structure was designed to allow for rich behavior interruption and resumption while having realistic reactions to world events and activities. Hopefully, with the right scripts we can create very life-like npcs that are also efficient on networking and CPU, with emergent behaviors that stay challenging and interesting to players for a long time to come.

== Behavior ==
{|
!Parameter
!Type
!Default
!Description
|-
|name
|string
|Mandatory
|The name of this behavior
|-
|loop
|boolean
|false
|Set to true if this behavior should loop
|-
|decay
|float
|0.0
|The decay rate of this behavior to apply when the behavior is the active one.
|-
|completion_decay
|float
|0.0
|The decay to be applied when this behavior is done. -1 will be all of the current need.
|-
|growth
|float
|0.0
|The growth rate of this behavior to apply when the behavior isn't the active one.
|-
|initial
|float
|0.0
|The initial need for this behavior
|-
|when_dead
|boolean
|false
|Set this to true if this behavior should be possible while dead. [[Behavior Operations#Resurrect_Operation|Resurrect Operation]] will need this.
|-
|resume
|boolean
|false
|Set to true if this behavior should resume after an interrupt.
|-
|min
|float
|none
|Set this attribute if a min need limit should be applied to this behavior.
|-
|max
|float
|none
|Set this attribute if a max need limit should be applied to this behavior.
|-
|auto_memorize
|string,[...,string]
|none
|If set this npc will memorize all perceptions types passed without changing behavior. (can pass keyword 'all' as parameter to auto_memorize all)
|}

Ex: <behavior name="move" decay="0" growth="0" initial="80" loop="yes" resume="yes">
...
</behavior>
<behavior name="chase" decay="1" completion_decay="-1" growth="0" initial="0" >
...
</behavior>

== Reaction ==
{|
!Parameter
!Type
!Default
!Description
|-
|event
|string
|
|The event to react to.
|-
|behavior
|string[,...,string]
|
|The set of behavior to influence if this reaction is triggered.
|-
|delta
|float
|0.0
|Apply a delta value to the need of the affected behavior.
|-
|absolute
|float
|0.0
|Apply a absolute value to the need of the affected behavior.
|-
|range
|float
|0.0
|
|-
|weight
|float
|0.0
|Passed to the perception when the reaction is accepted. Used to alter the HateList of the NPC.
|-
|faction_diff
|int
|0
|Used to match faction perceptions.
|-
|oper
|string
|
|The operator to use when comparing faction perceptions.
|-
|value
|string[,...,string]
|
|Used by some perceptions like time.
|-
|random
|integer[,...,integer]
|
|Used to add some random value to the value array.
|-
|type
|string
|
|The type is different for each perception. A "location sensed" will have the location type as the type.
|-
|active_only
|boolean
|false
|Only influence active behaviors
|-
|inactive_only
|boolean
|false
|Only influence inactive behaviors
|-
|when_dead
|boolean
|false
|Influence behaviors even if the npc is dead.
|-
|when_invisible
|boolean
|false
|Set to true if an invisible NPC should accept this reaction.
|-
|when_invincible
|boolean
|false
|Set to true if an invincible NPC should accept this reaction.
|-
|only_interrupt
|string,[...,string]
|
|If set this event will only be accepted if it can interrupt one and active behavior from this list.
|-
|do_not_interrupt
|string,[...,string]
|
|Set this if this reaction should not interrupt some active behaviors.
|}

The reaction can influence on a behaviors need either as GUARANTIED to execute(no delta or absolute attribute set), DELTA (delta attribute set), or ABSOLUTE ( absolute attribute set).

Ex: <react event="damage" behavior="Fight" delta="20" weight="1" />

Ex: <react event="time" value="16,0,,," random=",5,,," behavior="GoHome" />

This example show a reaction to a time event that will occur between 1600 and 1605. This is archived due to the random property. Each of the values in value represents "Hour,Minute,Year,Month,Day". Any parameter not
set will match every possible combination.

Ex: <react event="location sensed" behavior="ExploreLoc" type="mine" only_interrupt="Explore" />

This example show a reaction to the location sensed perception where location of type mine will interrupt explore operation with the ExploreLoc behavior.

== Perceptions ==

Perceptions it the invisible mechanism that makes reactions act. There are several situations where perceptions are fired. Some are hard coded into the NPCClient. Some are fired as responses to other script elements and the name might be configurable. An example on this is the [[Behavior_Operations#Chase_Operation|Chase Operation]] where the perception name is configured through the operation.

This section try to summarize some of the perceptions available. Though they might as well be documented at all or only through the senders.

=== Events to react to ===

{|
!Perception
!Description
|-
|collision
|description
|-
|out of bounds
|Checks if the NPC is out of bounds of a region defined in sc_npc_definitions and set up in sc_locations
|-
|in bounds
|Checks if the NPC is in bounds of a region defined in sc_npc_definitions and set up in sc_locations
|-
|damage
|description
|-
|attack
|description
|-
|nearby
|description
|-
|target out of range
|description
|-
|death
|description
|}

=== Faction Perceptions ===

This is perception can be filtered on the faction standing between the NPC and the sender. By defining the oper in the
reaction the faction will be compared. Without the factions will not be compared.

{|
!Attribute
!Values
!Description
|-
|
|talk
|Talk preception fired when talked to
|-
|event
|owner anyrange, owner sensed, owner nearby, owner adjacent
|Owner perceptions fired when owner is at different ranges(Will not get player perception if you are the owner).
|-
|
|player anyrange, player sensed, player nearby, player adjacent
|Player perceptions fired when player is at different ranges.
|-
|faction_diff
|integer
|The faction value to compare
|-
|oper
|>,<
|React if grater than or react when less than. If no oper is defined, faction will not be compared.
|}

{|
!Range
!Value
|-
|sensed
|<30
|-
|nearby
|<10
|-
|adjacent
|<4
|}

Ex: <react event="talk" faction_diff="10" oper=">" ... />

This example will only react to talk if the faction difference is more than +10 to the originator of the talk perception.

Ex: <react event="player nearby" ... />

This will allways react when a player is nearby.

=== Item Perceptions ===

This perception is fired whenever a NPC moves into the nearby, adjacent, or sensed range from an item. In the nearby range the item is so close that it can be picked up.

{|
!Attribute
!Values
!Description
|-
|event
|item nearby, item adjacent, item sensed
|The different perception fired that nearby, adjacent, or sensed range.
|-
|}

=== Location Perception ===

This perception is fired whenever a NPC moves into the sensed range of a location.

{|
!Attribute
!Values
!Description
|-
|event
|location perception
|
|-
|type
|''string''
|The location type name of the location sensed.
|}

Ex: <react event="location perception" type="mine" ... />
<react event="location perception" ... />

=== Time Perception ===

This perception is fired every game minute. It allows react to trigger on any combination of game hours, minutes, years, month, days.
{|
!Attribute
!Values
!Description
|-
|event
|time
|
|-
|value
|hours,minutes,years,months,days
|Match 1200 at the 2nd month like this "12,00,,2,"
|}

Ex: <react event="time" value="12,00,,2," ... />

[[Category:Engine documents]]

Behaviors and Reactions

2011-08-28T16:46:23Z

Zee: /* Behavior */ -- Added auto_memorize

As discussed earlier in [[NPC_Behavior_scripting]], any [[NPC Types]] are really simply a collection of behaviors and reactions to events. At the most meta level, all of us fit this definition. How we act and how we respond to stimuli determines everything about our activities over time. Thus it seems sufficient and general to model npc behavior this way also.

Each behavior gets a script made of [[Behavior_Operations]] as documented in the previous sections. For now we will neglect those, however and just talk about the behaviors themselves.

== Example ==
Here is an example of an NPC Type’s behavior/reaction list:

<npctype name="Wanderer">
<behavior name="walk" decay="0" growth="0" initial="50">
<behavior name="turn" completion_decay="100">
<behavior name="fight">
<behavior name="chase" completion_decay="100">
<BR>
<react event="collision" behavior="turn" delta="100" />
<react event="out of bounds" behavior="turn" delta="100" />
<react event="attack" behavior="fight" delta="150" />
<react event="damage" behavior="fight" delta="20" weight="1" />
<react event="target out of range" behavior="chase" delta="0" />
<react event="death" behavior="fight" delta="-1" />
</npctype>

This collection of behaviors and reactions is sufficient to have a basic outdoor wandering monster who will avoid collisions, stay in his boundary region, fight back if attacked and stop attacking if he dies.

=== List of priorities for NPCs ===

Similar to the way the hate list maintains a prioritized list of enemies for each NPC, each NPC also maintains a set of priorities for the list of behaviors in its npctype. The priority list starts out with 0 as the default score, unless an “initial” attribute is specified. (One behavior should have this attribute so the npc has a place to start.) Thus, any “Wanderer” NPC will start with the following priority list:

P-List: walk-50, turn-0, fight-0, chase-0

Thus on startup the NPC will begin by walking and using the operations inside that behavior tag to do something until an event occurs which preempts the behavior by making something else higher priority. For example, if he goes out of bounds, he will get an “out of bounds” perception, which he has a <react> tag for. It says to add 100 points to the “turn” behavior priority, which results in:

P-List: walk-50, turn-100, fight-0, chase-0

So his “walk” behavior is interrupted and the “turn” behavior and script is activated. This script starts running and the npc starts turning. Turning to point back into the boundary region should only take a couple of seconds. When the script complets for this behavior, the “completion_decay” of the behavior kicks in and affects the P-List again:

P-List: walk-50, turn-0, fight-0, chase-0

There are many real-world examples of how “completion_decay” exists in humans. Many actions are the top priority until they are completed, and then one simply doesn’t need to do them anymore. “completion_decay” is modeling that change in priority when an action is performed.

Now that the priority for turn has gone back to 0, “walk” again is the highest priority behavior and the npc starts walking again.

So now the npc is attacked by a player in the forest. “attack” is a perception sent by the server, as discussed in a previous section, and one for which this npctype has a <react> tag, telling him to add 150 to his “fight” priority, resulting in:

P-List: walk-50, turn-0, fight-150, chase-0

So now the npc stops walking and starts his fight behavior, which probably has the <melee> operation in it, using the hate list to fight back against one or more attackers. As the attack progresses, damage perceptions come in. A damage perception of 10HP has a <react> script also, which adds 10 points to the fight priority and also has a “weight” attribute which affects the hate list instead of the behavior list:

P-List: walk-50, turn-0, fight-160, chase-0

Since the fight behavior is already the highest, it might be redundant to keep increasing it like this, but personally I view it as the npc getting more enraged, which means it will take him longer to calm down when he runs out of enemies. The weight=”1” attribute means that the attacker’s hate score will go up by 1*HP.

Now imagine that the attacking player is losing the fight, and decides to run away. Very quickly, the “target out of range” perception will fire, created by the melee operation when the most hated enemy is farther away than the melee_range but within the seek_range. This NPC is scripted to chase after hated enemies if they run away with his <react event=”target out of range”> tag. The “delta” specified of 0 is a special delta which means “Make the named behavior the highest no matter what.” When reactions are coded with 0 deltas, NPCs are really acting like state machines again.

P-List: walk-50, turn-0, fight-160, chase-185 (Highest means at least 25 higher than the next highest to cause a preemption and switch.)

So now the NPC stops attacking and begins chasing the most hated enemy. The <chase> tag has a range specified for the chase to be completed (probably 2m again), so when the npc has caught the player, the chase behavior completion decay hits. The chase behavior has a specified completion decay of 100, but since chase was escalated artificially high by the 0 react, it is restored intead back to its original value.

P-List: walk-50, turn-0, fight-160, chase-0

So the npc stops chasing and resumes fighting the player immediately when he catches him. Now the npc finally kills the player and the fight is over. The “fight” behavior is still the highest one, so the npc keeps looking around for other enemies to fight, such as group members. If none are found, his fight behavior keeps decreasing by 10 points per iteration.
P-List: walk-50, turn-0, fight-160, chase-0
P-List: walk-50, turn-0, fight-150, chase-0
P-List: walk-50, turn-0, fight-140, chase-0
P-List: walk-50, turn-0, fight-130, chase-0
And so on…

Eventually, “walk” behavior becomes the most active again and the npc resumes his wandering of the forest.

The key concepts here are that the NPC constantly maintains a priority list of behaviors and a priority of list of enemies to attack. <react> tags can affect behavior priority, hatelist priority or both.

The interactions of events, behaviors and reactions can become very complex. The npc can be interrupted by an attack while moving, turning or even chasing another player. This priority structure was designed to allow for rich behavior interruption and resumption while having realistic reactions to world events and activities. Hopefully, with the right scripts we can create very life-like npcs that are also efficient on networking and CPU, with emergent behaviors that stay challenging and interesting to players for a long time to come.

== Behavior ==
{|
!Parameter
!Type
!Default
!Description
|-
|name
|string
|Mandatory
|The name of this behavior
|-
|loop
|boolean
|false
|Set to true if this behavior should loop
|-
|decay
|float
|0.0
|The decay rate of this behavior to apply when the behavior is the active one.
|-
|completion_decay
|float
|0.0
|The decay to be applied when this behavior is done. -1 will be all of the current need.
|-
|growth
|float
|0.0
|The growth rate of this behavior to apply when the behavior isn't the active one.
|-
|initial
|float
|0.0
|The initial need for this behavior
|-
|when_dead
|boolean
|false
|Set this to true if this behavior should be possible while dead. [[Behavior Operations#Resurrect_Operation|Resurrect Operation]] will need this.
|-
|resume
|boolean
|false
|Set to true if this behavior should resume after an interrupt.
|-
|min
|float
|none
|Set this attribute if a min need limit should be applied to this behavior.
|-
|max
|float
|none
|Set this attribute if a max need limit should be applied to this behavior.
|-
|auto_memorize
|string,[...,string]
|none
|If set this npc will memorize all perceptions types passed without changing behavior.
|}

Ex: <behavior name="move" decay="0" growth="0" initial="80" loop="yes" resume="yes">
...
</behavior>
<behavior name="chase" decay="1" completion_decay="-1" growth="0" initial="0" >
...
</behavior>

== Reaction ==
{|
!Parameter
!Type
!Default
!Description
|-
|event
|string
|
|The event to react to.
|-
|behavior
|string[,...,string]
|
|The set of behavior to influence if this reaction is triggered.
|-
|delta
|float
|0.0
|Apply a delta value to the need of the affected behavior.
|-
|absolute
|float
|0.0
|Apply a absolute value to the need of the affected behavior.
|-
|range
|float
|0.0
|
|-
|weight
|float
|0.0
|Passed to the perception when the reaction is accepted. Used to alter the HateList of the NPC.
|-
|faction_diff
|int
|0
|Used to match faction perceptions.
|-
|oper
|string
|
|The operator to use when comparing faction perceptions.
|-
|value
|string[,...,string]
|
|Used by some perceptions like time.
|-
|random
|integer[,...,integer]
|
|Used to add some random value to the value array.
|-
|type
|string
|
|The type is different for each perception. A "location sensed" will have the location type as the type.
|-
|active_only
|boolean
|false
|Only influence active behaviors
|-
|inactive_only
|boolean
|false
|Only influence inactive behaviors
|-
|when_dead
|boolean
|false
|Influence behaviors even if the npc is dead.
|-
|when_invisible
|boolean
|false
|Set to true if an invisible NPC should accept this reaction.
|-
|when_invincible
|boolean
|false
|Set to true if an invincible NPC should accept this reaction.
|-
|only_interrupt
|string,[...,string]
|
|If set this event will only be accepted if it can interrupt one and active behavior from this list.
|-
|do_not_interrupt
|string,[...,string]
|
|Set this if this reaction should not interrupt some active behaviors.
|}

The reaction can influence on a behaviors need either as GUARANTIED to execute(no delta or absolute attribute set), DELTA (delta attribute set), or ABSOLUTE ( absolute attribute set).

Ex: <react event="damage" behavior="Fight" delta="20" weight="1" />

Ex: <react event="time" value="16,0,,," random=",5,,," behavior="GoHome" />

This example show a reaction to a time event that will occur between 1600 and 1605. This is archived due to the random property. Each of the values in value represents "Hour,Minute,Year,Month,Day". Any parameter not
set will match every possible combination.

Ex: <react event="location sensed" behavior="ExploreLoc" type="mine" only_interrupt="Explore" />

This example show a reaction to the location sensed perception where location of type mine will interrupt explore operation with the ExploreLoc behavior.

== Perceptions ==

Perceptions it the invisible mechanism that makes reactions act. There are several situations where perceptions are fired. Some are hard coded into the NPCClient. Some are fired as responses to other script elements and the name might be configurable. An example on this is the [[Behavior_Operations#Chase_Operation|Chase Operation]] where the perception name is configured through the operation.

This section try to summarize some of the perceptions available. Though they might as well be documented at all or only through the senders.

=== Events to react to ===

{|
!Perception
!Description
|-
|collision
|description
|-
|out of bounds
|Checks if the NPC is out of bounds of a region defined in sc_npc_definitions and set up in sc_locations
|-
|in bounds
|Checks if the NPC is in bounds of a region defined in sc_npc_definitions and set up in sc_locations
|-
|damage
|description
|-
|attack
|description
|-
|nearby
|description
|-
|target out of range
|description
|-
|death
|description
|}

=== Faction Perceptions ===

This is perception can be filtered on the faction standing between the NPC and the sender. By defining the oper in the
reaction the faction will be compared. Without the factions will not be compared.

{|
!Attribute
!Values
!Description
|-
|
|talk
|Talk preception fired when talked to
|-
|event
|owner anyrange, owner sensed, owner nearby, owner adjacent
|Owner perceptions fired when owner is at different ranges(Will not get player perception if you are the owner).
|-
|
|player anyrange, player sensed, player nearby, player adjacent
|Player perceptions fired when player is at different ranges.
|-
|faction_diff
|integer
|The faction value to compare
|-
|oper
|>,<
|React if grater than or react when less than. If no oper is defined, faction will not be compared.
|}

{|
!Range
!Value
|-
|sensed
|<30
|-
|nearby
|<10
|-
|adjacent
|<4
|}

Ex: <react event="talk" faction_diff="10" oper=">" ... />

This example will only react to talk if the faction difference is more than +10 to the originator of the talk perception.

Ex: <react event="player nearby" ... />

This will allways react when a player is nearby.

=== Item Perceptions ===

This perception is fired whenever a NPC moves into the nearby, adjacent, or sensed range from an item. In the nearby range the item is so close that it can be picked up.

{|
!Attribute
!Values
!Description
|-
|event
|item nearby, item adjacent, item sensed
|The different perception fired that nearby, adjacent, or sensed range.
|-
|}

=== Location Perception ===

This perception is fired whenever a NPC moves into the sensed range of a location.

{|
!Attribute
!Values
!Description
|-
|event
|location perception
|
|-
|type
|''string''
|The location type name of the location sensed.
|}

Ex: <react event="location perception" type="mine" ... />
<react event="location perception" ... />

=== Time Perception ===

This perception is fired every game minute. It allows react to trigger on any combination of game hours, minutes, years, month, days.
{|
!Attribute
!Values
!Description
|-
|event
|time
|
|-
|value
|hours,minutes,years,months,days
|Match 1200 at the 2nd month like this "12,00,,2,"
|}

Ex: <react event="time" value="12,00,,2," ... />

[[Category:Engine documents]]

Zee August 15-August 21

2011-08-22T00:47:00Z

Zee:

First days of this week I mostly read code regarding object spawning in the world. (due some family problems)

At the end of the week I managed to get the building spawning on tribe request working. Also all standard behaviors are done, checked and should work.

At the moment recipes manage all tribe movement and behavior and the tribe can achieve simple tasks. (it should easily achieve any task as long as the scripting functions are used correctly)

This weekend I also changed the way recipes were managed by the tribe. Tribes now use a tree structure (RecipeTreeNode class) to store and prioritize their goals.

Best wishes.

Zee August 15-August 21

2011-08-22T00:46:49Z

Zee:

Zee August 15-August 21

2011-08-22T00:46:35Z

Zee: Created page with 'First days of this week I mostly read code regarding object spawning in the world. (due some family problems) At the end of the week I managed to get the building spawning on tr…'

GSoC weekly reports

2011-08-22T00:41:17Z

Zee:

__NOTOC__

== May ==

Request of weekly reports was sent out the 8th of June, anyway if you have any progress report for May, please post it here.

[[Zhan 16-20]]

== June 6-12 ==

[[Landson June 6-12]]

[[Lucubro June 6-12]]

Zee no report.

== June 13-19 ==

[[Lucubro June 13-19]]

[[Landson June 13-19]]

[[Zhan June 13-19]]

[[Zee June 13-19]]

== June 20-26 ==

[[Lucubro June 20-26]]

[[Landson June 20-26]]

[[Zee June 20-26]]

[[Zhan June 20-26]]

== June 27-July 4 ==

[[Landson June 27-July 4]]

[[Lucubro June 27-July 4]]

[[Zee June 27-July 4]]

[[Zhan June 27-July 4]]

== July 5-11 ==
[[Landson July 5-11]]

[[Lucubro July 5-11]]

[[Zee July 5-11]]

[[Zhan July 5-11]]
== July 12-18 ==
[[Landson July 12-18]]

[[Zhan July 12-18]]

[[Zee July 12-18]]

[[Lucubro July 12-18]]

== July 18-25 ==
[[Landson July 18-25]]

[[Zhan July 18-25]]

[[Lucubro July 18-25]]

Zee no report.

== July 25-31 ==
[[Zhan July 25-31]]

[[Landson July 25-31]]

[[Zee July 25-31]]

Lucubro in vacation.

== July 31-August 7 ==
[[Zee July 31-August 7]]

[[Zhan July 31-August 7]]

[[Lucubro July 25-August 7]]

Landson no report (see next week for summary).

== August 8th - August 15 ==
[[Landson July 31-August 15]]

[[Lucubro August 8-15]]

[[Zee August 8-August 15]]

== August 15 - August 21 ==
[[Zee August 15-August 21]]

Zee August 8-August 15

2011-08-15T20:37:22Z

Zee:

Personally I think it was a good week. I've studied the server - superclient connection a lot to see how actions are triggered.

I've spent the time testing how the tribe behaves based on some simple target recipes (like... acquire 30 members... acquire 100 gold... etc)

I noticed that the former system had the tribe dig automatically for it's wealth. I've changed this and now the tribe explores for resources... and once it finds a mine it prospects it in order to see what's in it. (this is why I studied the network managers and added MSGTYPE_NPC_WORKDONE). Currently, the tribe explores and digs for whatever resource we signal in the recipes.

I've made some tweaks in the NPC code and tribe code in order to attach buffers to each npc. I wanted npcs to have their own buffers in order to remember their targets while working. (E.G. : once they are sent mining, they store their mining place in the NPC class, so the tribe can use it's buffers to keep own data or assign other tasks to other npcs) For this I added some other attributes in npcOperations. I will signal them in the wiki when I update the documentation.

I've added the CMD_SPAWN_BUILDING command. This will be used by the superclient to request a building from the server. I'm working on it atm... probably a MSGTYPE_PERSIST_ITEM will be the response sent to all clients containing the new building. (item dropped on the ground).
As per the location of the buildings... I think I'll use the easy way for now... as in... pre-select the locations for buildings and signal them in recipes.

PS: Various minor changes that I didn't note here can be found as comments on svn commits. They aren't as important on the long run though :)

High regards,
Zee.

Zee August 8-August 15

2011-08-15T20:36:16Z

Zee: Created page with 'Personally I think it was a good week. I've studied the server - superclient connection a lot to see how actions are triggered. I've spent the time testing how the tribe behaves…'

GSoC weekly reports

2011-08-15T20:27:28Z

Zee: /* August 8th - August 15 */

Tribe Rework

2011-08-10T12:00:15Z

Zee: /* Provisional Functions */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
*an array of Assets (see below)

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|sleepPeriod(x)
|tribe info
|{ diurnal, nocturnal, nosleep }
|decides when tribe members should go to sleep... if they should at all
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|memory(x)
|requirement
|x is a memory name
|requires a memory. Especially used when looking for resources... if no memory is available explore for it.
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|mate()
|algorithm step
|none
|sends all selected members a 'tribe:breed' perception
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|addMember(x)
|algorithm step
|x is a member type
|adds a new member of type 'x' to the tribe
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Assets ==

Assets are items and buildings that belong to the tribe. They are held in the 'assets' array (which acts like a bank) in the tribal object.

An Asset data structure contains the following:
*name
*item - a gemNPCItem* that will hold how the item/building looks
*quantity - an int which will hold how many items of a kind the tribe has (used only for items)
*pos - a csVector3 holding the position of the item (used only for buildings)
*building - a boolean value (flagged as true for building entries)

I found that keeping positions & multiple entries for items would prove quite useless... and thought of a better practice to remove all tribal items from the world and keeping them as numbers.

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Zee July 31-August 7

2011-08-08T10:48:31Z

Zee: Created page with 'This week was pretty prolific. I spent the time completing all the gaps left in the code, completing the function list for recipes and making them work. In detail: *coded all re…'

This week was pretty prolific.

I spent the time completing all the gaps left in the code, completing the function list for recipes and making them work.
In detail:
*coded all requirements checks and added actions to do in case they are not met
*added tribe buffers and memory buffers to hold dynamic data between execution of functions, and dynamic data for the execution of behaviors
*added a preparser to allow the usage of buffers and certain variables (like REPRODUCTION_RESOURCE)
*added Assets (tribe buildings & items) and all the methods/mechanics to make it usable. (including sc_tribe_assets)
*added 'fireperc' command in the npcclient for testing purposes.
*varios small changes and fixes :)

Best wishes, Zee.

GSoC weekly reports

2011-08-08T10:38:52Z

Zee:

Tribe Rework

2011-08-07T14:40:08Z

Zee: /* Provisional Functions */ added mate() function

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
*an array of Assets (see below)

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|sleepPeriod(x)
|tribe info
|{ diurnal, nocturnal, nosleep }
|decides when tribe members should go to sleep... if they should at all
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|mate()
|algorithm step
|none
|sends all selected members a 'tribe:breed' perception
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|addMember(x)
|algorithm step
|x is a member type
|adds a new member of type 'x' to the tribe
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Assets ==

Assets are items and buildings that belong to the tribe. They are held in the 'assets' array (which acts like a bank) in the tribal object.

An Asset data structure contains the following:
*name
*item - a gemNPCItem* that will hold how the item/building looks
*quantity - an int which will hold how many items of a kind the tribe has (used only for items)
*pos - a csVector3 holding the position of the item (used only for buildings)
*building - a boolean value (flagged as true for building entries)

I found that keeping positions & multiple entries for items would prove quite useless... and thought of a better practice to remove all tribal items from the world and keeping them as numbers.

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-05T20:03:26Z

Zee: /* Provisional Functions */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
*an array of Assets (see below)

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|sleepPeriod(x)
|tribe info
|{ diurnal, nocturnal, nosleep }
|decides when tribe members should go to sleep... if they should at all
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|addMember(x)
|algorithm step
|x is a member type
|adds a new member of type 'x' to the tribe
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Assets ==

Assets are items and buildings that belong to the tribe. They are held in the 'assets' array (which acts like a bank) in the tribal object.

An Asset data structure contains the following:
*name
*item - a gemNPCItem* that will hold how the item/building looks
*quantity - an int which will hold how many items of a kind the tribe has (used only for items)
*pos - a csVector3 holding the position of the item (used only for buildings)
*building - a boolean value (flagged as true for building entries)

I found that keeping positions & multiple entries for items would prove quite useless... and thought of a better practice to remove all tribal items from the world and keeping them as numbers.

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-05T19:00:19Z

Zee: /* Provisional Functions */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
*an array of Assets (see below)

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|addMember(x)
|algorithm step
|x is a member type
|adds a new member of type 'x' to the tribe
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Assets ==

Assets are items and buildings that belong to the tribe. They are held in the 'assets' array (which acts like a bank) in the tribal object.

An Asset data structure contains the following:
*name
*item - a gemNPCItem* that will hold how the item/building looks
*quantity - an int which will hold how many items of a kind the tribe has (used only for items)
*pos - a csVector3 holding the position of the item (used only for buildings)
*building - a boolean value (flagged as true for building entries)

I found that keeping positions & multiple entries for items would prove quite useless... and thought of a better practice to remove all tribal items from the world and keeping them as numbers.

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-03T22:05:37Z

Zee: added Assets information

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
*an array of Assets (see below)

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Assets ==

Assets are items and buildings that belong to the tribe. They are held in the 'assets' array (which acts like a bank) in the tribal object.

An Asset data structure contains the following:
*name
*item - a gemNPCItem* that will hold how the item/building looks
*quantity - an int which will hold how many items of a kind the tribe has (used only for items)
*pos - a csVector3 holding the position of the item (used only for buildings)
*building - a boolean value (flagged as true for building entries)

I found that keeping positions & multiple entries for items would prove quite useless... and thought of a better practice to remove all tribal items from the world and keeping them as numbers.

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-03T21:57:37Z

Zee: /* Tribal Object */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes with achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
*an array of Assets (see below)

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-02T16:59:58Z

Zee: /* Provisional Functions */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes with achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-02T16:59:16Z

Zee: /* Provisional Functions */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes with achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|trader(x)
|requirement
|x is an item name
|requires a memory containing the position of another npc trading items of type x
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|trade(x,y)
|algorithm step
|x is the item/tria quantity given by the tribesman, y is the item/tria quantity received by the other npc
|Performs a trade between the tribesman and the npc.
|-
|wait(x)
|algorithm step
|x is a number of ticks
|sets the recipe on pause for the given csTicks. Useful when waiting for buildings to finish.
|-
|setBuffer(x)
|algorithm step
|x is any value
|sets the tribe (string)recipeBuffer to the given value
|-
|setAmountBuffer(x)
|algorithm step
|x is any value
|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
|-
|}

More algorithm steps might be added.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-02T14:15:10Z

Zee: /* Provisional Functions */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes with achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|guard()
|algorithm step
|none
|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
|-
|}

Much more algorithm steps will be added soon.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-01T20:47:09Z

Zee: /* AbstractTribesman npctype */

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes with achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|}

Much more algorithm steps will be added soon.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds general behaviors and reactions.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Tribe Rework

2011-08-01T20:45:26Z

Zee: /* AbstractTribesman npctype */ -- Added the npctype

==Idea==

'''Prerequisite'''

For this system to work, an npctype named "AbstractTribesman" needs to be declared in 'data/npcbehave.xml'.

The functioning of the tribe system is based on the following steps:

'''Step #1 (Loading Stuff)'''

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

The Recipe Manager loads all available recipes from mysql:'tribe_recipes'.

During load, the Recipe Manager parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

The Tribal Object receives all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

'''Step #2 (RunTime)'''

(executed once on startup and each time a recipe is completed)

The Tribal Object selects the top recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes with achieves the requirement on top of the tribe's recipe list

'''Step #3 (Recipe's Algorithm)'''

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs.

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

==Tribal Object==

The tribal object will suffer some changes in order to support the above-mentioned capabilities:
*a knowledge array of strings: it contains only the name of the knowledge received by the tribe from completing recipes. They act more as tokens to prove completion. They are needed because recipes may require knowledge. (E.g.: if we want our tribe to build axes for it's warriors, we need the ironworks knowledge)
*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.

==Recipe Manager==

'''Recipe'''

Definitions:
*Unique Recipe: recipe which can be executed only once. Like recipes to gain a knowledge, or build unique buildings.
*Persistent Recipe: recipe which never ends. Usually, these recipes will contain tribe information or goals which tribe will follow forever.

A recipe object holds all details regarding the process of doing tasks.

It holds:
*flag to signal a unique recipe
*flag to signal a persistent recipe
*a requirement data structure which flags it's name, type and number of entitites required
*csStringArray for holding algorithm steps
*csArray for holding requirements

'''Recipe Manager'''

It holds:
*a list of enrolled tribes and a tribeData structure for each of them
*a list of recipes loaded

Main operations the Recipe Manager does are explained above in the 'idea' tab.

It's in development how the recipe manager should track recipes. I'll add more details as soon as I got a good picture of it.

==Database changes==

The database needs to suffer some changes for this to work.

'''tribe table'''

Added a column to hold the tribal recipe.

'''tribe_recipes table'''

It will contain all the recipes described by:
*ID
*Recipe Name
*Requirement Script
*Algorithm
*Persistent
*Uniqueness

{| border="1"
!ID
!Name
!Requirement
!Algorithm
|-
| 1
| "Mine Coal"
| "tribesman(gatherer,1);item(pickaxe,1);"
| "goToMemory(coal);equip(pickaxe);dig;goTo(hoilme);alterResource(coal,1)"
| 0
| 0
|-
| 2
| "Build Well"
| "tribesman(builder,3);item(shovel,3);"
| "selectLocation(x,y,z);goTo(x,y,z);alterResource(food,-1);dig;alterResource(food,-2);addBuilding(well)"
| 0
| 0
|}

'''sc_tribe_knowledge table'''

It keeps the knowledge gained by the tribe.

{| border="1"
!id
!tribe_id
!knowledge
|-
| 1
| 1
| "Leatherwork"
|-
| 2
| 1
| "Mineworks"
|}

== Provisional Functions ==

Below is a list of functions which will be used to script recipes. Please note that this list is provisional. It will become final as soon as we have a solid list which allows us to do anything tribe-related.

{| border="1"
!function
!type
!arguments
!effect
|-
|brain(x)
|tribe info
|{ civilised, savage, inhuman }
|decides the advancement of this tribe
|-
|aggressivity(x)
|tribe info
|{ warlike, neutral, peaceful }
|decides how tribe members will react to entities coming near them
|-
|growth(x)
|tribe info
|{ expansionist, normal, conservatory }
|decides the expansion rate of the tribe
|-
|unity(x)
|tribe info
|{ organised, normal, cowards }
|decides how members will react if a fellow is attacked
|-
|loadRecipe(x)
|tribe info
|x is a recipe name
|loads a recipe at the initialization of the tribe
|-
|tribesman(x,y)
|requirement
|x is a tribe member type, y is a number
|used by recipes to require able-to-work tribesman
|-
|resource(x,y)
|requirement
|x is a resource type, y is a number
|used by recipes to require an amount of resources
|-
|knowledge(x)
|requirement
|name of knowledge (knowledges discussed above)
|requires a knowledge
|-
|item(x,y)
|requirement
|x is an item's name, y is the number of items
|requires items
|-
|recipe(x,y)
|requirement
|x is a recipe's name, y is the number of recipes
|require a recipe
|-
|alterResource(x,y)
|algorithm step
|x is the resources name, y is the value to alter with
| Pretty self-explaining :D
|-
|loadLocation(x,y,z)
|algorithm step
|x,y,z are float numbers
|loads this location into tribe:memory:activeLocation
|-
|go()
|algorithm step
|none
|makes the npcs go to tribe:memory:activeLocation
|-
|locateMemory(x)
|algorithm step
|x is a memory's name
|loads the memory's location into tribe:memory:activeLocation
|-
|locateResource(x)
|algorithm step
|x is a resource name
|loads the nearest resource of this type into tribe:memory:activeLocation
|-
|addKnowledge(x)
|algorithm step
|x is a name of knowledge (e.g: Ironworks, Pottery)
|adds the knowledge in the tribe knowledge array
|-
|addBuilding(x)
|algorithm step
|x is the name of a building
|finds a good location for the building (in respect of it's size) and spawns it
|-
|attack()
|algorithm step
|none
|sends all selected members to attack a previous selected location (to be used with locateMemory(enemy))
|-
|gather()
|algorithm step
|none
|sends all selected members to gather a previous selected resource
|-
|mine()
|algorithm step
|none
|sends all selected members to mine a previous selected resource
|-
|select(x,y)
|algorithm step
|x is the type of npcs, y is the number
|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
|-
|}

Much more algorithm steps will be added soon.

== AbstractTribesman npctype ==

This npctype is a parent for all npctypes tribe members will have. It holds behaviors only.

<npctype name="AbstractTribesman" vel="2.5">
<behavior name="do nothing" initial="80" resume="yes">
<wait anim="stand" duration="100" />
</behavior>
<behavior name="peace_meet" completion_decay="100">
<locate obj="target" />
<emote cmd="/bow" />
</behavior>
<behavior name="aggressive_meet" completion_decay="150">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="coward_attacked" decay="10">
<emote cmd="/me flees in panic." />
<wander anim="walk" />
</behavior>
<behavior name="normal_attacked" decay="10">
<locate obj="target" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="united_attacked" decay="10">
<locate obj="enemy" />
<percept event="tribesman attacked" target="tribe" />
<melee seek_range="20" melee_range="3" />
</behavior>
<behavior name="Chase" initial="0" growth="0" decay="1" complection_decay="-1" >
<chase type="target" chase_range="20" anim="run" vel="5" />
</behavior>
<behavior name="GoToWork" loop="yes" resume="yes" resume="yes">
<locate obj="tribe:memory:activeBuilding" />
<moveto coords="tribe:memory:activeLocation" anim="walk" />
<wander anim="walk" />
</behavior>
<behavior name="Explore" completion_decay="100" resume="yes">
<locate obj="waypoint" static="no" />
<navigate anim="walk" />
<locate obj="waypoint" static="no" random="yes" range="80" />
<wander anim="walk" />
<wait anim="stand" duration="3" />
<locate obj="tribe:home" static="no" />
<wander anim="walk" />
<navigate anim="walk" />
<share_memories />
</behavior>
<behavior name="GatherResource" completion_decay="100" resume="yes">
<locate obj="tribe:memory:activeResource" />
<wander anim="walk" />
<equip item="Rock Pick" slot="righthand" />
<dig resource="tribe:wealth" />
<locate obj="tribe:home"/>
<wander anim="walk" />
<transfer item="tribe:wealth" target="tribe" />
<share_memories />
</behavior>
<behavior name="GoToSleep" resume="yes">
<locate obj="tribe:home" />
<wander anim="walk" />
<wait anim="sit" duration="180" />
</behavior>
<behavior name="Breed" completion_decay="100">
<invisible />
<wait anim="sit" duration="180" />
<visible />
</behavior>
<behavior name="Resurrect" when_dead="yes" completion_decay="200">
<resurrect />
</behavior>
<behavior name="Guard" resume="yes">
<locate obj="tribe:memory:activeLocation" />
<wander anim="walk" />
<circle anim="walk" radius="2" />
</behavior>
<react event="tribe:resurrect" behavior="Resurrect" delta="200" when_dead="yes" />
<react event="tribe:gotowork" behavior="GoToWork" delta="100" />
<react event="tribe:gather" behavior="GatherResource" delta="100" />
<react event="tribe:breed" behavior="Breed" delta="100" />
<react event="tribe:explore" behavior="Explore" delta="100" />
<react event="target out of range" behavior="Chase" />
<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
</npctype>

== Pros & Cons ==

''' Pros '''
* It won't use any other data sources besides the sql database
* Independent pieces can be altered without the need to change the whole system. Adding moods will only affect the Parser Class that will slightly change the behavior before assembling and sending to the Tribal Object.
* There's no need to change the code in order to add or change tribes.
* The parser class can assemble NPCTypes for regular non-tribe npcs too.

''' Cons '''
* It will put a higher load on the NPCClient. I'm not to good at predicting but... it shouldn't make it "a piece of 20tons rock" :).
* For the start... I might be needed to assembly the NPCType and send it as an xml IDocumentNode so I can use the already-made API there.

== Notes ==

* It would be great if MathScript could be used for the tasks above. Please let me know if it's possible. I like to avoid reinventing the wheel.
* Awaiting the green light.

Zee July 25-31

2011-08-01T20:43:31Z

Zee: Created page with 'I've been away for a week and I apologize for the delay on my arrival. Since I came back on friday I worked on making the Recipe Manager really work. Now we have everything done…'

I've been away for a week and I apologize for the delay on my arrival.
Since I came back on friday I worked on making the Recipe Manager really work.

Now we have everything done on parsing requirements. (except the member types on which we have to agree... for now if we request 5 gatherers we'll get 5 npcs of any type)

We also have all the functions working. The provisional list is posted on the wiki page... if you guys think we need extra functions or something please let me know.

I've spent the last hours trying to populate the tribe_recipes database in order to have something to test on.

I ask of you again... point me to someone who's good at making npctypes and behaviors... I didn't manage to have the npcs salute me on "player nearby" perception or retaliate on my attacks. (the examples in npcbehave.xml don't work ... ) -- I posted my work on 'AbstractTribesman' on the wiki page [[Tribe Rework]].

Best Wishes... Zee.

GSoC weekly reports

2011-08-01T20:37:42Z

Zee: /* July 25-31 */

__NOTOC__

== May ==

Request of weekly reports was sent out the 8th of June, anyway if you have any progress report for May, please post it here.

[[Zhan 16-20]]

== June 6-12 ==

[[Landson June 6-12]]

[[Lucubro June 6-12]]

Zee no report.

== June 13-19 ==

[[Lucubro June 13-19]]

[[Landson June 13-19]]

[[Zhan June 13-19]]

[[Zee June 13-19]]

== June 20-26 ==

[[Lucubro June 20-26]]

[[Landson June 20-26]]

[[Zee June 20-26]]

[[Zhan June 20-26]]

== June 27-July 4 ==

[[Landson June 27-July 4]]

[[Lucubro June 27-July 4]]

[[Zee June 27-July 4]]

[[Zhan June 27-July 4]]

== July 5-11 ==
[[Landson July 5-11]]

[[Lucubro July 5-11]]

[[Zee July 5-11]]

[[Zhan July 5-11]]
== July 12-18 ==
[[Landson July 12-18]]

[[Zhan July 12-18]]

[[Zee July 12-18]]

[[Lucubro July 12-18]]

== July 18-25 ==
[[Landson July 18-25]]

[[Zhan July 18-25]]

[[Lucubro July 18-25]]

== July 25-31 ==
[[Zhan July 25-31]]
<br>[[Landson July 25-31]]

[[Zee July 25-31]]

GSoC weekly reports

2011-08-01T20:37:29Z

Zee: /* July 25-31 */

__NOTOC__

== May ==

Request of weekly reports was sent out the 8th of June, anyway if you have any progress report for May, please post it here.

[[Zhan 16-20]]

== June 6-12 ==

[[Landson June 6-12]]

[[Lucubro June 6-12]]

Zee no report.

== June 13-19 ==

[[Lucubro June 13-19]]

[[Landson June 13-19]]

[[Zhan June 13-19]]

[[Zee June 13-19]]

== June 20-26 ==

[[Lucubro June 20-26]]

[[Landson June 20-26]]

[[Zee June 20-26]]

[[Zhan June 20-26]]

== June 27-July 4 ==

[[Landson June 27-July 4]]

[[Lucubro June 27-July 4]]

[[Zee June 27-July 4]]

[[Zhan June 27-July 4]]

== July 5-11 ==
[[Landson July 5-11]]

[[Lucubro July 5-11]]

[[Zee July 5-11]]

[[Zhan July 5-11]]
== July 12-18 ==
[[Landson July 12-18]]

[[Zhan July 12-18]]

[[Zee July 12-18]]

[[Lucubro July 12-18]]

== July 18-25 ==
[[Landson July 18-25]]

[[Zhan July 18-25]]

[[Lucubro July 18-25]]

== July 25-31 ==
[[Zhan July 25-31]]
<br>[[Landson July 25-31]]
[[Zee July 25-31]]

Tribe Rework

2011-08-01T20:13:15Z

Zee: /* Provisional Functions */

Tribe Rework

2011-08-01T17:44:20Z

Zee: /* Provisional Functions */

Tribe Rework

2011-08-01T17:11:59Z

Zee: /* Provisional Functions */

Zee July 12-18

2011-07-18T02:49:52Z

Zee: Created page with 'This week I took my time to work-out the way the tribal object manages the recipe priority list. By friday everything was done and I started working on parsing functions used in …'

This week I took my time to work-out the way the tribal object manages the recipe priority list. By friday everything was done and I started working on parsing functions used in recipes.

I need some help from someone experienced in order to complete the 'AbstractTribesman' npctype. The model I did seemed fine to me but it has some malfunctions :(.

I would also like to know if you have any extra ideas on what the function list (available on [[Tribe Rework]]) should have to be a complete set of instructions.

Next week I want plan to have a working recipe manager and tribe system in order to test basic things for a start.

GSoC weekly reports

2011-07-18T02:45:47Z

Zee: /* July 12-18 */

GSoC weekly reports

2011-07-10T22:05:00Z

Zee: /* July 5-11 */

GSoC weekly reports

2011-07-10T22:04:43Z

Zee: /* July 5-11 */

GSoC weekly reports

2011-07-10T22:04:35Z

Zee: /* July 5-11 */

Zee July 5-11

2011-07-10T22:04:17Z

Zee: Created page with '*This week I finished all the database work required. (built all dbs & methods for loading & saving data) *Designed the plan presented on wiki. I personally think it fits all the…'

*This week I finished all the database work required. (built all dbs & methods for loading & saving data)
*Designed the plan presented on wiki. I personally think it fits all the tribe requirements and it will be the final version of the implementation.
*Wrote the 'AbstractTribesman' npctype
*Made the methods for parsing db information regarding scripting functions for recipes
*Made a provisional list of functions
*Most of the lesser things implemented in Recipe & RecipeManager are noted on svn commits & wiki page.

Tribe Rework

2011-07-09T17:08:41Z

Zee: updated

Tribe Rework

2011-07-09T16:15:48Z

Zee: /* Tribal Object */

Tribe Rework

2011-07-09T15:42:59Z

Zee: /* Idea */ improved and updated