> Papers, Please was originally written in Haxe/OpenFL, a combo of modern ECMA-ish language, Flash-alike API, and multi-platform build system. [...]

> When I finally committed to this port my first decision was to rewrite the game in C#/Unity. After Obra Dinn I’m a solid fan of Unity – the editor, the entity/component design, the build system, the ubiquity, just about everything.

> I made it a few days into rewriting before finding that although I like C#, I like Haxe more. [...] Still it’s hard to overstate how appropriate Unity is for someone in my position: a solo developer targeting multiple platforms and desperate for a popular, proven, and well-supported engine and build system.

> Fortunately, Haxe is a transpiled language, meaning that you write in one language (Haxe) and it gets converted to another language (Javascript, PHP, Python, C++, C#, Lua, etc) before being compiled/interpreted for whatever target you’ve got. So it’s possible to write code in Haxe and have it transpiled to C# that can be loaded and compiled in Unity. Which is how I decided to roll this.

From "Cramming 'Papers, Please' Onto Phones" (last year).

Original post: <https://dukope.com/devlogs/papers-please/mobile/>

HN comments: <https://news.ycombinator.com/item?id=32371423>

I used it a few years later for some work with Nickelodeon. Somewhere in a backup I have some Spongebob games and a version of Pai Sho.

Haxe was never great, but it was a bit more efficient and productive than using the GWT-based PlayN (formerly Fourplay). The language itself was just not quite right and felt like a harder version of Java or JavaScript.

It's not really a problem anymore, but compiling to ActuonScript used to be pretty buggy. Now that Flash is long dead, it's possible that the cross-compilation problems might be lessened.

They also may have added some additional features making it less painful, but I'm not convinced.

Very tangential, but: the last time I looked into this (many years ago) the only full rules for Pai Sho I could find on the internet were improvised by fans. Can you share any more about the construction of your version? Is it still playable online somewhere?

I have the set of rules we built, and the "dumbed down" version of the rules that had to be presented to the world. The source code lives in a zip file somewhere and I may be able to dig that out.

Send me an email and I'll fire off a few things.

I use Haxe personally and professionally, and I love it. My use case is slightly different though, I work in R&D, so the emphasis isn't on production code but on getting a wide-ranging set of proof-of-concepts built quickly. For example, my current project required that we run the same logic in a Java service, Java client, Python client, and (coming soon) Javascript and C++ clients. Haxe worked great for getting that infrastructure up and running quickly in all of those locations so that production teams could start experimenting. I find that Haxe is great for that use case, I've got a core set of utiltiy libraries that I've been using for about a decade now that run in Java, Python, C++, and Javascript, so for a given new project I've already got a good set of code that I can use.

I've also written Maven plugins - and later when I ditched Maven, Bazel rules - to incorporate Haxe projects into our build systems that work pretty well. This makes it pretty seamless to incorporate say a Haxe built Java library into a project, and the same utilities in Javascript - including debugging in Eclipse or the browser.

It's not all sunshine though, I find that Haxe-compiled Python code tends to be underperformant and needs a lot of love to become as performant as, for example, the equivalent Java code. And it is true that the community is smaller, so it can be hard sometimes to get answers to questions. But it's still fun to write and work with, and I definitely see myself continuing to use it in the future.

I'm really curious why you need all those targets? Sounds like a perfect fit, tho.

I work for a very large company, with lots of different software products, and our group specifically looks at cutting edge stuff. So it's not uncommon that we may be trying to hack a shiny new square peg into a decades old round hole, plus a few triangle holes, so that we can demo a potential feature. We try to make good choices where we can, but having a flexible and consistent set of utilities to draw from is definitely helpful.

I've used Haxe on the web for a minimalist virtual tabletop. Not exactly production, because the only user is probably me... but my gaming group and I have used it weekly for a couple of years now, and I don't need to spend time fussing over it. So production enough.

I've found Haxe to be pretty pleasant in this situation. The only areas I really needed a library were around graphics and input, and Heaps looked more interesting to me than the JS alternatives I looked at.

The language itself feels like a pleasant mush of all the Java-y OO languages, but without the entire kitchen sink included. You've got all the polymorphism and generic typing stuff you'd expect from a java clone, plus algebraic data types, plus the ability to drop to dynamic duck-typing if you have to. And the type inference has worked pretty well for me. Oh, it also has a macro system I've never needed to use.

The tooling situation is good but not great. The compiler's messages have generally been clear. I am using vim + universal ctags for development, and it is fine but not as deluxe as a working LSP. I didn't have any luck getting Haxe's LSP working with vim, but I assume a VS Code based setup is more of a happy path and would have better luck.

Output-wise, the JS it generates seems fine. For my particular use case I care more about the readability and debuggability of the generated JS rather than the size. It has not been a problem to understand where an issue is coming from while looking at the generated JS.

Performance wise, the only issues I've had were caused by my own foolishness in making thousands of draw calls instead of batching things. Other than bugs I haven't seen any performance problems.

When it comes to libraries, you have to contend with both the relatively small size of the community, as well as the difficulty of writing a library that actually supports all of Haxe's compile targets. Haxe errs on the side of pragmatism instead of identical behavior on all of its supported platforms. So often you'll find nasty platform-specific logic in the heart of libraries, and if your target isn't supported then you have to dive in and fix it yourself. It is not a good language for grabbing a few things off of npm or cargo and slapping them together.

I would love to see your code.

Haxe is my favorite programming language. I recommend hanging out in the Discord, the community is quite active! We have had new frameworks like Ceramic [0] popping up and one of the (imo) best UI libraries: HaxeUI [0] be continuously developed. There is a bit of unrest on the future of Haxe, but I have seen development pick back up recently.

[0] https://ceramic-engine.com/ [1] https://github.com/haxeui/haxeui-core

What kind of unrest? Are you able to provide any details?

I can't speak for everyone, but the main thing for me is how hard it can be to get PRs in Haxe sister projects merged (i.e haxelib and Hashlink). Typically pinging one of the main developers works out. I heard that Shiro Games has sponsored a developer to work on Hashlink full-time, not sure on if they are working on it right now.

The person who made Haxe (Nicolas Canesse) went on to found Shiro Games (https://shirogames.com), a game development company. I believe all their games are made in Haxe. The latest one, "Dune: Spice Wars" was released this September and Google says the engine is HashLink (https://hashlink.haxe.org/) which is a VM for Haxe.

I don't know any other companies who are releasing games in Haxe today.

I was surprised when found out some of the most successful indie games are made in haxe - Dead Cells, Papers Please, Dicey Dungeon, Northgard, rymdkapsel etc.

They made Evoland, which is a very cute game which begins with basic monochrome Game Boy-style graphics and becomes progressively more modern as you advance. It’s really fun, especially if tech history is your thing.

And Evoland 2 was pretty neat, if not a bit more... Strange, when it comes to transitions between gaming systems.

I use Haxe and really enjoy it. I use it to develop an MMORPG (https://jamcloud95.com).

I've remember going through quite a few different game engines (Godot, Unity, Defold, etc.) but HaxeFlixel had the most "natural" feel for me to code in, which is largely due to Haxe itself.

Can't enter any letters into the codename/pass/email prompts under android chrome, so can't get passed email prompt. Probably not the right place for bug reports though.

I'll take bug reports anywhere I can get them. I'll see if I can reproduce it—and thanks for the heads up! A dedicated Android version is also on the way.

For years I worked on interactive contents for museums and such. Mostly using Adobe Air (Flash with AS3).

At one point around 2014 I was looking for alternatives and tried Haxe with OpenFL. I loved the language but the ecosystem was super fractured. I remember something was breaking on the latest version of OpenFL and the cause was in some intermediary layer to make the whole thing work (Lime IIRC).

When I started a gamedev project with some friends last year we considered Haxe against other engines/frameworks. Most of us had touched flash/actionscript game-making in the past in some way, so it was an interesting choice (less to learn). In the end, Godot easily beat out Haxe given the popularity, which go a long way to making development easier and more fun. I don't doubt it's mature in its own way, but I think we made the right choice.

I've found tons of resources and cool people in the Godot environment that I've worked with. I'm taking a break on the game to develop new features for an addon we use in-game with the maintainer on things, which is not something you get as often with a more seldomly used platform. All to say, I'm satisfied with our decision.

I used it in conjunction with OpenFL a few months ago to port a Flash project. My impression is Haxe itself is pretty solid as a language but I could only get the web-based target to work consistently. The C++ backend seems dead based on the repo activity[1] and I got GC-related crashes with no workaround. I could never get the native Android support working either since it crashed on startup.

Also OpenFL was missing some Flash features the project relied on and I had to spend a lot of time on a fork of their repos patching them in.

[1] https://github.com/HaxeFoundation/hxcpp/graphs/contributors

I used it for a few research projects around the same time. Overall it was a good experience, even after wresting with the macro system, and I was very sad it didn't reach wider adoption.

A few years later I tried to rebuild an old project running openfl 3.0 and failed miserably. I ended up building a docker running an old base image to get it working. That made me realize that the haxe community toolchain also evolves quickly in a non-compatible way.

The TypeScript ecosystem already way too large and way too fast. It's hard to follow both. It's also harder to find collaborators / hires.

In a fantasy world a megacorp would pick up haxe as a main driver and pump money into the ecosystem and make lots of people haxers.

I ended up using it to play with development around 2013 for writing an algorithm that could be cross compiled to "any programming language" [1]. Really think about Haxe often and like it but have not found a personal necessity to use it again.

[1] http://blog.databigbang.com/searching-for-substrings-in-stre...

Not using it myself, but there is an insanely well done fan-made game called “MegaMan X: Corrupted”[1][2] which uses Haxe for a custom-made game engine. It has been years (and is still) in development and they sometimes live-stream development and game testing on Twitch.

- [1] https://jkbgames.com/w/index.php/MegaMan_X:_Corrupted_Wiki

- [2] https://www.youtube.com/user/jkbproductions

It's probably the best way to get into game development if you already have some programming experience (LOVE 2D if you're inexperienced). I tried it a while back but when I did the documentation left much to be desired.

I’ve used it for game dev stuff with HaxeFlixel, but trying to do anything more than that ended up being a pain. The community around it seems to have mostly moved on: a lot of libraries are unsupported or haven’t been updated in years and there’s not a lot of places to find help when you run into problems. I really like Haxe as a language, but I really don’t see a bright future for it personally, especially with how popular TypeScript has become.

I used it for years, but it's been a while.

I mainly used it because it brought some sanity to the whole Javascript landscape, especially at the time where many frontend libraries were pretty immature.

Never really used it for anything because as a Javascript transpiler though.

Haxe is a nice language, but it's doesn't really allow you to deploy any haxe code on any languages runtime.

It doesn't provide a consistent enough api across all of the language backends. For example, the tink http framework only targets node and php.

I poked it a while ago for a project but found some important bits missing for what I was trying to accomplish. It may well be better now, this was over a year ago and maybe closer to two.

I'm using Haxe actively today to preserve the very reason why Haxe exists.

Haxe was created by Nicolas Cannasse, also known as warp. He was a software developer at french game studio Motion-Twin in the 2000's. At the time they were producing web games using PHP and Flash. This required some shared logic both in the client and server; which caused some duplication. As any engineer in his situation, he decided to solve this with his own compiler. :D

One of the earliest languages he created was Motion Script, a an AS inspired language compiling to the AVM1 bytecode (SWF). You can see some examples in their 2006 game Hammerfest [0]. Haxe is a successor language with the promise of being compatible with many platforms. It's pretty remarkable in this way as one of the first languages offering expansive target of multiple _platforms_. Not just CPU architectures or OSes, or languages with a dedicated VM. Haxe was pretty successful, and and all Motion-Twin games since around 2008 used this language. It's used even today with their latest releases such as Dead Cells. Warp left Motion-Twin to create his own studio Shiro Games and is also obviously still using his language: Evoland, Northguard, Dune spice wars all use it.

From my side, I'm working on Eternaltwin [1], a project to preserve Motion-Twin's web games. Games that were more reliant on the server side were migrated to regular JS; but client heavy games such as Hammerfest, AlphaBounce, their Kadokado games, Fever, etc. use Haxe.

We use Haxe as a way to migrate off Flash. In particular, we had many user-made content using Flash. In the last five years, we migrated almost all of it to Haxe while still compiling to Flash 8; and we are now preparing to target HTML5 - but it requires removing all the Flash specific-bits. Doing it in two steps allows to perform the migration incrementally. It also requires use to move to more recent versions of Haxe. Due to the specifics of our project, we're stuck using Haxe 3.1 (to target Flash 8), we even sent a few bugfixes to this old version to ensure it keeps compiling today...

Regarding Haxe itself, I'd say that it's a very impressive language and probably a very solid choice if you are creating a video game and need to target multiple targets. It's good for final applications. However, I feel that it falls short as a language for libraries. It felt very well suited for me to implement schema validation and client libraries. Write them once in Haxe and export for Node, the JVM, Python, PHP, etc. in one go. To support all those targets, it needs to bring its own compat layer that makes it less ergonomic to use Haxe libs from target-native code. It also requires a lot of macros; which tend to be less well supported by editors. Regarding tooling, their package manager improved a lot I feel and now supports project-local dependencies with lock files and they have a nice builtin doc generator.

Regarding integration, there are still some slight oddities; like _requiring_ an env variable to find the standard lib.

To sum it up; it's a pretty nice language, but I feel like it's also showing its age (it still feels very attached to older OOP styles found in Java or AS3).

[0]: https://github.com/motion-twin/hammerfest/blob/master/class/... [1]: https://eternaltwin.org/

There was a company in Boulder that was using it, at least a little, as recently as 2019.

I use it in game development, it’s nice for those purposes.

This is a complete non-answer. I'd assume that they know that Haxe isn't as popular as other languages, but they're asking about people's experience with Haxe, not looking for recommendations on which language to learn.

Correct

Sounds more like a chat bot answer, TBH. It misses the point of the question in a much too subtle way.

Nah, it's a common beginner misunderstanding.

There's a huge genre of blog posts and Reddit threads where beginners tell other beginners which language is best to learn to get started with programming. My guess is that OP mistook this thread for one of those.

I used Haxe in the past. While it isn't necessarily modern usage I'd agree with the parent comment and suggest either Rust (using the WASM target) or TypeScript.

Compiler ergonomics are important for me these days.