@krabouille
80% Dev Consoles at Seaven Studio. Work on Brotato consoles ports. 20 % Solo Game Dev on my spare time. 40% Roller Derby Player at Jules Vénères from Nantes Yes, I'm good on math. Ex Co-founder and CTO of Casus Ludi. Worked on Blanc.
Someone ported Dead Cells to the R36S (a kind of $40 Game Boy) without the source code by modifying the .hl file (the Hashlink binary) and creating an ARM runtime for Hashlink.
It takes 4 hours to boot but runs at 25fps! Which is quite an achievement.
GG.
gardinerbryant.com/the-anatomy-...
In conclusion, HHH is a niche stack. And I don't see how that could change in the near future.
It's made for developers who like to get their hands dirty. Still I have a lot of affection for this stack, and I can't wait to release my game and my IDE developed with HHH.
That's all folks!
It's important that the team is working on the same version. Updating an ongoing project can also be risky, because jumping directly to the latest nightly builds isn't always smooth sailing. You have to coordinate the versions of Haxe, Heaps, and Hashlink, and the three are quite interdependent.
5 - Versioning is floating.
Version management isn't great. The community recommends installing HHH for the 1st time starting from git main branches, not latest releases. There are very few releases versions, and those that exist can quickly become quite old. This isn't ideal when working in a team.
Autocompletion isn't always stable. So, it's also possibly due to the nature of my project, which is very macro-heavy. But it sometimes lacks fluidity. And while I can accept these frictions fairly well, I'd be reluctant to impose them on less technical or less experienced users.
4 - The lack of stability/fluidity.
I think it's mainly due to the fact that HHH's development is driven by Shiro's needs. As soon as we deviate from those needs, things become less polished.
I need to regularly restart the completion server (the server that manages the cache and autocompletion).
I'm not blaming them. It's a small open-source community, and the task is enormous. It doesn't have the clout of the Godot community, for example. But the problem is still there. You really have to enjoy reading code to make progress with HHH.
It's anything but easy to access. And that's the case for many things. Hashlink's documentation is more than minimalist. And it often happens that the documentation is not up to date.
3 - Doc sucks.
The various documentations do the bare minimum, but nothing more. Haxe's documentation is the most comprehensive but has some serious blind spots. I love macros, but the associated documentation is practically nonexistent. To figure things out, you have to scour Discord or the forum.
For example, FBX files created with Blender are not as well supported as those created with Maya which is used by Shiro . At least, that was the case at one point.
Shiro's latest games have not been released on consoles: therefore the git repos haven't been updated since 2024.
2 - While it's an open-source project, it remains Shiro's technology first and foremost. This means the project's direction is primarily driven by the studio's needs.
I don't blame them. When I write Thor, I focus on my needs first.
Therefore, some features are only partially supported.
1 - The first warning sign is the widespread adoption of techno. I don't believe that, apart from Shiro and Deepnight, any other notorious studio uses Haxe. After Dead Cells, Motion Twin and Evil Empire both abandoned HHH for their projects. Techno didn't convince them.
Okay, those are the good points. Now let's address the points of friction.
Note: I don't blame anyone for these flaws, whether it's Shiro or the community.
It's more like: "That's just the way it is, and we have to deal with it."
7 - Bring your own tools
I chose HHH for its minimalist approach. A graphical backend with a fairly modular API, a resource manager, and I can pick and choose just what I need.
It's a good foundation for building your own tools. And that's exactly what I was looking for.
I say "not completely" because it still requires getting your hands dirty. But I don't have a problem with not having access to the source code (like Unity, for example).
6 - It's open source.
Therefore, I have access to all the HHH's code. I can study it and potentially fix it.
Even the code for the console support modules is available (provided you have the console developers' approval). I'm not completely dependent on a third party.
5 - Backends consoles
One of the important prerequisites for me when choosing a game engine is console support. Hashlink supports the Switch, PS4, PS5, and Xbox.
4 - Fast Compilation
Haxe compiles quite quickly. Often between 2 and 8 seconds. It can take longer, but the cache helps a lot.
It's a welcome change from Unity.
3 - Syntax
Haxe's syntax is quite similar to that of Actionscript 3. It brings back a sense of nostalgia for me. I like it.
Here's a personal example for modeling damage. There's a default "Harmless" type, several types (Physical, Poison, etc.) with minimum and maximum damage values, and a Composite type that allows you to combine multiple damage types.
I think it's an elegant way to model damages.
2 - Enums
Haxe has a rather unique type of enumeration: an enum with a constructor that can take parameters. This provides a lot of flexibility in data modeling. It's also used extensively in the Haxe API, particularly for modeling code within macros.
You want to integrate the current Git commit hash into your build => Macros
You want to create UI components like in ReactJS => Macros (which is what the Domkit library offers)
You want to generate a UI from a class's code => Macros (and that's what I do with Thor)
It's really powerful.
1- Macros !
Macros are code that allows you to write code at compile time. It's metaprogramming. Haxe has a version closer to Rust than to C++ (which is very rudimentary). I love this concept; it allows you to do tons of things.
I'm really enjoying myself with this stack. I love it. But if I were asked for a recommendation for solo development or if I had to choose a stack as CTO for a studio, I don't think it would be my first choice. And in a way, that breaks my heart.
But let's start : Why I love it ?
These three technologies were conceived by Nicolas Cannasse, Ex-Motion Twin and now head of Shiro Games. This is the development stack used for Dead Cells and all Shiro games.
It can be used for both 2D and 3D games on PC and consoles.
For the rest of the thread, I will call them HHH.
Why do I love Haxe, Heaps, and Hashlink, and why do I advise against them?
⬇️Thread
For my personal project, I use the following development stack:
- Haxe, the programming language
- Heaps, a game engine written in Haxe
- Hashlink, a VM that runs everything on PC and exports to consoles.
Ascenseur émotionnel…
« Oh il est mort 😢 »
« Ah c’était une ordure… »
C’est beaucoup pour un dimanche matin.
Coucou les #gamedevs
On tente un projet un peu fou avec @ty.games : faire un éditeur coopératif breton.
On en parle là :
www.linkedin.com/posts/damien...
And I greatly recommand to use less assets than possible.
You can add Amplify Shader to create shader with nodes : assetstore.unity.com/packages/too...