That said, my impression is that a big chunk of talent from the Flash community went to work on HaXe. These are people who make games and want tools to make game development easier—as opposed to people who get excited about engines, architectural patterns, and programming languages. Just as a general impression, based on people I’ve recognized working with HaXe.
That said, I agree that Haxe seems to attract a good crowd. I've also worked with some very competent people who primarily used HaxeFlixel.
You don't have to click on "About Heaps", the landing page mentions HaXe inside the page <title>
Not using Heaps but https://github.com/Kode/Kha.
And I think you are indeed correct in your assumption, since I know plenty of others who made that switch.
I feel attacked.
(2) There are good open-source Flash runtimes.
(3) The selling points of Flash were the no-installation experience and really good development tools. Both aspects are somehow lacking today, so the momentum is gone. Maybe someone will produce a great and accessible tool to create comparable HTML5 experiences, and that thing will become popular. But not yet.
If you're familiar with Pixi.js, Heaps and it's language, Haxe, will feel very similar. Haxe is a pretty cool language, it's similar to TypeScript but compiles to native binaries for almost all major game consoles.
Heaps was apparently the framework behind Dead Cells if that says anything about the level of polish you can accomplish with this set of tools.
[1] https://www.openfl.org/ [2] https://github.com/haxenme/NME [3] https://github.com/HaxeFoundation/as3hx [4] https://github.com/innogames/ax3
article of gamasutra about the gaming pipeline of dead cells https://www.gamedeveloper.com/production/art-design-deep-div...
Still, that's a big +1 for Heaps/Haxe then Dead Cells runs fantastically.
EDIT: Ah, looking into it more Nicolas also founded Shiro Games who made Evoland, Northgard, etc. So it might just be following him around (not to disparage it, still looks great).
the problem really is that typescript was designed to be backwards compatible with javascript - aka, valid js is valid typescript. This is a pretty big constraint.
Haxe could never do this imho. It's got it's own design philosophy. I personally like haxe more, but typescript does have the advantage of the above feature, and a more robust typesystem as a result.
The distinguishing feature of haxe is the macro system - which lets you generate code at compile time. It's almost as powerful as LISP, but in a familiar syntax.
When writing haxe web projects, there’s so much less cruft:
- only one system to import modules (import X)
- one call to haxe.exe to compile and one output file
- no strange js implicit typing (and no === operator) and so on
- Heaps is powerful and used by two of biggest and most successful Haxe gamedev companies (Shiro Games, Motion Twin, and I guess the Dead Cells spinoff company is a third now)
- HaxeFlixel is friendly and well-documented and used by some smaller but still successful gamedev companies, and is much more popular in the indie and game jam scene (also HaxeFlixel is 2D-only, Heaps is 2D and 3D)
- There's other noteworthy engines, Kha for instance. Also proletariat (Spellbreak) uses an Unreal engine integration with Haxe.
Godot and unity are more of an editor oriented "engine", and you code some small pieces of logic associated with entities in the editor.
They target different audiences, and have different use cases imho.
Maybe it's just that Godot is incredibly good at what it does (for 2d game dev), but regardless, it's been a joy to use where Phaser was a drag. I don't personally have any use cases where I would go back to Phaser or any JS Engines like it.
I plan on learning Godot soon, curious if I should choose something else instead.
Godot is better for just shipping small game projects; everything's in one place with an IDE that you can extend, and the design limits imposed by Godot are mostly a matter of how detailed a scene you can support. Those limits are not a barrier most indie devs are really facing - you can sink millions of dollars into a game without really needing special engine code, and because it's all open source, adding a patch for the things that do need some customization is not unfeasible. The barriers are much more likely to be in finding good tutorials, documentation, etc which Godot has accumulated plenty of, albeit not as many as Unity.
Justifications for using Haxe come from a systems development viewpoint. It piggybacks on your other technology to add a layer of portability and options for repurposing code; e.g. if you want to debug and test with interpreted code but then compile it for performance, Haxe gives you several means of doing that. Easy things tend to be slightly harder just due to the nature of its cross-platform functionality, but very hard things also become possible for the same reason. Haxe the language is very good, especially considering what it's aiming to do, but it helps to have some familiarity with the technology you are targeting through Haxe first, since things like standard library functions will follow what their host environment does, which means it is not really a "write once compile everywhere" kind of deal. But if you're really set on exploring engine tech from the beginning, Haxe is a useful way to build up portability, since you can slip its output into a codebase gradually. And engines that build on Haxe are generally coming from the mindset of solving those deep technical issues, which means they often have a great pedigree but aren't the easiest to get started with(since they assume you know what you're doing and what you want out of the tech).
From an ability-to-ship-games perspective, starting out, I'd go with Godot. Putting together a game's architecture from scratch with a library like Heaps sounds like a fun project, but to just get a game out the door without fussing around, Godot makes things easier without major downsides. Godot has so many custom things because those things work.
That said, I'm just a dabbler, so I'm sure other people will chime in as well. I'm also sure that if you invest time in learning Godot or Heaps, it will pay off well, because they are both mature projects that people have used to ship commercial games.
Godot is better if you intend to also learn the editor (and potentially the godot language gscript?). You'd probably get something out the door quicker with godot too.
Heaps is a programming framework/library for making games, not a game editor. You'd also need to be pretty familiar with haxe to use it, unlike godot (where you can get away with not learning gscript for simple things).
if you're a beginner game developer, i'd actually start with godot. Once you got one game made with it, you can then explore other options and learn new things.
What makes Godot really good for beginners can a bit of friction for experienced developers: Especially with GDScript it feels like old-school Python with only one obvious way to do things, which is great but also means it is very opinionated. Node-based OO inheritance is the main abstraction. You don't get any interfaces or traits. Everything is a deep inheritance hierarchy with all the good and bad that brings. (In godot 4 we at least finally get closures.)
And yes, some people absolutely love thinking about their games as a hierarchy of nodes but for me who likes to build data-driven games that is just not the right abstraction.
Of course there are other languages to choose from and there is even a ECS extension for Godot 4 but there can be a bit of friction if you want to design your game differently than the "golden path" the Godot developers have laid out. Still even with the friction, I still think godot is the best choice for my projects.
Also Heaps is written in Haxe which is a nice GC'd language that compiles down to C++ so you get a good combination of development speed and runtime speed.
Is Heaps better? Probably not. But there's definitely a specific type of dev who would prefer this kind of tool.
https://heaps.io/samples/world.html
Edit: spelling
- Haxe is held back by not being self-hosted [0].
- TypeScript is the ideal syntax for Haxe.
Why is that a problem for Haxe adoption?
But on the 2014 MBP with Intel Iris graphics that I travel with it doesn't always run smooth. It may stutter in certain biomes and just plan hang for a few seconds sometimes (GC?).
For me, growing up as a teenager, learning assembly after C, so I can do 2D graphics on my VGA card, this is unacceptable for a pixel graphics game coming out today (even with the shader-based the effects it sports).
And I am certain this game would run smooth as f... on my laptop if it was written in something like Rust or Zig.
I understand that these were no really choices available when R&D on the game started and that C++ may likely have been out of the question too because of the burden on the devs that comes with than language. I.e. Haxe was likey a good idea given the constraints of the studio at the time.
But today, IMHO something like Rust+Bevy is a better choice for a game like this.
a) packaging html5 version in to android App. There are plenty of frameworks for this. Probably the performance will not be the best.
b) hashlink -> in theory possible, a couple of people have done it, but in practice the issue for documenting the process has been opened for years.
Approximate structure for the hashlink approach would be: compile hashlink and required multimedia libs for Android, haxe->hashlink C -> Android SO, create a basic android Java activity which loads all the native code so libs.
Consider the knowledge required for porting (not compiling existing port) Doom or some openGL c++ game (with custom engine) to android. This will be similar experience. On one hand actual work may be somewhat less since some people have done it and code is mostly there, on other hand you will have to deal with half a dozen different projects and their build systems and glue them together. You can find a couple of example projects from people who have gone through this struggle, but they will likely not work out of the box due to version changing and not being common combination so the requirement of knowledge or good code reading and learning skills remains.
1: it doesn't detect the LMB release outside of the frame, although it keeps changing the visuals if I pressed it within the frame. If I release it outside of the frame, it will need a further press-release cycle to free the mouse pointer. It might be intentional but could be annoying sometimes.
2: the snow fall appears linked to the terrain position in a strange way: hard to describe in my non native English; if you move the terrain around while looking at the snow flakes you get it.
I am curious how large the community is?
Nicolas Cannasse having created (and still creating) HaXe (Which would seem like more of a workload in itself) He then goes on to write a 2D/3D game engine?
Both achievements seem huge on their own.
Not knowing the history, he seems to be an incredibly productive person?
So it appears Shiro Games use it!
For everyone else, those are Darksburg, Dead Cells, Northgard, Evoland.
