Awesome! I would like to point out that two of the example gifs are from the game Dead Cells[1] which is a <i>fantastic</i> action rogue-like with super tight combat and controls.<p>So if anyone's wondering if this engine can handle "AAA" game requirements, it already is!<p>[1] <a href="https://dead-cells.com/" rel="nofollow">https://dead-cells.com/</a>
Heaps is more of a game framework than engine. Though it is very high level. It gives you flexibility. The problem is that it lacks in documentation, real world examples etc.
I'm tired of "game engines" that aren't. There's more to game development than exposing a load-update-draw loop and providing bindings to libraries. The most frequent example of this is a game framework when accurately marketed.<p>But I've come to call tech like this a "game software suite" when sufficiently advanced. Further, software like Unity and Unreal Engine are also just game software suites. They aren't true engines, because you <i>still</i> have to write everything yourself.<p>Imagine someone provided you the metal and engineering concepts to build an engine, but never supplied the engine itself. That's consistently, time and time again, what the games industry on the hobbyist side has provided.<p>Well, thanks for providing bindings I guess. Any sufficiently advanced language with an FFI can automatically do most of that work for me.<p>But it isn't a game engine in the same respect as any of the Quake, Source, IW engine, or derivative engines.<p>Where's my console? Where's my UI layer? Where's my map loading and format? Where's my multiplayer? No server browser protocol or architecture? No matchmaking? Where's my key and controller binding system? Oh, there isn't one?<p>It's not an engine. It's a collection of library interfaces.<p>Library => Framework => Engine. What's missed almost every single time is that to build an engine, you actually need a framework to dictate how a game loop performs behaviors, schedules, tasks, entity dispatch, sound emitters, and how all of these things should be networked and how they should work over split-screen or on difference devices.<p>If you see something exposing load-update-draw, it's at best a framework. Like the XNA of yesteryear or the LÖVE of today, that's what it is.<p>But a true game engine doesn't have you building your own console variable and replication system. It should come out of the box. That's the point.<p>That's the entire point. And if you're not working on nearly exclusively game logic, you're probably not working on a game engine. Or you're sure as hell doing both engine and game development with a half-baked game software suite.