Excalibur ECS Implementation Goals and Guide

[eonarheim]

Goals

• Break behavior out of Actor and other types into Components/Systems for:
  • Maintainability of the code base
  • Testability of the code base (new components/systems need high test coverage)
  • De-duplication
  • Tree shaking ability
• Excalibur should where possible maintain
  • The easy to use property
  • It should "just work" property
  • It should not surprise users
• Goal are not:
  • to be a pure ECS
  • to require users to know about ECS in order to use Excalibur
  • to purely increase performance

Guide

The current plan is to avoid breaking changes or regressions as much as possible. The plan is to add ECS in 2 steps:

First step the ECS foundations will be installed

• Entity type - Actors will be entities with pre-built components
• Base Components
  • Transform
  • Motion
  • Offscreen
  • Drawing
• Base systems
  • Motion
  • Drawing
• Query mechanisms - what entities match what criteria

Second step ECS everywhere

• All Excalibur behavior should be driven (at least under the hood) by ECS
• Particles
• Collision
• Triggers

[DaVince]

Nice, I've been waiting for this feature!

[eonarheim]

@DaVince let me know how it goes, it is missing some some convenience features at the moment. All systems need to be loaded in by hand for each Scene

[eonarheim]

@DaVince WIP migrating existing draw to to ECS #1643

[DaVince]

Thanks. I will check this out when I can, but time/energy has been scarce. It's been slow going as well as I've been running into having to figure out what goes where. Is it possible to add a very basic snippet containing the minimally required code to use it?

[eonarheim]

Good point @DaVince I'll get some documentation on ECS usage as a part of this PR

[AndrewCraswell]

Hey! Just wanted to drop in and say this is amazing. I've been lurking watching this project for awhile. Built my first game last night in a few hours (first time reading the docs, they're awesome!) and it was such a breath of fresh air from other frameworks like Phaser.

The ECS change is also a key differentiator. Before I saw this, my plan had been to attempt to combine Excalibur with ECSY from Mozilla. I'm curious about what drove the decision to create an ECS from scratch? Although the future of ECSY might be a bit in doubt at the moment, the key win it had was a Devtools extension. At the least I wonder if the same events that the ECSY Devtools expects could be emitted so that the tool can interop with Excalibur? And having another team drive that infrastructure might help keep Excalibur lean.

ECSY
https://github.com/ecsyjs/ecsy

ECSY Devtools
https://github.com/ecsyjs/ecsy-devtools

[eonarheim]

@AndrewCraswell Thanks for checking us out! Please do send us any feedback you have in the discussions! And we'd love to see your game as well!

There are a few reasons we decided chart our own course on an ECS in TypeScript:

• We want it to be 100% suited for Excalibur, keeping that ease of use and keeping tight seamless integration first of mind (And not require users to necessarily be aware of the ECS architecture)
• We want Excalibur's internal organization to be more maintainable on the road to 1.0, ECS is a nice way to organize
• We want to be TypeScript first and leverage the type system when using an ECS to build games
• We generally try to avoid explicit dependencies on other projects to control our own destiny, so to speak

We will look into the dev tools idea, no promises on anything anytime soon 😄 but building a plugin/extension/hook that can interop with an existing devtools is worth exploring.

[github-actions]

This issue hasn't had any recent activity lately and is being marked as stale automatically.

[DrSensor]

This might give some inspiration (all js)

• blazing fast ECS using TypedArrays
• ECS over WebRTC
• ecs-benchmark

[github-actions]

This issue hasn't had any recent activity lately and is being marked as stale automatically.

[JumpLink]

Just to note: Javelin is another performant and handy ECS-Framework directly developed in TypeScript with many good automatic types. The current developer version v1.0.0-alpha.12 is even better although v0.21.0 is already very good.

CC @AndrewCraswell

[github-actions]

This issue hasn't had any recent activity lately and is being marked as stale automatically.

[eonarheim]

Thanks for all the awesome comments on this issue! I'm closing this issue for now but we may open more when we have changes to make.

We will definitely reference all the links posted!