[HN Gopher] Heaps: A free, open-source and cross-platform game e...
___________________________________________________________________
Heaps: A free, open-source and cross-platform game engine
Author : technophiliac
Score : 463 points
Date : 2022-04-09 19:00 UTC (1 days ago)
(HTM) web link (heaps.io)
(TXT) w3m dump (heaps.io)
| farmin wrote:
| 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.
| Karliss wrote:
| 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.
| farmin wrote:
| Ok thankyou for that. Html5 seems to be path of least
| resistance. The demo's seem to perform quite well on the Web.
| wetpaws wrote:
| The loading times and performance in the browser are absolutely
| mindblowing
| __ryan__ wrote:
| 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
| xolve wrote:
| > - Haxe is held back by not being self-hosted [0].
|
| Why is that a problem for Haxe adoption?
| virtualritz wrote:
| 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.
| rahil627 wrote:
| baddash wrote:
| is there some news/development recently regarding Heaps? or is
| this just a general awareness post?
| cpeterso wrote:
| 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.
| redundantly wrote:
| 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.
| cardanome wrote:
| 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.
| JoeyJoJoJr wrote:
| 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.
| cardanome wrote:
| 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.
| chii wrote:
| > 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.
| bstar77 wrote:
| 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.
| irskep wrote:
| 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.
| cpeterso wrote:
| 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/
| syntheweave wrote:
| 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).
| Mikeb85 wrote:
| 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.
| chii wrote:
| 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.
| bstar77 wrote:
| 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.
| rahil627 wrote:
| tsujp wrote:
| 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!
| hyuuu wrote:
| 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.
| chii wrote:
| > 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.
| haxiomic wrote:
| 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
| [deleted]
| foxbee wrote:
| This sounds awesome. And credit to the team for creating such a
| nice platform. The 3d api looks real nice, and simple!
| xyst wrote:
| what happened to just using Vulcan
| kryptiskt wrote:
| 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.
| Narishma wrote:
| If you mean Vulkan, there are a lot of platforms where it's not
| available.
| logo4poop wrote:
| 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/
| leoncvlt wrote:
| 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]
| larsiusprime wrote:
| 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.
| JoeyJoJoJr wrote:
| +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
| larsrc wrote:
| How hard can it be to pick a name that doesn't clash with a
| common data structure?
| dalmo3 wrote:
| Heaps.
| [deleted]
| nazgulsenpai wrote:
| 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
| woldenron wrote:
| How hard it would be to target FreeBSD?
| squarefoot wrote:
| 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.
| klodolph wrote:
| You can remember that there was a vibrant community of Flash game
| developers before the demise of Flash (EOL December 2020, the
| date of its "demise" is debatable). There's not really a
| replacement for Flash and the community kind of fragmented.
|
| 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.
| telchior wrote:
| 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.
| klodolph wrote:
| 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>
| kovac wrote:
| Or click on the link to the source and see for yourself.
| apple4ever wrote:
| Its not a lot of work to have a quick line "HaXe (which
| Heaps is written in)...".
| strken wrote:
| 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.
| faitswulff wrote:
| comment = "This is written in Haxe. " + comment;
| klodolph wrote:
| Yes, that's exactly the kind of thing which I think is a
| waste of time/effort.
| apple4ever wrote:
| Why? Its not hard and and very helpful.
| faitswulff wrote:
| And being helpful to readers is helpful for getting your
| point across.
| koonsolo wrote:
| 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.
| throwaway82652 wrote:
| 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.
| nine_k wrote:
| (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.
| throwaway82652 wrote:
| 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?
| jan_Inkepa wrote:
| >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.
| MattRix wrote:
| 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.
| Bigpet wrote:
| 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.
| throwaway82652 wrote:
| >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.
| torginus wrote:
| 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.
| klodolph wrote:
| 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.
| nine_k wrote:
| 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?
| throwaway82652 wrote:
| I don't know, I was asking you!
| munificent wrote:
| _> as opposed to people who get excited about engines,
| architectural patterns, and programming languages._
|
| I feel attacked.
| [deleted]
| jupp0r wrote:
| Well the people who used to be excited about Flash certainly
| were not excited about any of the things mentioned above.
| remram wrote:
| Are all the games featured on the frontpage (as screenshots)
| actually built with Heaps?
| larsiusprime wrote:
| Yes and yes.
| remram wrote:
| Impressive.
|
| For everyone else, those are Darksburg, Dead Cells,
| Northgard, Evoland.
| foxbee wrote:
| 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
| thejeswi-nk wrote:
| Ew, no not every page.
| nullfish wrote:
| 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.
| noduerme wrote:
| 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.
| tkp wrote:
| 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
| afrodc_ wrote:
| 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.
| stryan wrote:
| 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).
| imachine1980_ wrote:
| 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...
| BolexNOLA wrote:
| That was an absolutely fantastic read. Thank you for that!
| mftb wrote:
| At first glance it looks pretty nice. I wonder why it hasn't
| gotten more attention? Or did I just miss it?
| ergo14 wrote:
| I really love what Nicolas is doing. But it kinda feels like
| whole Haxe ecosystem driving force is this one guy.
| tkp wrote:
| 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.
| postalrat wrote:
| I think it's a victim of godot's popularity.
| rahil627 wrote:
| setr wrote:
| 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
| rahil627 wrote:
| orthoxerox wrote:
| 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.
| Hemospectrum wrote:
| 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.
| Buttons840 wrote:
| 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.
| msk-lywenn wrote:
| And all Shiro games: Northgard, Darksburg, upcoming Wartales
| and Dune games. Not sure about Evoland but I wouldn't be
| surprised.
| keb_ wrote:
| Yep, Evoland too! Shiro Games was founded by the creator of
| Haxe (Nicolas Cannasse). Smart guy.
| k_ wrote:
| iirc evoland 2 was made with Heaps, and evoland 1 with what
| then became heaps.
| ThinkBeat wrote:
| 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?
___________________________________________________________________
(page generated 2022-04-10 23:02 UTC)