---

In order to implement dynamic tribes, we need a mechanism to build the layout of tribe camps dynamically, based on leveldesign parameters, with customized behaviour per tribe.

This document describes a procedure based on hexagonal tiles, creating a reasonably organic look, as shown in the following example sketch of it's final output.

Todo: Illustrate this.

The hex tiles are laid out automatically onto the continent using World Editor. Tiles on land without walkable area are automatically removed. A displacement map or noise function may be used to make the grid non-uniform, and more organic looking. Tile placement may be further adjusted by the level designer.

Each tribe has an initial starting position that is specified by the leveldesigner, and a seed value used for deterministic randomization. Every step in the camp placement process advances the seed.

A leveldesigner may place zones using World Editor to specify prefered building areas, as well as zones to specify prefered guarding areas. (And roads in the landscape for tribe members to follow when they happen to pass through.) Useless tile sides, for examples ones which are blocked by walls in the landscape, may be flagged by the leveldesigner to disallow gates.

Each hex tile is required to have at least three gates. This ensures that when the camp grows, there are two potential new directions to grow in. The first tile simply has its gates on three random sides.

When a tile is added, it is placed next to a gate of an existing tile. The tribe's script is queried with the elegible tiles to make that choice, it may base it's decision on preferential zones or other tribe goals.

Initially, the elegible gate will have an NPC providing missions to aid in the construction. From a technical POV, the tile is already reserved, and the placement is already prepared.

The tile will have two gates to decide on. To ensure that no circular locking structures occur, one gate will be placed right next to one of the first free edges found, starting from the first gate, ensuring inwards connection. The last gate will be built on one of the three opposing edges.

This sketch demonstrates the three permitted edges onto which the third gate for the second tile will be placed.

If the tile is built against two or more existing gates, or if gates cannot be placed following the rules, one new gate will always be made at random without restriction to ensure camp growth.

Once the tile and gate sides are decided on, the first thing that will be placed are the gates. The tribe camp script is provided with the tile and gate description, and returns the used shapes and locations. The gate shapes are required to be placed outside of the actual tile. Shapes that end up on existing occupied tiles, are discarded by the system, so that only one gate per tile pair will be placed.

In addition to the gate shape, the script must also provide the location and type of guard unit. When a tile is built, existing guard units from the neighbouring tile that occupy the tile location will not despawn, but instead be transfered to the new guard unit location. Guards could be individuals or larger groups, depending on the tribe script.

Guards are expected to be placed outside the gate.

Next is the placement of fences or walls, these are also placed outside of the tile itself, following any curve as the script likes. Fences on neighbouring tiles will be discarded automatically. When a new tile is built, it will also discard the now-useless fences that are on it's area from neighbouring tiles.

Assuming the area connecting the gates is to be used as a walking space, the tile will now consist of three or more constructable areas. A constructable side will either be

• A) a single corner,
• B) a single whole edge,
• C) a corner with two edges,
• D) or three whole edges which provides the largest possible area.

Effectively, the three common layouts will be ABC, AAD, or BBB, with more combinations of A and B when there are more than three gates in the tile.

A tile with only two gates or one gate may cause larger constructable spaces. For simplification, a tile with two gates right next to each other will always contain only a C zone accross the gates. A Tile with one gate, will always contain only a D zone accross the gate. This ensures the contained area is cleanly accessible to players.

The functional contents of the tile can be decided by the tribe script, based on the available areas, and the required space for each function.

NPCs and decorations which should face the player within the camp can be easily placed on a curve between the neighbouring gates of the constructable area.

Placement of NPCs and decorations is entirely up to the tribe script. The system will aid in ensuring locations chosen by the script do not have any collision conflicts. Decors should be placed from largest to smallest.

Tile layouts may deviate from the generic rules. A BBB layout may serve nicely as a square with a campfire in the center, and tribe members around.

• Camp Tiles: Tiles which are part of the camp, connecting to other camp tiles.
• Guard Tiles: Tiles which are outside of the camp, containing a guard unit. These are lighter in dressing than Camp tiles, and can be directly upgraded to a camp tile with guard function.
• Forage Tiles: Tiles which are outside of the camp, containing a foraging unit, along with a light guard. Can be upgraded to a Farm camp tile. Ideally situated on strategic deposits (mission materials).

Several functions need to be provided by camp tiles.

• Altar: Teleport and respawn altar, leader tent.
• Guard: Guard tower, guard supply point.
• Resource: Storage area, convoy transit point, resource market.
• Craft: Craft area, item market, generally next to storage.
• Decor: Chill area, campfire.
• Residential: Residential area, tent.
• Farm: Forage, strategic.

A tribe camp needs at minimum the altar. The altar itself has guards of the higher powers inside the tile. If this tile is overtaken, it is immediately rebuilt elsewhere by the higher powers, without tribe members. The tribe leader may respawn there after some time.

Tiles may combine several functions, although functional clustering is prefered.

These tiles are spawned at a distance outside of the tribe camp, depending on the tribe design.

Following the same design rules as the Camp tiles, but without the fence or gate dressing. Only one constructable area of the tile is built, either of B, C, or D size, whichever is the largest one available in the tile. Guards are inside this area, rather than at gates.

