Version 3 is Work in Progress and comes with some neat features.

[Lusito]

I am currently working on Version 3. You might wonder what changed.. it's not final yet, but the most important features are:

• Support for hot module replacement
  • for systems
  • for components (and thus factories)
  • tested with webpack and with parcel.
• Simplified creating components without blueprints (from engine)
• Simplified syntax for pure marker components
• Performance optimizations

Wait, did you say Hot Module Replacement?

Yes, while investigating a bug in a game, I had to always go back to the same place and repeat the same steps to be able to reproduce the bug, since every save would reload the entire game.

I could have created a special level with this bug, but I knew, that most bundlers nowadays support hot module replacement. So if this works for Single Page Applications, why not for games as well?

If you don't know: Hot module replacement means, that when you save a file while developing, the code (logic) will be replaced, but state (data) can be kept. This should work perfectly with an entity-component system, since we already separate logic (systems) and data (components).

My first idea was to just write the ECS in react, since the code to keep the state already exists. I made a prototype working relatively quickly and it even made the code a lot(!) simpler. But it would also force everyone to use react and it would prevent ecstasy from being used on the server-side. Aside from that, it would introduce very big breaking changes, since systems would have to be written in a completely different manner.

So I started experimenting with webpacks hot module replacement API and, while it took a lot longer to get a prototype working, the new approach works without react.

Breaking Changes

Sadly, this still requires quite a few breaking changes. A lot of things will remain similar or even unchanged, but if you have been using v1 or v2 before, you will have to put some work in to go for v3. Mostly on the component code. The adjustments required for systems are not as drastic. I will create a migration guide before the release.

Most notable breaking changes:

• Switch from typedi to custom dependency injection code
  • Why? There doesn't seem to be a dependency injection library for typescript, which supports hot-module-replacement at this time.
  • This includes a switch to constructor-only dependency injection (to keep it simple for now)
• Components have to be written in a very different way. No more classes. On the plus-side: it puts more focus on components just being data.

Feedback

The new API is not final yet. If you have any idea how to make the API better, feel free to comment here.

The current code can be found here: https://github.com/Lusito/typed-ecstasy/tree/v3

Beware: The documentation (markdown files) are not yet up to date.

I will try to prepare some alpha/beta builds once I am a bit more confident about the API.

Quick Start Guide:

If you want to fire it up for a test-drive:

clone the repo, checkout the v3 branch and run:

• yarn to install dependencies
• yarn start:fresh to run compile the lib and start the demo
• Open the url shown in the console (usually localhost:1234)
• Now edit RenderSystem.ts and change the following line:

// this.context2D.fillStyle = sprite.image;
this.context2D.fillStyle = "red";

You will notice, that while boxes both change to red, the state of the components (positions of the boxes) and the state of the system (size of the boxes) remain.

[Lusito]

@MadMed677 since you've recently been using typed-ecstasy, I wonder if you have any thoughts on improving the API.