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.
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.
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.
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).
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.
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.
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.
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.