Heaps: A free, open-source and cross-platform game engine(heaps.io)
heaps.io
Heaps: A free, open-source and cross-platform game engine
https://heaps.io/index.html
102 comments
Because it's not obvious until visiting the Heaps page and clicking through to About: Heaps is built on Haxe. So you're complimenting it, right? (Your comment reads like a non-sequitur criticism if one doesn't know what Heaps is).
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.
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.
I'm certainly not going to try to write comments assuming that people don't read linked page, that sounds tiring :-)
You don't have to click on "About Heaps", the landing page mentions HaXe inside the page <title>
You don't have to click on "About Heaps", the landing page mentions HaXe inside the page <title>
I read the word "Haxe" on the front page and still had no idea what language Heaps was written in, because I didn't know Haxe existed until today.
Its not a lot of work to have a quick line "HaXe (which Heaps is written in)...".
Or click on the link to the source and see for yourself.
comment = "This is written in Haxe. " + comment;
Yes, that’s exactly the kind of thing which I think is a waste of time/effort.
Why? Its not hard and and very helpful.
I don't see the point in spending any effort helping out people who don't click the main link in an HN post.
You could equally say "It's not hard to click on the link at the top, to get context if there's a comment on HN you don't understand." It's a really low bar. Honestly, making HN a better place for people who aren't willing to click the link is just making HN a worse place for everyone else.
If I'm gonna burn time writing something clearly so anyone can understand it, it's gonna be on my blog, or answering questions on Stack Overflow, where that effort pays off. I know there are people on HN who dive straight into the comments without reading the article---I do that often enough---and it's not usually a big deal. However, if I don't understand a comment and haven't read the article, I'm not gonna blame the comment for that.
You could equally say "It's not hard to click on the link at the top, to get context if there's a comment on HN you don't understand." It's a really low bar. Honestly, making HN a better place for people who aren't willing to click the link is just making HN a worse place for everyone else.
If I'm gonna burn time writing something clearly so anyone can understand it, it's gonna be on my blog, or answering questions on Stack Overflow, where that effort pays off. I know there are people on HN who dive straight into the comments without reading the article---I do that often enough---and it's not usually a big deal. However, if I don't understand a comment and haven't read the article, I'm not gonna blame the comment for that.
Interesting how you seem to think you are helping the community by not helping the community.
And being helpful to readers is helpful for getting your point across.
I ported my https://rpgplayground.com from AS3 to Haxe. It was the most sane technology to replace Flash, because it came with some platform independent benefits (as opposed to coding straight in JavaScript)
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.
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.
> as opposed to people who get excited about engines, architectural patterns, and programming languages.
I feel attacked.
I feel attacked.
Well the people who used to be excited about Flash certainly were not excited about any of the things mentioned above.
[deleted]
I don't understand why the Flash runtime is needed or why it matters that it went through a "demise". I was under the impression that you could just export Flash to HTML5 and javascript now? I'm not a flash developer so you'll have to forgive me if this is a dumb question.
(1) The rumors about HTML5 are not exactly true.
(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.
(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.
What is missing in HTML5? You have WASM and websockets and the WebGL canvas built into every browser now, that seems to replicate just about everything Flash was known for doing? And just to clarify, I mean actually using the same old Flash development tools (apparently it's called Adobe Animate now?)
Or is the issue that the export-to-HTML5 functionality in those tools is just not fully done yet?
Or is the issue that the export-to-HTML5 functionality in those tools is just not fully done yet?
>What is missing in HTML5?
- Audio (while in some respect capable) is a nightmare, the interface is unstable and breaks about once a year in my experience.
- You can't do pixel-perfect rendering (People keep promising that you can - the last time I checked was a few months ago - the DOM rendering architecture is deeply wretched when it comes to pixel-access).
- No nice pipeline for integrating vector animations/art into games like there was in flash. (SVG exists, and I've used it in games myself, but it's a niche thing to do). For most engines nowadays you're baking your SVG art to sprite, but flash kinda took care of it for you - its approach to vector art+animation was great/very very powerful, and Adobe Animate allows for HTML5 animation export nowadays, but that's somewhat short of a full interactive app pipeline.
- many of the html runtimes for new engines (Unity for instance) feel waay heavier/more sluggish in the browser than flash games. Pauses during loading/weird interactions with the mouse, having to click before you can see anything is common behaviour. And often they don't perform so well as the flash runtime.
- easy to make fancy + good-looking interactive UIs. There's a reason Scaleform was so beloved for UIs even outside of the browser ( https://en.wikipedia.org/wiki/Scaleform_GFx ).
It's not obviously better than flash still. Flash was a very stable platform for many many years - really good with backwards compatibility (IIRC as a result of literally having secretly several copies of the runtime for different versions), and ...well, for instance Godot HTML5 builds as of last week crashes in safari for everyone it seems.
Source: I made bunch of flash games, and have made a bunch of HTML5 games, and have made a HTML5 game engine myself. And flash was just a better experience as a user for so many things (except for abuses) and as a developer. Outside of writing javascript yourself, haxe is probably the best replacement for flash (as well as being good in its own right). I have been playing with heaps this week actually and it's yeah pretty nice. But flash had a nicer pipeline.
Flash was weaker at 3d stuff, though - even back when flash was a thing I still went for Unity/hand-rolled for 3d games.
- Audio (while in some respect capable) is a nightmare, the interface is unstable and breaks about once a year in my experience.
- You can't do pixel-perfect rendering (People keep promising that you can - the last time I checked was a few months ago - the DOM rendering architecture is deeply wretched when it comes to pixel-access).
- No nice pipeline for integrating vector animations/art into games like there was in flash. (SVG exists, and I've used it in games myself, but it's a niche thing to do). For most engines nowadays you're baking your SVG art to sprite, but flash kinda took care of it for you - its approach to vector art+animation was great/very very powerful, and Adobe Animate allows for HTML5 animation export nowadays, but that's somewhat short of a full interactive app pipeline.
- many of the html runtimes for new engines (Unity for instance) feel waay heavier/more sluggish in the browser than flash games. Pauses during loading/weird interactions with the mouse, having to click before you can see anything is common behaviour. And often they don't perform so well as the flash runtime.
- easy to make fancy + good-looking interactive UIs. There's a reason Scaleform was so beloved for UIs even outside of the browser ( https://en.wikipedia.org/wiki/Scaleform_GFx ).
It's not obviously better than flash still. Flash was a very stable platform for many many years - really good with backwards compatibility (IIRC as a result of literally having secretly several copies of the runtime for different versions), and ...well, for instance Godot HTML5 builds as of last week crashes in safari for everyone it seems.
Source: I made bunch of flash games, and have made a bunch of HTML5 games, and have made a HTML5 game engine myself. And flash was just a better experience as a user for so many things (except for abuses) and as a developer. Outside of writing javascript yourself, haxe is probably the best replacement for flash (as well as being good in its own right). I have been playing with heaps this week actually and it's yeah pretty nice. But flash had a nicer pipeline.
Flash was weaker at 3d stuff, though - even back when flash was a thing I still went for Unity/hand-rolled for 3d games.
Can confirm all this. I used to work professionally as a Flash developer from 2005 to 2010. Since then I’ve been working using Unity and other game engines, but nothing else really comes close to the workflow of Flash. Sometimes it feels like tools in this area are moving backwards.
I'm not sure if I agree with all of this. People forget flash kinda sucked.
One of the most significant ways in which flash sucked was the performance. Imo, the most famous flash game of all time is Binding of Isaac, which basically couldn't achieve a respectable, consistent frame rate even on the most powerful rigs. It's native rewrite, Rebirth, never had performance issues.
>You can't do pixel-perfect rendering
Sure you can, with canvas, and if you want to have absolutely perfect control, there's WebGL (and nice stuff like PixiJS)
>No nice pipeline for integrating vector animations/art into games
You can render SVG sprites into bitmaps, and use them in WebGL or canvas, as you mentioned, you needed to do this too in flash as well if you wanted decent performance.
>easy to make fancy + good-looking interactive UIs
If I remember correctly, most fancy game UIs were built with some framework, like flixel, which used low-level drawing primitives and built-up the UI from scratch. Alternatively you could use the full power of HTML+Js frameworks to build arbitrarily complex UIs and overlay them on your game scene.
>many of the html runtimes for new engines (Unity for instance) feel waay heavier/more sluggish in the browser
True, but they are meant to be, and meant for bigger games than flash/html5+js is. But for modern engines, HTML5 export sucks, there's no doubt about that. But that's a failure of execution, not technology. I remember Epic citadel a decade ago, which ran by compiling C++ to js with emscripten, and it worked pretty well:
https://www.youtube.com/watch?v=BV32Cs_CMqo
Also, there' a few Electron based indie games, most notably CrossCode, which is a fun, and technically pretty well executed game, and by the devs' own admission, it's built on pretty ancient tech.
>You can't do pixel-perfect rendering
Sure you can, with canvas, and if you want to have absolutely perfect control, there's WebGL (and nice stuff like PixiJS)
>No nice pipeline for integrating vector animations/art into games
You can render SVG sprites into bitmaps, and use them in WebGL or canvas, as you mentioned, you needed to do this too in flash as well if you wanted decent performance.
>easy to make fancy + good-looking interactive UIs
If I remember correctly, most fancy game UIs were built with some framework, like flixel, which used low-level drawing primitives and built-up the UI from scratch. Alternatively you could use the full power of HTML+Js frameworks to build arbitrarily complex UIs and overlay them on your game scene.
>many of the html runtimes for new engines (Unity for instance) feel waay heavier/more sluggish in the browser
True, but they are meant to be, and meant for bigger games than flash/html5+js is. But for modern engines, HTML5 export sucks, there's no doubt about that. But that's a failure of execution, not technology. I remember Epic citadel a decade ago, which ran by compiling C++ to js with emscripten, and it worked pretty well:
https://www.youtube.com/watch?v=BV32Cs_CMqo
Also, there' a few Electron based indie games, most notably CrossCode, which is a fun, and technically pretty well executed game, and by the devs' own admission, it's built on pretty ancient tech.
>Audio (while in some respect capable) is a nightmare, the interface is unstable and breaks about once a year in my experience.
I don't know if I understand, something like flash would probably do its own mixing and only use AudioBufferSourceNode. That seems to be what Emscripten uses and I haven't heard about any major breakages there.
>You can't do pixel-perfect rendering (People keep promising that you can - the last time I checked was a few months ago - the DOM rendering architecture is deeply wretched when it comes to pixel-access).
You can though, with WebGL. The point is you avoid the DOM just like what the Flash VM did.
>and Adobe Animate allows for HTML5 animation export nowadays, but that's somewhat short of a full interactive app pipeline.
This is what I'm asking though. How is it different? It seems the pipeline is completely the same except instead of exporting to SWF you export to HTML5.
> And often they don't perform so well as the flash runtime.
I'm actually asking why can't you still use a port of the flash runtime that's done in WASM. I think you misunderstand my question. If the compatibility was there you could also get Scaleform to work with no changes.
I don't know if I understand, something like flash would probably do its own mixing and only use AudioBufferSourceNode. That seems to be what Emscripten uses and I haven't heard about any major breakages there.
>You can't do pixel-perfect rendering (People keep promising that you can - the last time I checked was a few months ago - the DOM rendering architecture is deeply wretched when it comes to pixel-access).
You can though, with WebGL. The point is you avoid the DOM just like what the Flash VM did.
>and Adobe Animate allows for HTML5 animation export nowadays, but that's somewhat short of a full interactive app pipeline.
This is what I'm asking though. How is it different? It seems the pipeline is completely the same except instead of exporting to SWF you export to HTML5.
> And often they don't perform so well as the flash runtime.
I'm actually asking why can't you still use a port of the flash runtime that's done in WASM. I think you misunderstand my question. If the compatibility was there you could also get Scaleform to work with no changes.
Just my experience—the audio API seems relatively stable to me since the autoplay policies launched a couple years ago. I do remember it being a mess back when I started doing audio, and I remember needing libraries to paper over the differences between different browsers, but these days I don’t need that.
Agreed that the “export to browser” in Unity et al. is usually junk.
Agreed that the “export to browser” in Unity et al. is usually junk.
About the pixel perfect aspect: were the people that made the flash games/experiences that I played just bad, or did flash also struggle with pixel perfect placement. I remember both a lot of nearest neighbour flickering and a bunch of seems appearing/disappearing.
Isn't the scene isn't there any more, or is it?
Is Adobe Animate free (or easy to crack) so that an interested kid would just start with it and some tutorial, and could make something moderately cool in an afternoon?
Is Adobe Animate free (or easy to crack) so that an interested kid would just start with it and some tutorial, and could make something moderately cool in an afternoon?
I don't know, I was asking you!
I've written a couple side project games in Heaps and I'm a big fan.
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.
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.
Pixi.js has been a lifesaver for generating interactive art/data pieces since the death of AS3, which used to be my main bag. I remember messing around with HaXe ten years ago or so, the main problem being most of the fl. graphics APIs were not ported at that time and the idea of rewriting my own GUIs and game engines built on those didn't make much sense. I'm not sure it does now, either. If this had a 1:1 naming system, e.g. Sprite and Graphics and Stage, I'd be all in. But so much of my 2D game code was based on extending Starling atlases, etc. and now that's all dead. I'd be afraid to invest the time needed to port it to a relatively exotic and not so well known framework... which still requires a well maintained VM to run.
Heaps has it's own API, but other Haxe frameworks[1][2] reimplement the flash API. Some tools[3][4] help to convert AS3 source code to Haxe, and the typing and compiler are helpful to identify issues. So depending on the size and dependencies, conversion can be easy once you get past the main language differences.
[1] https://www.openfl.org/ [2] https://github.com/haxenme/NME [3] https://github.com/HaxeFoundation/as3hx [4] https://github.com/innogames/ax3
[1] https://www.openfl.org/ [2] https://github.com/haxenme/NME [3] https://github.com/HaxeFoundation/as3hx [4] https://github.com/innogames/ax3
And all Shiro games: Northgard, Darksburg, upcoming Wartales and Dune games. Not sure about Evoland but I wouldn't be surprised.
Yep, Evoland too! Shiro Games was founded by the creator of Haxe (Nicolas Cannasse). Smart guy.
iirc evoland 2 was made with Heaps, and evoland 1 with what then became heaps.
I had no idea Dead Cells was made in this. That game is incredibly sharp. Need to play around with this as it seems relatively simple.
is really cool, is 3d under the hood, then they make a 2d pixel render over.
article of gamasutra about the gaming pipeline of dead cells https://www.gamedeveloper.com/production/art-design-deep-div...
article of gamasutra about the gaming pipeline of dead cells https://www.gamedeveloper.com/production/art-design-deep-div...
That was an absolutely fantastic read. Thank you for that!
Haxe (the language Heaps uses) was initially written by Nicolas Cannasse, who worked at Motion Twin for a while; not sure if he was part of the team that did Dead Cells. So it's not a big surprise.
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).
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).
At first glance it looks pretty nice. I wonder why it hasn't gotten more attention? Or did I just miss it?
The whole Haxe ecosystem flies under most people's radar, partly because it evolved from what was once the Flash ecosystem. It never really qualified for the kind of "NEW SHINY THING" announcement that creates hype elsewhere. A lot of people who have written loads of games are peripherally aware of it but have never actually gotten hands-on with it.
I've said before, I about fell out of my chair the first time I looked at the games created with Heaps: Dead Cells and a few other top tier indie games I had been looking at. Still haven't gotten around to learning Haxe though, hopefully soon.
Looking through the documentation, it’s a bit lackluster. So I always got the feeling that the primary users of the engine were the engine developers themselves
That's exactly my thoughts. They had an internal engine they could open source, so they did it. Probably to simplify the management of intellectual property rights between several companies. Making it a popular choice for indie devs has never been the goal.
I really love what Nicolas is doing. But it kinda feels like whole Haxe ecosystem driving force is this one guy.
The feeling is understandable and it could be worrying, but since some years Nicolas seems to be focusing on Shiro games and game dev tooling (heaps, hide). The compiler is developed by the Haxe Foundation and the ecosystem by the community which is not that big but has quite a few talents.
I really wish Haxe would just take off in the application development world, it had so much potential to be what Typescript has become with the benefit of transpiling to different languages. We theoretically could have had 1 single programming language for a full application with JS front end, Django server, C++ workers, the best of all worlds.
> so much potential to be what Typescript has become
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.
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.
I use both haxe and typescript extensively. I yearn for what haxe could do to the js world! For example, I’m currently building a website in typescript and next.js. Next.js introduces extra tooling that generates code based on filepaths and things. It’s all very clever and complex, but this sort of thing is trivial in haxe - you just mark code to run at compile time and no extra tooling is needed.
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
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
If you are new to the Haxe or game development world I would advise against Heaps as the documentation is pretty bare bones. Haxeflixel [0] is one that is prominently recommended for good reason. Heaps is still great regardless and I have used it for a few private projects.
[0] https://haxeflixel.com/
As a longtime Haxe gamedev:
- 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.
- 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.
+1 for Kha. I have been getting crazy good performance with the WebGL target. I also much prefer its immediate mode API, as apposed to Heaps’s display list (or scene graph). I was also able to build out a full editor with this fantastic library https://github.com/armory3d/zui
For those who might be interested, I wrote an introductory book to HaxeFlixel at https://discover-haxeflixel.com/ which was "blessed" by the devs (we gave away tons of copies during an HaxeFlixel IndieGoGo, plus there's a link to the book in the official docs as well)
[deleted]
What are some advantages of Heaps over Godot or Unity? Neither Godot nor Unity are mentioned on Heaps' website, though there are some mentions in Heaps' community forums.
Heaps is a programming focused game engine (or more correctly, a library for game rendering and other various utilities associated with game, like sound, loading models etc etc).
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.
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.
I've done non-trivial projects in Phaser and Godot... I thought I would never prefer an editor oriented engine (after trying Unity), but I've done a complete 180* on that. Managing game objects and their inheritance tree in the editor makes life so much easier and less bug prone and attaching the scripts makes accessing relevant code much easier. Also, every feature in the editor UI seems to have a code counterpart.
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.
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 don't have anything to add, just that I'd really like to know how it stacks up against Godot.
I plan on learning Godot soon, curious if I should choose something else instead.
I plan on learning Godot soon, curious if I should choose something else instead.
I've used both Godot and Haxe(outside of Heaps, but there are several Haxe game engines and frameworks).
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).
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).
I've half-learned both. My impression is that Godot is more like a framework (but more so) with prescribed ways of doing things, with lots of custom languages and formats, and Heaps is more like a library you use in a codebase that belongs to you a bit more.
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.
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.
This blog post on the Haxe website about Shiro Games’ technology stack shows House many other tools and libraries they needed to build their commercial games. On their architectural diagram, Heaps is just one of a dozen boxes.
https://haxe.org/blog/shirogames-stack/
https://haxe.org/blog/shirogames-stack/
> how it stacks up against Godot.
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.
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.
Godot is the safest and best choice for most 2d games and simple 3d games. You absolutely should keep learning it.
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.
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.
I’d really like to go all in on Godot, but the path to release on consoles is very vague. I really wish it had first class support for consoles.
Godot will never have first class support for consoles. That is because of the console manufactures that only offer proprietary SDKs and require you to sigh NDAs.
The strategy would be to target PC first and if successful use that money to fund console ports, as there are third party companies that offer that.
If you really care about consoles, you should just use Unity/Unreal. Though even then you will need a license and it is up to the manufacturer whether they approve your game.
The strategy would be to target PC first and if successful use that money to fund console ports, as there are third party companies that offer that.
If you really care about consoles, you should just use Unity/Unreal. Though even then you will need a license and it is up to the manufacturer whether they approve your game.
I just don’t see that as a great strategy, when libraries like Heaps, Kha, and Monogame all have support for consoles that is provided once you prove you are a part of the developer program, and also have proven, quality products released. As you mentioned, Unity, Unreal, and even Game Maker, provide a clear path for console support. I don’t want develop an entire game with a library or engine, only then to have to hand over the keys to a third party company. There are so many games on the Nintendo Switch store because it is actually comparatively easy to get your game onto there. There are obviously challenges associated with licensing, but I don’t want further challenges dealing and negotiating with another 3rd party later down the track.
It appears to me that console support is a means for the Godot creator/contributors to make some money. That’s ok, but there are too many unknowns for many developers to consider it as an option. If it was clearly stated “pay X amount to gain Switch/Xbox/PS support”, I would totally choose Godot.
It appears to me that console support is a means for the Godot creator/contributors to make some money. That’s ok, but there are too many unknowns for many developers to consider it as an option. If it was clearly stated “pay X amount to gain Switch/Xbox/PS support”, I would totally choose Godot.
Godot, hands down. It's incredible and is close to releasing version 4.0 which has massive 3d improvements, if that's your thing. Documentation is 1st rate and the community is the best I've seen for game dev.
Programming-only tools are generally easier if you want to do procedurally generated stuff, gameplay patterns that don't exist yet, etc... Engines are easier if you're making a more common genre of game and are hand-placing assets, creating levels, etc...
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.
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.
The idea of world generation being this easy in a game engine is cool. I can't wait to play around with it! Thanks for sharing this.
https://heaps.io/samples/world.html
Edit: spelling
https://heaps.io/samples/world.html
Edit: spelling
I first discovered Haxe nearly a decade ago when seeking alternatives to Microsoft XNA. It was extremely influential in my learning programming. Lots of half-finished games and projects. Haxe is dear to my heart, but I haven’t touched it in a while. A couple of opinions:
- Haxe is held back by not being self-hosted [0].
- TypeScript is the ideal syntax for Haxe.
0: https://github.com/HaxeFoundation/haxe/issues/6843
- Haxe is held back by not being self-hosted [0].
- TypeScript is the ideal syntax for Haxe.
0: https://github.com/HaxeFoundation/haxe/issues/6843
> - Haxe is held back by not being self-hosted [0].
Why is that a problem for Haxe adoption?
Why is that a problem for Haxe adoption?
I love "Dead Cells". I clocked about 500hs on it since I bought it in 2018. It's a masterpiece. It is built with Haxe.
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.
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.
Can someone explain or link to a resource on how you would get this into a android apk? I see it is mostly demonstrated as HTML5.
There are two possible approaches to 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.
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.
Ok thankyou for that. Html5 seems to be path of least resistance. The demo's seem to perform quite well on the Web.
Just found two minor bugs in the "world" sample.
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.
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.
[deleted]
I had not heard much about HaXe before.
Given my current experiments in OCaml it was interesting
to learn its importance its development.
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?
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?
lol, it's not just one person, tho he is kinda OP. The engines are actually simple, minimal. It's the actual games that get complex, not the engines. Haxe the language has a few core people dedicated to the language and compiler (Haxe foundation), and then there are open-source contributors beyond that. Just check the github for haxe foundation.
Under the title "2D and 3D accelerated graphics" on the linked website it shows gameplay for Darksburg (top-left) and Northgard (both on the middle row). I've played both of these games for a decent amount of time (~150 hours between both) and can attest to how fun I found them. Darksburg suffers from lack of content but as functional games (no bugs etc) it was a pleasant experience.
So it appears Shiro Games use it!
So it appears Shiro Games use it!
One of Shiro Games founder (Nicolas Cannasse) is the creator of the Haxe language and Heaps engine !
is there some news/development recently regarding Heaps? or is this just a general awareness post?
This sounds awesome. And credit to the team for creating such a nice platform. The 3d api looks real nice, and simple!
Are all the games featured on the frontpage (as screenshots) actually built with Heaps?
Yes and yes.
Impressive.
For everyone else, those are Darksburg, Dead Cells, Northgard, Evoland.
For everyone else, those are Darksburg, Dead Cells, Northgard, Evoland.
this impressed me too. Might be an indication to put these in front of every use as they access the page - that's my design two cents for the day
How hard it would be to target FreeBSD?
what do we define as a game engine vs a graphic engine?
what happened to just using Vulcan
If you mean Vulkan, there are a lot of platforms where it's not available.
When I learned about Vulkan the program I wrote using the raw Vulkan API drawing a triangle was 900 lines of C++. There is no such thing as "just" using Vulkan, working at that level is a major commitment and a total waste of time for nearly all game developers. Especially since major targets are using DirectX 12 or Metal instead. Yeah, you could use Vulkan on them, but it would be weird to want to use a low-level API and not go for the platform native one.
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.