Tribe Rework

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

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.

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.

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
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

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.

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.