I’m writing a new game engine in Zig, and I’m open sourcing each module as I write it.
Today I released the beta version of my entity component system ZCS, I’ll consider it a beta until I’ve shipped my next Steam game using it as these things tend to evolve with usage.
Here's a quick sample:
// Reserve space for the game objects and for a command buffer.
// ZCS doesn't allocate any memory after initialization.
var es: Entities = try .init(.{ .gpa = gpa });
defer es.deinit(gpa);
var cb = try CmdBuf.init(.{
.name = "cb",
.gpa = gpa,
.es = &es,
});
defer cb.deinit(gpa, &es);
// Create an entity and associate some component data with it.
// We could do this directly, but instead we're demonstrating the
// command buffer API since it's used more frequently in practice.
const e: Entity = .reserve(&cb);
e.add(&cb, Transform, .{});
e.add(&cb, Node, .{});
// Execute the command buffer
// We're using a helper from the `transform` extension here instead of
// executing it directly. This is part of ZCS's support for command
// buffer extensions, we'll touch more on this later.
Transform.Exec.immediate(&es, &cb);
// Iterate over entities that contain both transform and node
var iter = es.iterator(struct {
transform: *Transform,
node: *Node,
});
while (iter.next(&es)) |vw| {
// You can operate on `vw.transform.*` and `vw.node.*` here!
}
I’ve written a number of ECSs in the past including the one used by Magic Poser. Going through this process a few times has given me a chance to hone in on what I want out of an ECS and I’m really happy with how this one turned out.
In particular, I think my command buffer extension implementation is an interesting solution to a problem I've experienced with other ECS implementations.
If you have any questions or feedback let me know!
I'll be shifting my focus to my render API abstraction & renderer next, if you want to keep up to date with what I'm working on consider signing up for my mailing list.
Top comments (0)