You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+38-20Lines changed: 38 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -207,13 +207,45 @@ True
207
207
208
208
## Relations
209
209
210
-
Use `Entity.relation_components[component_key][target] = component` to associate a target entity with a component.
211
-
Use `Entity.relation_tag[tag] = target` to associate a tag exclusively with a target entity.
212
-
Use `Entity.relation_tags_many[tag].add(target)` to associate a tag with multiple targets.
210
+
Entity relations are unidirectional from an origin entity to possibly multiple target entities.
211
+
212
+
- Use `origin.relation_tag[tag] = target` to associate an origins tag exclusively with the target entity.
213
+
This uses standard assignment and is useful for tags which would not make sense with multiple targets.
214
+
Reading `origin.relation_tag[tag]` returns a single target while enforcing the invariant of only having one target.
215
+
- Use `origin.relation_tags_many[tag].add(target)` to associate a tag with multiple targets.
216
+
This supports `set`-like syntax such as adding or removing multiple targets at once.
217
+
This allows for many-to-many relations.
218
+
- Use `origin.relation_components[component_key][target] = component` to associate a target entity with a component.
219
+
This allows storing data along with a relation.
220
+
This supports `dict`-like syntax.
221
+
The `component_key` can be queried like a normal tag.
213
222
214
-
Relation queries are a little more complex than other queries.
215
-
Relation tags and relation components share the same space then queried, so 'normal' tags should not be in the format of a component key.
216
-
Relations are unidirectional, but you can query either end of a relation.
223
+
### Relation queries
224
+
225
+
Relations are queried with `registry.Q.all_of(relations=[...])`.
226
+
This expects 2-item or 3-item tuples following these rules:
227
+
228
+
- Use `(tag, target)` to match the origin entities with the relation `tag` to `target`.
229
+
- If `tag` is a component key then component relations are also matched.
230
+
This means you should be careful with tags which look like component keys.
231
+
-`target` can be a specific entity. This means only entities relating to that specific entity will be matched.
232
+
-`target` can be query itself. This means only entities relating to a match from the sub-query are matched.
233
+
-`target` can be `...` which means an entity with a relation to any entity is matched.
234
+
- To reverse the direction use a 3-item tuple `(origin, tag, None)`. `origin` can be anything a `target` could be.
235
+
236
+
Relations using sub-queries may be chained together.
237
+
See [Sander Mertens - Why it is time to start thinking of games as databases](https://ajmmertens.medium.com/why-it-is-time-to-start-thinking-of-games-as-databases-e7971da33ac3) to understand the repercussion of this.
238
+
239
+
You can use the following table to help with constructing relation queries:
0 commit comments