Civilization 7 Behavior Tree System Architecture

[notque]

Civilization 7 Behavior Tree System Architecture

Core database tables handle tree definition, node configuration, and data management. Direct and clean reference system.

Base Structure​

BehaviorTree​

Essential starting point. No tree exists without this.

• TreeName: Primary key
• Must exist before any node references
• Handles trigger connections

Key Point: Always register tree first.

BehaviorTreeNode​

Main tree structure. Heavy integration with NodeDefinition and TreeData.

• TreeName: Links to base tree
• NodeId: Sequential ordering
• JumpTo: Flow control, defaults 0
• NodeType: Links to definition
• PrimaryKey: Unique identifier

Flow Rule: JumpTo values must align with existing NodeIds.

TreeData​

Node configuration layer. Highly flexible, deeply integrated.

• DefnId: Links to NodeDataDefinition
• NodeId: References BehaviorTreeNode
• Tag/DefaultData: Core configuration
• ParentTag: Data flow control
• UniqueId: System tracking

Critical: Every node needs matching TreeData entries.

Supporting Architecture​

DataType System​

Foundational type management.

• TypeName: String identifier
• DataId: Internal reference

Rule: Type mismatches break nodes silently.

NodeDataDefinition​

Configuration requirements manager.

• Links NodeType to DataType
• Controls required fields
• Manages data flow direction
• Handles editor behavior

Key Point: Check Required and RequiredGroup flags.

ShapeDefinition​

Node structure control.

• Sets child limits
• Enforces tree shape
• Controls node relationships

Core Rule: Respect MinChildren/MaxChildren.

NodeDefinition​

Behavior definition center.

• NodeType primary key
• Links to ShapeDefinition
• Provides base description

Critical: New nodes need NodeDefinition entries.

Practical Implementation​

Tree Building Steps​

1. Register in BehaviorTree
2. Create node structure
3. Add required TreeData
4. Validate references

Error Prevention​

• Check TreeName consistency
• Verify NodeId sequence
• Validate all references
• Test data flow

Performance Notes​

• Minimize JumpTo usage
• Keep trees shallow
• Clean up unused nodes
• Monitor data chains

Real Talk: Complex trees need rigorous testing. Small changes ripple hard.


End Point: System's robust but unforgiving. Test thoroughly.

 

[notque]

Diagram of Simple City Assault (civs attacking cities)

 

[notque]

Diagram of Civ attacking an independent

 

[notque]

Diagram of Civ City Defense

 

[Smayo]

for that example diagram, did you skip the JumpTos from 4, 9 and 16 to 27, and the 13-> 16 one for brevity? or is there something about the db configuration that means those JumpTos aren't valid? I also notice its missing 11-15, which seems to be a branch off of 10.

it seems like the flow is index based using the ShapeId right? so for a given node x without a JumpTo, it walks back to be parented by the closest node with a suitable shapeID, i.e not 1 or 2 as they have no children.

I also am struggling to see what specifies some connections, like what is defining 20 -> 25 as opposed to 21->25? 0->4 as opposed to 1-> 4, and 4->9 as opposed to 5->9. These appear to be cases where an earlier node parents, even tho there was a closer node that could parent.

 

[notque]

The thing is, this is an internal implementation. We don't know of an external reference architecture. So it's all trying to recreate documentation from very little actual information.

For example, the jump to's after the node number at the end. That is not an implementation I am aware of, but we know because they consistently do it, that it means end the run for this turn. And the only way to sort each one out is to try it, view the outcome, and hope to make a logical conclusion.

So I don't have the answers a lot of times. I'm just sort of shaping out what I understand of it. For me, most of the early work is documenting all the variables available for each part of the tree data, because we don't have any linker. So I have to put massive levels of documentation around each tree so that all of that is known when editing.

From there, I determine if what I'm editing is possible to change. For example, Number of Turns to run is an easy one, and I often change it because waiting for things to happen for 20 turns or whatever in civ, is a lot.

However, the one to find the best plot to settle, or the best place to dig for an artifact, that's handed off to the db, and we're basically left to guess.

In the case of plot to settle, we know the inputs in general across flavors for plot settle conditions. For artifacts, we have literally no idea.

So for each question, I would have to attempt variations, and see what the outcomes are, and hope that I can clearly understand the impact. Hope this is making sense.

 

[notque]

Thread 'Mod Tools: Behaviour Tree Visualiser Plugin for draw.io'

Feb 15, 2025

I have written a behavior tree visualiser for the diagram program drawio. It might help in understanding how to mod ai trees.

GitHub - slothoth/behavior-nodes-visualiser-drawio: A plugin for Draw.io that queries your debugGameplay database to visualise a behaviourTree. Bundles sqljs 0.5

A plugin for Draw.io that queries your debugGameplay database to visualise a behaviourTree. Bundles sqljs 0.5 - slothoth/behavior-nodes-visualiser-drawio

github.com

Note: Posting here since there is no tools section, happy to have it moved if theres a better place.

The program underneath it has some bad defaults, like Light Mode, but can be adjusted if you so wish.

• Smayo
• developer tools
• Replies: 4
• Forum: Civ 7 - Creation & Customization

•