mirror of
https://github.com/Ukendio/jecs.git
synced 2025-04-28 19:00:03 +00:00
Compare commits
No commits in common. "b3ab540705750f114a9839c9819af26380807d1b" and "f66961fc9b08cdfc6578dfc98f3b82a38db1ea8f" have entirely different histories.
b3ab540705
...
f66961fc9b
4 changed files with 282 additions and 351 deletions
|
@ -1,23 +1,16 @@
|
|||
# Addons
|
||||
|
||||
A collection of third-party jecs addons made by the community. If you would like to share what you're working on, [submit a pull request](https://github.com/Ukendio/jecs)!
|
||||
# Assets
|
||||
A collection of third-party jecs assets made by the community. If you would like to share what you're working on, [submit a pull request](https://github.com/Ukendio/jecs)!
|
||||
|
||||
# Debuggers
|
||||
|
||||
## [jabby](https://github.com/alicesaidhi/jabby)
|
||||
|
||||
A jecs debugger with a string-based query language and entity editing capabilities.
|
||||
|
||||
# Schedulers
|
||||
|
||||
## [lockstep scheduler](https://gist.github.com/1Axen/6d4f78b3454cf455e93794505588354b)
|
||||
|
||||
A simple fixed step system scheduler.
|
||||
|
||||
## [rubine](https://github.com/Mark-Marks/rubine)
|
||||
|
||||
An ergonomic, runtime agnostic scheduler for Jecs
|
||||
## [sapphire-jecs](https://github.com/Mark-Marks/sapphire/tree/main/crates/sapphire-jecs)
|
||||
A batteries-included [sapphire](https://github.com/mark-marks/sapphire) scheduler for jecs
|
||||
|
||||
## [jam](https://github.com/revvy02/Jam)
|
||||
|
||||
Provides hooks and a scheduler that implements jabby and a topographical runtime
|
||||
|
|
|
@ -1,21 +1,16 @@
|
|||
# Component Traits
|
||||
|
||||
Component traits are IDs and pairs that can be added to components to modify their behavior. Although it is possible to create custom traits, this manual only contains an overview of all builtin component traits supported by Jecs.
|
||||
|
||||
# Component
|
||||
|
||||
Every (component) ID comes with a `Component` which helps with the distinction between normal entities and component IDs.
|
||||
|
||||
# Tag
|
||||
|
||||
A (component) ID can be marked with `Tag´ in which the component will never contain any data. This allows for zero-cost components which improves performance for structural changes.
|
||||
|
||||
# Hooks
|
||||
|
||||
Hooks are part of the "interface" of a component. You could consider hooks as the counterpart to OOP methods in ECS. They define the behavior of a component, but can only be invoked through mutations on the component data. You can only configure a single `OnAdd`, `OnRemove` and `OnSet` hook per component, just like you can only have a single constructor and destructor.
|
||||
|
||||
## Examples
|
||||
|
||||
::: code-group
|
||||
|
||||
```luau [luau]
|
||||
|
@ -32,22 +27,23 @@ end)
|
|||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const Transform = world.component();
|
||||
|
||||
const Transform = world.component()
|
||||
world.set(Transform, OnAdd, (entity) => {
|
||||
// A transform component has been added to an entity
|
||||
});
|
||||
// A transform component has been added to an entity
|
||||
})
|
||||
world.set(Transform, OnRemove, (entity) => {
|
||||
// A transform component has been removed from the entity
|
||||
});
|
||||
// A transform component has been removed from the entity
|
||||
})
|
||||
world.set(Transform, OnSet, (entity, value) => {
|
||||
// A transform component has been assigned/changed to value on the entity
|
||||
});
|
||||
// A transform component has been assigned/changed to value on the entity
|
||||
})
|
||||
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
# Cleanup Traits
|
||||
|
||||
When entities that are used as tags, components, relationships or relationship targets are deleted, cleanup traits ensure that the store does not contain any dangling references. Any cleanup policy provides this guarantee, so while they are configurable, games cannot configure traits that allows for dangling references.
|
||||
|
||||
We also want to specify this per relationship. If an entity has `(Likes, parent)` we may not want to delete that entity, meaning the cleanup we want to perform for `Likes` and `ChildOf` may not be the same.
|
||||
|
@ -58,20 +54,18 @@ To configure a cleanup policy for an entity, a `(Condition, Action)` pair can be
|
|||
|
||||
There are two cleanup actions:
|
||||
|
||||
- `Remove`: removes instances of the specified (component) id from all entities (default)
|
||||
- `Delete`: deletes all entities with specified id
|
||||
- `Remove`: removes instances of the specified (component) id from all entities (default)
|
||||
- `Delete`: deletes all entities with specified id
|
||||
|
||||
There are two cleanup conditions:
|
||||
|
||||
- `OnDelete`: the component, tag or relationship is deleted
|
||||
- `OnDeleteTarget`: a target used with the relationship is deleted
|
||||
- `OnDelete`: the component, tag or relationship is deleted
|
||||
- `OnDeleteTarget`: a target used with the relationship is deleted
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use cleanup traits
|
||||
|
||||
### (OnDelete, Remove)
|
||||
|
||||
::: code-group
|
||||
|
||||
```luau [luau]
|
||||
|
@ -86,20 +80,19 @@ world:delete(Archer)
|
|||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const Archer = world.component();
|
||||
world.add(Archer, pair(jecs.OnDelete, jecs.Remove));
|
||||
const Archer = world.component()
|
||||
world.add(Archer, pair(jecs.OnDelete, jecs.Remove))
|
||||
|
||||
const e = world.entity();
|
||||
world.add(e, Archer);
|
||||
const e = world:entity()
|
||||
world.add(e, Archer)
|
||||
|
||||
// This will remove Archer from e
|
||||
world.delete(Archer);
|
||||
world.delete(Archer)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### (OnDelete, Delete)
|
||||
|
||||
::: code-group
|
||||
|
||||
```luau [luau]
|
||||
|
@ -114,46 +107,19 @@ world:delete(Archer)
|
|||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const Archer = world.component();
|
||||
world.add(Archer, pair(jecs.OnDelete, jecs.Delete));
|
||||
const Archer = world.component()
|
||||
world.add(Archer, pair(jecs.OnDelete, jecs.Delete))
|
||||
|
||||
const e = world.entity();
|
||||
world.add(e, Archer);
|
||||
const e = world:entity()
|
||||
world.add(e, Archer)
|
||||
|
||||
// This will delete entity e because the Archer component has a (OnDelete, Delete) cleanup trait
|
||||
world.delete(Archer);
|
||||
world.delete(Archer)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### (OnDeleteTarget, Remove)
|
||||
|
||||
::: code-group
|
||||
|
||||
```luau [luau]
|
||||
local OwnedBy = world:component()
|
||||
world:add(OwnedBy, pair(jecs.OnDeleteTarget, jecs.Remove))
|
||||
local loot = world:entity()
|
||||
local player = world:entity()
|
||||
world:add(loot, pair(OwnedBy, player))
|
||||
|
||||
-- This will remove (OwnedBy, player) from loot
|
||||
world:delete(player)
|
||||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const OwnedBy = world.component();
|
||||
world.add(OwnedBy, pair(jecs.OnDeleteTarget, jecs.Remove));
|
||||
const loot = world.entity();
|
||||
const player = world.entity();
|
||||
world.add(loot, pair(OwnedBy, player));
|
||||
|
||||
// This will remove (OwnedBy, player) from loot
|
||||
world.delete(player);
|
||||
```
|
||||
|
||||
### (OnDeleteTarget, Delete)
|
||||
|
||||
::: code-group
|
||||
|
||||
```luau [luau]
|
||||
|
@ -169,15 +135,14 @@ world:delete(parent)
|
|||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const ChildOf = world.component();
|
||||
world.add(ChildOf, pair(jecs.OnDeleteTarget, jecs.Delete));
|
||||
const Archer = world.component()
|
||||
world.add(Archer, pair(jecs.OnDelete, jecs.Remove))
|
||||
|
||||
const parent = world.entity();
|
||||
const child = world.entity();
|
||||
world.add(child, pair(ChildOf, parent));
|
||||
const e = world:entity()
|
||||
world.add(e, Archer)
|
||||
|
||||
// This will delete both parent and child
|
||||
world.delete(parent);
|
||||
// This will delete e
|
||||
world.delete(Archer)
|
||||
```
|
||||
|
||||
:::
|
||||
|
|
|
@ -1,26 +1,23 @@
|
|||
# Entities and Components
|
||||
|
||||
## Entities
|
||||
|
||||
Entities represent things in a game. In a game there may be entities of characters, buildings, projectiles, particle effects etc.
|
||||
|
||||
By itself, an entity is just an unique identifier without any data
|
||||
|
||||
## Components
|
||||
|
||||
A component is something that is added to an entity. Components can simply tag an entity ("this entity is an `Npc`"), attach data to an entity ("this entity is at `Position` `Vector3.new(10, 20, 30)`") and create relationships between entities ("bob `Likes` alice") that may also contain data ("bob `Eats` `10` apples").
|
||||
|
||||
## Operations
|
||||
### Operations
|
||||
Operation | Description
|
||||
----------|------------
|
||||
`get` | Get a specific component or set of components from an entity.
|
||||
`add` | Adds component to an entity. If entity already has the component, `add` does nothing.
|
||||
`set` | Sets the value of a component for an entity. `set` behaves as a combination of `add` and `get`
|
||||
`remove` | Removes component from entity. If entity doesn't have the component, `remove` does nothing.
|
||||
`clear` | Remove all components from an entity. Clearing is more efficient than removing one by one.
|
||||
|
||||
| Operation | Description |
|
||||
| --------- | ---------------------------------------------------------------------------------------------- |
|
||||
| `get` | Get a specific component or set of components from an entity. |
|
||||
| `add` | Adds component to an entity. If entity already has the component, `add` does nothing. |
|
||||
| `set` | Sets the value of a component for an entity. `set` behaves as a combination of `add` and `get` |
|
||||
| `remove` | Removes component from entity. If entity doesn't have the component, `remove` does nothing. |
|
||||
| `clear` | Remove all components from an entity. Clearing is more efficient than removing one by one. |
|
||||
|
||||
## Components are entities
|
||||
### Components are entities
|
||||
|
||||
In an ECS, components need to be uniquely identified. In Jecs this is done by making each component its own unique entity. If a game has a component Position and Velocity, there will be two entities, one for each component. Component entities can be distinguished from "regular" entities as they have a `Component` component. An example:
|
||||
|
||||
|
@ -28,12 +25,12 @@ In an ECS, components need to be uniquely identified. In Jecs this is done by ma
|
|||
|
||||
```luau [luau]
|
||||
local Position = world:component() :: jecs.Entity<Vector3>
|
||||
print(world:has(Position, jecs.Component))
|
||||
print(world:has(Position, Jecs.Component))
|
||||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const Position = world.component<Vector3>();
|
||||
print(world.has(Position, jecs.Component));
|
||||
print(world.has(Position, Jecs.Component))
|
||||
```
|
||||
|
||||
:::
|
||||
|
@ -51,7 +48,7 @@ world:add(Position, Networked)
|
|||
world:set(Position, Name, "Position")
|
||||
world:set(Position, Type, { size = 12, type = "Vector3" } ) -- 12 bytes to represent a Vector3
|
||||
|
||||
for id, ty, name in world:query(Type, Name, Networked) do
|
||||
for id, ty, name in world:query(Type, Name):with(Networked) do
|
||||
local batch = {}
|
||||
for entity, data in world:query(id) do
|
||||
table.insert(batch, { entity = entity, data = data })
|
||||
|
@ -78,63 +75,39 @@ end
|
|||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const Networked = world.component();
|
||||
const Type = world.component();
|
||||
const Name = world.component();
|
||||
const Networked = world.component()
|
||||
const Type = world.component()
|
||||
const Name = world.component()
|
||||
const Position = world.component<Vector3>();
|
||||
world.add(Position, Networked);
|
||||
world.set(Position, Name, "Position");
|
||||
world.set(Position, Type, { size: 12, type: "Vector3" }); // 12 bytes to represent a Vector3
|
||||
world.add(Position, Networked)
|
||||
world.set(Position, Name, "Position")
|
||||
world.set(Position, Type, { size: 12, type: "Vector3" } ) // 12 bytes to represent a Vector3
|
||||
|
||||
for (const [id, ty, name] of world.query(Type, Name, Networked)) {
|
||||
const batch = new Array<{ entity: Entity; data: unknown }>();
|
||||
for (const [id, ty, name] of world.query(Type, Name).with(Networked)) {
|
||||
const batch = new Array<{ entity: Entity, data: unknown}>()
|
||||
|
||||
for (const [entity, data] of world.query(id)) {
|
||||
batch.push({ entity, data });
|
||||
}
|
||||
// entities are sized f64
|
||||
const packet = buffer.create(batch.size() * (8 + ty.size));
|
||||
const offset = 0;
|
||||
for (const [_, entityData] of batch) {
|
||||
offset += 8;
|
||||
buffer.writef64(packet, offset, entityData.entity);
|
||||
if (ty.type == "Vector3") {
|
||||
const vec3 = entity.data as Vector3;
|
||||
offset += 4;
|
||||
buffer.writei32(packet, offsetm, vec3.X);
|
||||
offset += 4;
|
||||
buffer.writei32(packet, offset, vec3.Y);
|
||||
offset += 4;
|
||||
buffer.writei32(packet, offset, vec3.Z);
|
||||
}
|
||||
}
|
||||
for (const [entity, data] of world.query(id)) {
|
||||
batch.push({ entity, data })
|
||||
}
|
||||
// entities are sized f64
|
||||
const packet = buffer.create(batch.size() * (8 + ty.size))
|
||||
const offset = 0
|
||||
for (const [_, entityData] of batch) {
|
||||
offset+=8
|
||||
buffer.writef64(packet, offset, entityData.entity)
|
||||
if (ty.type == "Vector3") {
|
||||
const vec3 = entity.data as Vector3
|
||||
offset += 4
|
||||
buffer.writei32(packet, offsetm, vec3.X)
|
||||
offset += 4
|
||||
buffer.writei32(packet, offset, vec3.Y)
|
||||
offset += 4
|
||||
buffer.writei32(packet, offset, vec3.Z)
|
||||
}
|
||||
}
|
||||
|
||||
updatePositions.FireServer(packet);
|
||||
updatePositions.FireServer(packet)
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
## Singletons
|
||||
|
||||
Singletons are components for which only a single instance
|
||||
exists on the world. They can be accessed on the
|
||||
world directly and do not require providing an entity.
|
||||
Singletons are useful for global game resources, such as
|
||||
game state, a handle to a physics engine or a network socket. An example:
|
||||
|
||||
::: code-group
|
||||
|
||||
```luau [luau]
|
||||
local TimeOfDay = world:component() :: jecs.Entity<number>
|
||||
world:set(TimeOfDay, TimeOfDay, 0.5)
|
||||
local t = world:get(TimeOfDay, TimeOfDay)
|
||||
```
|
||||
|
||||
```typescript [typescript]
|
||||
const TimeOfDay = world.component<number>();
|
||||
world.set(TimeOfDay, TimeOfDay, 0.5);
|
||||
const t = world.get(TimeOfDay, TimeOfDay);
|
||||
```
|
||||
|
||||
:::
|
||||
|
|
|
@ -17,14 +17,14 @@ This manual contains a full overview of the query features available in Jecs. So
|
|||
## Performance and Caching
|
||||
|
||||
Understanding the basic architecture of queries helps to make the right tradeoffs when using queries in games.
|
||||
|
||||
The biggest impact on query performance is whether a query is cached or not.
|
||||
|
||||
This section goes over what caching is, how it can be used and when it makes sense to use it.
|
||||
|
||||
### Caching: what is it?
|
||||
|
||||
Jecs is an archetype ECS, which means that entities with exactly the same components are
|
||||
grouped together in an "archetype". Archetypes are created on the fly
|
||||
whenever a new component combination is created in the ECS. For example:
|
||||
Jecs is an archetype ECS, which means that entities with exactly the same components are grouped together in an "archetype". Archetypes are created on the fly whenever a new component combination is created in the ECS. For example:
|
||||
|
||||
:::code-group
|
||||
|
||||
|
|
Loading…
Reference in a new issue