Once a camp grows to contain a guard tile, it can be upgraded into a camp tile. When the camp grows towards an existing guard tile, it follows the same rules, with the gate of the new camp tile connecting to one of the gates of the guard tile.

Similar mechanic to Guard tiles, spawned at a distance outside of tribe camp. Constructable area of the tile may contain some storage box decors.

Tribe foragers may forage at these preferentially, or at any other deposits. Strategic mechanism to assert control over a resource early on.

Mobs should not respawn within tribe camps. Need a mechanism to tell the AIS not to respawn mobs within specific zones. Perhaps one tile around the camp needs to be free, to be safe.

Need a mechanism to have NPCs, that are instructed to go from one point to another, automatically snap to any roads that happen to be practical on the way.

Admin commands should be available to reset an entire tribe to its initial state, and to progress a tribe tile by tile, for testing purposes.

Guards should be able to patrol and change shifts. Guard towers inside the camp may have spare guards on standby.

Tile takes shared ownership of any objects from neighbouring tiles that are in it's area (such as the gates and fences.) This allows the tile to keep those objects alive, (as well as optionally reactivate neighbouring fences,) in case the neighbouring tile is lost.

Tiles may have a constructing, occupied, abandoned, and empty state.

AIS may need some adjustment for enhancing pathfinding within a tribe camp.

For tile construction, the script will be passed the tile layout, and the decors list of the neighbouring tiles with the shapes flagged that collide with the new tile. The script can add and remove objects until it is satisfied, the system will check for each added object whether it collides, and refuse the added shape if so. The script may fail to construct a tile, in which case the system will pick another tile. (The NPC for construction will only show up when the tile is already constructed.) (Two adjacent tiles may not be up for construction simultaneously.)

The tribe service will remember the whole placement of all decors, in case of restart.

Use same technique to construct Kitin nests, Gingo nests, bandit camps, and other threats.

Tiles are flagged whether they can initiate a kitin nest, goo infestation, etc. Goo infested area makes the mobs turn into goo mobs. Areas grow for each enemy the threat kills (kind of like zombie replacement.) Respawned threat is weaker each time (each mob gets to do more than one attack wave.) (The same respawn weakening rule counts for tribes, etc.) Threat mobs reduce and zone shrinks as more of them are killed. Kitin nests should grow from anywhere towards camps and cities, spawn Kitin mounds, etc. Weak worn down tribe camps are good food for Kitin nest growth! Goo mobs start out from Goo zones, also spawn Goo junk.

Weak scout Kitins prepare the Kitin nest if they can gather enough food in a zone. Scout goes zone by zone in the invasion direction. Invasion launches a wave, with a new scout, when a scout dies if not in invasion mode, or when an invasion group is killed in invasion mode. Invasion also launches when the nest grows large enough to destroy the target.

Utility could make a zone visualisation to see which tiles are being occupied, for developer.

Tribes, etc, need to maintain a resource for upkeep, per spawned unit. So, depletion of resources causes units to degrade. That way, overpopulation can be avoided. Spawning a new unit requires resources as well. Resources may be simply killing enemy units, in the case of Kitin.

Need flag on zone who can occupy it. Tribes cannot build on roads, but Kitin can put their nests (although avoid spawning mound if too rough terrain).

Outposts may be simply four tiles. Need some passthrough flag for tiles surrounding outposts, though, since it's rough terrain that's difficult to place buildings on. Same passthrough flag as roads? Effectively allow tribe to bypass a tile.

Tribe script specifies the build order of individual elements of a camp tile.

Abandoned tiles must have all fences removed to avoid pathfinding issues.

This needs to integrate with leveldesign cities. Large cities could be considered as one detached tile with special rules of access and takeover. Should central city be safe or not? Or nearly safe? Move all the cities fairly to different level areas? Add more cities?

Custom placed tiles could be detached from the standard tiles without issue, to fit in specific areas. It doesn't break the camp placement algorithm. Need to flag the detached gates, though, since it affects pathfinding.

Tribes evolve based on a random dice roll. Effectively, they're playing a pseudo turn based board game in the background, invisible to the player. Major decisions such as invasions are triggered by a dice roll which is done each tick. On average a major decision should be initiated every four hours, may be adjustable. Response decisions can be processed independently based on triggers, for example, when a tribe has a set number of tribe members killed by another tribe. Can effectively be handled by a random dice roll any time tribe members are killed by another tribe.

Tribes can declare war on guilds that negatively cross their paths...

Should tribe members carry dog tags that can be looted as proof for killing them? So, rather than Kill 10 Renegades, you can just bring tags to an enemy tribe and they'll reward you. Different rate tags for different tribe member levels. No looting armor either, instead you get stuff based on unique materials (requiring the reverse craft and upgrade mechanism) from the tribe you deliver tags too.

Colored weapons?

In a way, long-running missions will need to be autonomous programs, detached from a mission giver. Mission givers may die at any time, so the mission should direct the player to any NPC of the appropriate rank to continue. Most tasks (supply, eliminate, ...) should not require missions to be active.

When a tribe is defeated, including the teleporter, the teleport will immediately be spawned at another tile, at a safe distance from the existing one. Upon random dice roll, when the tribe chief respawns, the teleport is moved as well, to avoid any spawn camping.

Tribe scripts need access to season, time of day, etcetera, in order to have tribe behaviour differ throughout time.