(Go back to the main GSoC 2012 page)
Please read the main Tribes concept document. This document outlines the concept behind tribes implementation in PlaneShift.
Now consider that the following elements are already completed:
- The concept of "Home", where the tribe spawns and where the tribes member return for bringing food/resources
- The concept of harvesting around the home location
- Food to support the expansion of the tribe
- Maximum number of members and reproduction, the tribe can spawn new members on a simple formula
- TribeNeedSets, possibility to have different members of a tribe to have different set of needs. E.g a queen, warrior, or a worker do have different things to do.
Keep a list of goals with priorities. The goal with the highest priority will be executed. After successful completion of a goal this priority will be lowered, so other goals will be executed. Possible goals for now are:
- Grow in number (mate)
- Build/enhance village size or quality
- Gain wealth
- Expand non aggressively (if other tribes are found, they stop)
- Expand aggressively (if other tribes are found, attack)
- Be able to evaluate what’s needed to accomplish a goal, splitting it into subtasks.
- Be able to give the subtasks to members to achieve the goal. For example if goal is grow in number, it should send input to members to seek food, then to build houses, then to mate.
- Execute some random actions like sitting down for resting, looking around, waiting few seconds.
- React to other NPCs nearby and stop walking to look at the nearby creature (just for few seconds, then restart walking).
Artificial intelligence in collecting materials:
- Building materials – required by the tribe to support expansion, a small population can survive without the need for a distinguishable home but a large one cannot.
- Raw materials – used by the tribe to craft and trade allowing it to actively participate in the economy, increase wealth, tools quality, weapons. These are the actions needed for NPC to use natural resources:
- Dig or search for resources along the movement paths
- Know which tool is needed for digging/harvesting
- Remember a location when they find a resource
- See objects that lie on the ground, so can be picked up and used
This is the most important part of the tribe system. The tribe should be able to :
- Keep a list of houses/buildings which can be created by the tribe
- Keep a cost associated to the creation of each building and the resources needed
- Have a function associated to each building, which can be just sleeping, or can be a forge to make items, or a well, to get water.
- Be able to build and spawn houses/buildings in a predefined area
- Keep a list of houses/buildings which are owned by the tribe
- Use those buildings for their primary function
Tribes should be able to dig the ground/walls and build caves. They can then use those areas to live and to hunt.
- Keep a list of building blocks the tribe can use to create the dungeon
- have an algorithm for creating a dungeon from the building blocks
- know the cost in terms of resources
- know the time needed to create each block
- spawn one block or multiple blocks
- (to be evaluated) collapse the geometry of multiple blocks to create a single piece for performance reasons. This requires some CS internals knowledge and we need CS help.
Based on the current engine, the changes must take place in the NPC superclient. Sadly, having many tribes and complex actions would most probably put a higher load on the CPU. This issue shouldn't be addressed now though and will be discussed based on some benchmarks + unit-tests.
Operations are the base unit from which behaviors and ultimately, tribes, are built. The full list of operations is currently available on this page. The current operations set suffices for now but might be a subject to change if, while developing, we realize we can't make our actors do certain actions.
The SetMood Operation is pretty straight-forward, it just takes cares of setting moods on NPCs. This operation would have no net/cpu loads. It should just set a tribesman mood according to the parameters.
|name||string||random||The name of the mood that should be loaded to the NPC|
|duration||int||0||The duration of the mood. If it's 0 the mood is loaded for the full day.|
<setmood name="aggressive" />
Described here, behaviors are the set of operations that governs the life of an npc. The only changes this expansion requires is to populate the xml files with more behaviors that correspond to types of tribes. (discussed more below, on Tribal Object)
Reactions are certain world events triggered by NPC Perceptions. The before-mentioned list of perceptions is also a subject to change, based on the needs encountered. Besides the possibility of populating the perception list, there is no technical issue to be addressed on Reactions.
Tribal needs set the path tribe members have if no external factors intervene. Based on these needs, behaviors are assigned to tribe members upon creation. The current need list is very low-populated so more Needs / NeedSets will be added...
Treats are special features that a tribe has. Some tribes may be expansive, while some may be conservative. Some tribes may wage wars while some may try to establish peace with others. To handle these situations, the best solution is to have treats represented as TribeNeedSets, store them in xml format and assign them to tribe members upon creation.
Provisional list of treats:
Example for the xml tree structure:
<tribe name="Sumer"> <needset name="expansionist" /> <needset name="advanced" /> <needset name="diplomatic" /> </tribe>
Moods are a new thing regarding Planeshift and they will make tribe members quite unpredictable. The first step in this implementation will be to randomly assign a temperament to each NPC upon creation. The four temperaments are:
(info on each one here)
Based on their temperament, npcs will receive a mood at the start of each day. The mood will alter their behaviors during the day by inserting certain actions. Things considered so far:
|Mood||Inserted operations to Behavior|
|Lazy||Circle Operation, Sit Operation, Standup Operation, Wait Operation|
|Industrious||~no operation should be added, do as ordered~|
(it's just a provisional table)
Temperaments will be described in an xml file by listing all moods and a chance (x%) for them to be chosen at the start of the day. Example:
<temperament name="sanguine"> <mood name="lazy" chance="10" /> <mood name="industrious" chance="80" /> <mood name="aggressive" chance="10" /> </temperament> <temperament name="choleric"> <mood name="lazy" chance="20" /> <mood name="industrious" chance="60" /> <mood name="aggressive" chance="20" /> </temperament>
Moods will also be described in an xml file by listing all operations that should be inserted in the behavior.
<mood name="lazy"> <operation name="circle" repeat="3" /> <operation name="sit" repeat="2" /> <operation name="wait" repeat="4" /> </mood> <mood name="aggressive"> <operation name="melee" repeat="5" /> </mood>
An alternative to this system would be to drop the temperaments idea and assign mood rates directly to the tribal object, storing them in the tribe xml.
<tribe name="sumer"> <needset name="expansionist" /> <needset name="advanced" /> <needset name="diplomatic /> <mood name="lazy" chance="30" /> <mood name="aggressive" chance="20" /> <mood name="industrious" chance="50" /> </tribe>
This structure simplifies things a bit (we don't need another data source to hold the temperaments and their assigned moods), but will make tribe individuals less unique. All tribe members will have the same pattern on which their moods are decided. This isn't a big downfall though, since we still keep the desired randomness and we are close to a real tribe. (some tribes can have industrious individuals while others may have lazy or aggressive ones)
The Tribe object is responsable with:
- holding all the tribe members
- holding all the tribe needs
- managing it's members by sending perceptions to them
- taking decisions based on computed statistics (e.g. Should the tribe spawn more members?)
Most of the expansion tweaks will take place on the tribal object.
An idea for this is to develop a Recipe System. A Recipe class member will be, generally speaking, an algorithm which defines all steps needed to be taken in order to achieve the final product. A very simple example on mining iron:
Technically speaking, the Recipe class should be quite abstract. This way we can derive more Recipe classes based on their type.
Based on this, the Tribal Object must have an Array of known Recipes, from simple to complex.
All Recipes will be held in the database, and each Tribe will load their recipes from there upon initialization. Possible database structure:
|ID||Recipe Name||Recipe Type||Mathscript for the Recipe|
|0||Mine Gold Recipe||Harvest / Gather||<MathScript>|
The Base Recipe class should feature the following things:
- A MathScript that features the algorithm of the Recipe
- A tracking system that should report the step at which the NPC is with completing the task. Based on this, if for some reason (e.g. incomming war), a house is stopped being built, the NPC can resume after he settles his business.
- A requirement set for the Recipe (if the NPC cannot mine Iron, then he shouldn't start mining at all)
Another change in the Tribal Object will be to store the members based on their profession. At the moment the tribal object holds all members in a members array. In the future it should have different arrays for different types of members:
- specialMembers (e.g. Matriarch, Patriarch, Queen, Offspring)
I'll try to keep track here on all things I've thought of adding so far.
Changes in the engine:
- adding setMoodOp
- splitting the Tribe::Member array into multiple arrays
Changes in the database:
- adding a recipe database
- adding a mood database
Changes in xml files:
- adding xml's for tribes for holding their features
Happily awaiting any criticism on this page talks :)