Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Source Haxe/OpenFL Platform Will Support Home Game Consoles

Posted by timothy on from the do-it-yourself dept.

lars_doucet writes: At last week's World Wide Haxe conference, a coalition of game developers announced that the open source platform Haxe/OpenFL is coming soon to home game consoles. The first three games that will ship using the technology are Yummy Circus, Defender's Quest (HD edition), and the award-winning Papers, Please. Haxe is a programming language that compiles to other programming languages (everything from C++ to Javascript to Python), has been around for about 10 years and is quite powerful. OpenFL is a hardware-accelerated cross-platform reimplementation of the Flash API, built on top of Haxe (but does not have the Flash player's performance and security limitations and has nothing to do with Adobe), and is built on a low-level cross-platform layer called Lime, which can be used separately for those who have no need for a Flash-like API. This could eventually lead to console compatibility for engines that are built on top of Haxe/OpenFL, such as Away3D, Stencyl, HaxeFlixel, and HaxePunk.

Six console targets are planned: Wii U, PS4, Xbox One, PS Vita, 3DS, and PS3; footage of demos running on the Wii U was presented at the talk and are included in the linked article.

13 of 20 comments (clear)

  1. Flash for consoles? by Em+Adespoton · · Score: 1

    So is this basically a framework that allows people to port all their Flash games to the console? Because at the end of the day, that's what it sounds like.

    Adding another layer of abstraction means adding another layer of non-optimization in the coding process. For desktop apps, that's not too big an issue; but consoles have a longer upgrade cycle and a restricted memory footprint.

    So for games that don't push the hardware in the first place, this should work fine -- such as porting a bunch of Web Flash games. But for doing anything serious, you're going to want to get as close to the metal as possible.

    What I'd REALLY like to see for consoles is an asset optimization system -- something that will package up game assets in the optimal format for storage/loading on each platform. Then the coding becomes much simpler.

    1. Re:Flash for consoles? by lars_doucet · · Score: 2

      What you're basically asking for is the underlying Lime layer which is a part of this solution. The "OpenFL" part -- the Flash API implementation, is a convenience layer that would, yes, make it possible to port flash games to consoles, but the underlying Lime layer is pretty close to the metal and does as little as possible while unifying things like asset management and providing direct access to a consistent rendering API.

      This compiles down to native C++ output making hardware calls and unlike Unity, does NOT rely on a virtual machine.

  2. Re:Just want to play a damn game by murdocj · · Score: 1, Informative

    I hope you can get more for your kidney that the $10 or so a Steam sale game will cost you. I also hope game makers continue to be paid so there will continue to be games.

  3. Re: Just want to play a damn game by lars_doucet · · Score: 1

    For the record, Haxe was created 10 years ago, before Typescript and transpiling was cool.

  4. memory management by phantomfive · · Score: 2

    I've been looking through the Haxe documentation, but I can't see how it does memory management. Does anyone know? Is it garbage collected?

    --
    "First they came for the slanderers and i said nothing."
    1. Re:memory management by lars_doucet · · Score: 1

      Yes, it does use a garbage collector.

  5. Papers Please by NotDrWho · · Score: 1

    Heard good things about that game. Look forward to seeing it in the PSN store.

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
  6. Re:So, not FOSS anymore? by lars_doucet · · Score: 4, Interesting

    That's actually a concern of ours and we've designed the architecture around it to leave as much code as possible open source. To be clear we are NOT creating a new, non-open-source fork. We're using the existing public stack of OpenFL and Lime you can find today. However, as you can read in the article, we're building console-specific "batteries" that slot into the very last mile of the console stack as a separable library that can be safely distributed under the terms of console NDA's, without putting any burden on the existing public codebase.

  7. Re:So, not FOSS anymore? by Gibgezr · · Score: 2

    And you are charging for the console batteries, and they are not open source. The summary makes it sound like everything is open source and free, but the console stuff is not. I'm not being judgmental here: I understand why that stuff can't be free and open, but the summary is somewhat misleading.

  8. Re:So, not FOSS anymore? by r0ckstar · · Score: 1

    Lars, this are great news. Nice work! How can we get access to this version? We have some OpenFL games already published and we're working on new ones. Also we have PSVita dev kits (and of course NDA signed with Sony).

  9. Re:So, not FOSS anymore? by lars_doucet · · Score: 2

    Yeah, that's fair. I'd update the summary if I knew how; I thought that was implied as the last mile of any console solution is bound by proprietary terms, but in retrospect I see how it's confusing.

  10. Re:So, not FOSS anymore? by lars_doucet · · Score: 1

    Send me an email at leveluplabs at gmail dot com !

  11. Re:So, not FOSS anymore? by Gibgezr · · Score: 1

    Good luck with the project; the addition of a way to bridge to consoles is a very nice feature, even if it can't be FOSS.