Encompass + LÖVE: Statically typed ECS development

[thatcosmonaut]

Hello everyone!

First of all, thanks to the maintainers of LÖVE. This is an incredible project and my favorite 2D game engine hands down.

However, as my projects grew larger, the dynamically typed nature of Lua began to impede my development as unexpected nils and other nasty problems crept into my code. I also found myself increasingly frustrated with object-oriented patterns.

Because of this, I began looking into ECS, and spent the past year developing the Hyper ECS architecture, an enhancement of ECS that attempts to fix some common problems with the architecture. It has some nifty features, like automatic system ordering and race condition prevention.

I also started looking into ways I could do statically typed development for LÖVE. Encompass-TS is an implementation of the Hyper ECS pattern in TypeScript. Thanks to the TypeScriptToLua project, you can develop in TypeScript and compile to Lua.

Encompass-TS fully supports LÖVE. There is a full tutorial and a few example projects in existence.

A fully-featured tutorial is located here:
https://encompass-ecs.github.io/

The Encompass + LÖVE starter pack is here:
https://github.com/encompass-ecs/encomp ... 2d-starter

API Docs are hosted here:
https://encompass-ts.readthedocs.io/en/latest/api.html

And all Encompass-related code is hosted on our GitHub organization:
https://github.com/encompass-ecs

I hope you make some cool projects with Encompass and LÖVE, please let me know if you do! Feel free to join our Discord chat as well!

[Karai17]

Haxe is also a pretty good option for writing games in LOVE, that's what I use and it does the trick. I'm not exactly sure what the benefit of automatic system ordering provides. Generally speaking, you don't need to dynamically add or remove systems in your agme, just entities, so you'd likely just initialize all of your systems on load in the order you want them to execute and call it a day.

[thatcosmonaut]

There are a few reasons why automatic system ordering is a good feature. Hyper ECS uses messages to communicate information between systems which allows for code reuse. Once your game becomes sufficiently complex, determining a valid ordering of systems, so that systems which emit a message always run before systems which read that message, becomes nontrivial. What if you had 80 systems? You don't want to have to think about the structure of the entire game to determine where to place a new one. In regular ECS, the order in which systems run can change the outcome of the simulation and you can introduce tricky bugs like race conditions by having systems in the wrong order, but you will never have to worry about this using Encompass. There is a detailed explanation of this and other architecture choices in the docs.

[Karai17]

80 systems seems a bit contrived. Also cross talk between systems is generally discouraged. If there is shared code between systems then that code probably shouldn't be in a system, but in a library or utility file. Systems are meant to independently process data and do little else.

[thatcosmonaut]

A moderately complex game could easily have that many systems and more. I'm already up to 45 on one of my projects and it's still a work-in-progress.

Systems in my architecture are inspired by functional programming where they declare inputs, outputs, and side effects. I've used it in practice and I think it works well and is easy to maintain. I'm not really interested in adhering strictly to the conventions of ECS architecture, but in improving them. If you don't actually think I've actually made an improvement, well, you're perfectly free to decide that.

[Karai17]

My games are non trivial and usually land under 10 systems, so perhaps your definition of what constitutes a system is different. I'm not trying to downplay your work, I'm just trying to understand the benefit. It seems to me that while you are moving towards functional programming, you may be holding on to oop ideas that are forcing you to write layers to manage your code in ways that I've not really found necessary in my own code.