Eskimo ECS + Tundra Engine

A hard truth I’ve come to realize is I apparently like making tools more than games. I think I like making games, but my track record clearly shows otherwise.

On that note, while developing, I quickly came across some issues using hxE2 in terms of usability and consistency, the thing felt bloated and messy. Fixing bugs would spawn other bugs, functionality was split awkwardly and sometimes duplicated, etc.. Which is why I did what I like to do, and create yet another ECS, this time explicitly focusing on simplicity and lighter code.

Eskimo ( is so far the best approach to an ECS I’ve made. All component access happens through an Entity object (unlike in hxE2, where you could do that, but also use a View object), and Views only manage a list of entities (they don’t store their own components, except for one, which is explicitly defined that way). Further, there are types of Views that enable specific features you might need, such as just a list of entities with certain components, or tracking added/updated/removed entities from that list. There has been no effort to unreasonably optimize parts of the system, and by design Views are meant to be single threaded, resulting in a clean and simple implementation. Multi-threading support happens through the base Context class, again, in a much clearer manner (though multi-threading support is only at a proof of concept stage right now). Check out the github repository for more details and usage!

Now with Eskimo in hand, I am much more confident that things will work correctly, so far it has had less bugs and I haven’t experienced any huge limitations.

Afterwards I devoted time to learning about CPPIA, the relatively new scripting feature in hxcpp. I should write a post on what I learned and my travels, but I’ll wait until my understanding solidifies.

I’m currently working on a tool called Tundra, which is both a tool and a (game) engine right now, though I’ll try to extract the coolest functionality out into a separate library: live code reloading. Currently it’s based on Snow from Snowkit, but that could be swapped for anything that supports file-watching. It scans your project.flow file, finds all source directories, and scans for classes implementing either IState or ISystem interfaces. Once found, it compiles each one into a CPPIA file, and loads it. Only 1 IState class is loaded at a time (the one that changed most recently will load), and reloading an IState causes the Eskimo ECS to be reset/cleared of all entities. ISystem classes are loaded and run without any interruption to gameplay, and with a meta tag, can be assigned to 1 of 4 System groups, input, logic, physics, or render. System groups are run in that order, but individual system order within those groups is not defined.

Despite some problems with CPPIA that causes a crash once in a while, I can leave the game window open and freely work on a game idea with no interruption, and nearly immediate results. Adding a new system is as easy as creating the class itself, and it will get picked up by Tundra to load.

My work isn’t public because I have yet to solve a few issues (I kind of broke it a bit before initializing git, what a great idea…), but once I’m comfortable with how it works, I’m excited to release it into the wild. It’s improved the speed at which I can prototype, and so hopefully for once, after many years, I’ll be able to make another game…maybe.

Leave a Reply

Your email address will not be published. Required fields are marked *