Hey guys. I know the idea of moving the engine to Godot didn't fly at all, and it totally makes sense why it doesn't fit the project. That's why I started looking into another alternative that stays within Haxe, but actually fixes the heavy performance issues: Heaps.io.
The main advantage is that we go from a high-level engine like HaxeFlixel to a much more direct framework. The heavy logic stays the same, and we'd only have to adapt the file system and how scripts handle rendering.
Here is the technical breakdown of how it would work, with pros, cons, and the plan for scripting:
Main Pros:
Performance and overhead: It compiles directly to C++ via HashLink (HL) or to WebGL in a super lightweight way. It gives you real control over memory and the GPU without intermediate layers.
Instant compilation: Haxe's compilation speed with HashLink is absurdly fast. Changing something in the engine core takes just a couple of seconds to compile.
Architectural freedom: We get rid of the OpenFL/Flixel structure. We can build our own entity system tailored for rhythm games and throw in custom shaders with HXSL without breaking our heads.
Cons and Fixes (The "Do It Yourself" trap):
The obvious con with Heaps is that it doesn't come with physics, collisions, or a built-in UI out of the box. But we don't need to reinvent the wheel: we can use HIDE (its web-based editor for assets), CDB (Castle Data Base) to handle structured JSON data, and Domkit to layout UIs with CSS. For 2D physics and tweens, we can throw in libraries like Echo or C++ bindings.
The official docs are lacking, but the samples folder in Heaps' GitHub repo is super complete and is the best guide to see how everything is actually implemented.
How HScript would adapt to Heaps and Flixel compatibility:
Since the scripting base is already built, porting it to Heaps isn't that complicated, and we can add a translation layer so we don't break existing mods:
Keep -lib hscript in the .hxml.
Abstraction/Compatibility Layer: To keep modders from having to learn Heaps from scratch, we can make the interpreter intercept HaxeFlixel classes. When a script calls new FlxSprite(), the engine interprets it under the hood and instantiates it as a Heaps h2d.Bitmap or h2d.SpriteBatch. We map typical Flixel functions (like .loadGraphic, .alpha, .velocity) so they tweak Heaps' native properties underneath.
When instantiating hscript.Interp, we map these bridge classes using interp.variables.set(). That way, old code still works but runs on the fast backend.
To load .hscript files, we use Heaps' resource system (hxd.Res) or sys.io.File.getContent for desktop builds, and pass it through parser.parseString() to get the AST.
Wrap the execution (interp.execute(ast)) inside a try/catch block so syntax errors from modders just show up as a console warning and don't crash the executable (hl.exe).
I know migrating the base from Flixel to Heaps means rewriting a lot of the render stuff (swapping Flixel components for the h2d environment), but in the long run, we'd get rid of all the OpenFL bottlenecks and the HashLink garbage collector would run a thousand times better.
Just throwing the proposal out there in case you ever want to plan a big architecture shift for the engine. If you prefer to stay on HaxeFlixel, that's totally understandable too. Let me know what you think!
Hey guys. I know the idea of moving the engine to Godot didn't fly at all, and it totally makes sense why it doesn't fit the project. That's why I started looking into another alternative that stays within Haxe, but actually fixes the heavy performance issues: Heaps.io.
The main advantage is that we go from a high-level engine like HaxeFlixel to a much more direct framework. The heavy logic stays the same, and we'd only have to adapt the file system and how scripts handle rendering.
Here is the technical breakdown of how it would work, with pros, cons, and the plan for scripting:
Main Pros:
Performance and overhead: It compiles directly to C++ via HashLink (HL) or to WebGL in a super lightweight way. It gives you real control over memory and the GPU without intermediate layers.
Instant compilation: Haxe's compilation speed with HashLink is absurdly fast. Changing something in the engine core takes just a couple of seconds to compile.
Architectural freedom: We get rid of the OpenFL/Flixel structure. We can build our own entity system tailored for rhythm games and throw in custom shaders with HXSL without breaking our heads.
Cons and Fixes (The "Do It Yourself" trap):
The obvious con with Heaps is that it doesn't come with physics, collisions, or a built-in UI out of the box. But we don't need to reinvent the wheel: we can use HIDE (its web-based editor for assets), CDB (Castle Data Base) to handle structured JSON data, and Domkit to layout UIs with CSS. For 2D physics and tweens, we can throw in libraries like Echo or C++ bindings.
The official docs are lacking, but the samples folder in Heaps' GitHub repo is super complete and is the best guide to see how everything is actually implemented.
How HScript would adapt to Heaps and Flixel compatibility:
Since the scripting base is already built, porting it to Heaps isn't that complicated, and we can add a translation layer so we don't break existing mods:
Keep -lib hscript in the .hxml.
Abstraction/Compatibility Layer: To keep modders from having to learn Heaps from scratch, we can make the interpreter intercept HaxeFlixel classes. When a script calls new FlxSprite(), the engine interprets it under the hood and instantiates it as a Heaps h2d.Bitmap or h2d.SpriteBatch. We map typical Flixel functions (like .loadGraphic, .alpha, .velocity) so they tweak Heaps' native properties underneath.
When instantiating hscript.Interp, we map these bridge classes using interp.variables.set(). That way, old code still works but runs on the fast backend.
To load .hscript files, we use Heaps' resource system (hxd.Res) or sys.io.File.getContent for desktop builds, and pass it through parser.parseString() to get the AST.
Wrap the execution (interp.execute(ast)) inside a try/catch block so syntax errors from modders just show up as a console warning and don't crash the executable (hl.exe).
I know migrating the base from Flixel to Heaps means rewriting a lot of the render stuff (swapping Flixel components for the h2d environment), but in the long run, we'd get rid of all the OpenFL bottlenecks and the HashLink garbage collector would run a thousand times better.
Just throwing the proposal out there in case you ever want to plan a big architecture shift for the engine. If you prefer to stay on HaxeFlixel, that's totally understandable too. Let me know what you think!