# HaxeFlixel: a 2D engine where the ecosystem outgrew the core > A Haxe and OpenFL port of a 2011 ActionScript codebase, now a family of libraries, demos, templates and tools. Strong on 2D cross-platform release; thin README. **HaxeFlixel/flixel** — Free, cross-platform 2D game engine powered by Haxe and OpenFL - Repository: https://github.com/HaxeFlixel/flixel - Website: https://haxeflixel.com/ - Stars: 2,214 · Forks: 527 - Language: Haxe - License: MIT - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/haxeflixel-flixel ## A 2D engine built on Haxe and OpenFL HaxeFlixel is a free, cross-platform 2D game engine written in Haxe on top of OpenFL. That pairing is the whole technical story, and it is worth unpacking because it determines both the strengths and the constraints. Haxe is a language that compiles to many targets from one source, and OpenFL is the Lime-derived runtime layer that gives Haxe code access to native rendering and input on desktop, mobile and web. The README states that HaxeFlixel targets these platforms natively rather than through an emulator or a compatibility shim, and it illustrates the list with a platforms image rather than enumerating them in text. The licence is MIT and the project lives under the HaxeFlixel GitHub organisation rather than a personal account, with the engine itself in this repository. The topics list is candid about the domain: 2d-game-engine, game-engine, cross-platform, haxe, haxelib and openfl. Distribution runs through Haxelib, the Haxe package manager, and the README links the project's package page on lib.haxe.org along with a version badge and a download badge. So the pitch in one sentence: if you already write Haxe, this is a 2D engine you can install as a library and target broadly. If you do not write Haxe, the cross-platform story costs you a language to learn, which is a different deal than the same trade in a language you already have. ## From Adam Atomic's Flixel to a 2011 Haxe port The lineage is unusual enough to be worth knowing, because it explains both the API shape and the community. HaxeFlixel descends from the original ActionScript 3 version of Flixel, created by Adam Saltsman, who is credited in the README by his handle Adam Atomic. Alexander Hohlov started the Haxe port in 2011, and the README describes the beginning in plain terms: a straightforward Haxe port of the ActionScript codebase, which also absorbed Richard Davey's Flixel Power Tools. That origin story explains a great deal about the design. Flixel was built around display list objects, tweens and a tile map, and a direct port keeps that vocabulary intact, which is why HaxeFlixel code and Flixel tutorials share a shape. It also explains a limitation. Code written for the ActionScript original is written against a Flash runtime that no longer exists, so expectations set by old Flixel material do not always carry over to the current Haxe implementation. The README does not claim feature parity in either direction. It says today's HaxeFlixel far surpasses the capabilities of the original, citing substantial core improvements, new features, a richer ecosystem of additional libraries, and over 80 demo projects to learn from. The project also credits over 100 contributors and points at a core team on GitHub, so this is distributed maintenance rather than one maintainer's project. ## The ecosystem is the actual product Look at the repository links at the top of the README and a pattern appears: this repository is the engine, and everything you will actually use sits next door. There is flixel-addons for extra libraries, flixel-ui for interface components, flixel-tools for tooling, flixel-templates for project scaffolding, flixel-demos for the examples, and flixel-docs plus the haxeflixel.com site for documentation. Six sibling repositories, each solving a problem you would otherwise solve yourself. That structure is the strongest argument for the project, and it is also the biggest evaluation problem. When you assess an engine, you are really assessing the engine plus the addons you will use plus the demos you will copy from, and only the first of those is in this repository. A framework can look thin in isolation and productive in practice, which is exactly the case for an ecosystem-first 2D engine. The demos deserve the emphasis. The README points at over 80 demo projects in flixel-demos, and a showcase image links to haxeflixel.com/showcase. For a 2D engine, the fastest way to judge whether it fits is to look at what finished games and prototypes look like when built with it, because 2D engines mostly differ in sprite handling, tilemaps, text, audio and input rather than in anything fundamental. ## What the repository tree reveals about the build The tree is short and tells you more than the README does. The engine source lives in `flixel/`, tests in `tests/`, and build scripts in `script/`. There is a `haxelib.json` at the root, which is how a Haxe project declares itself installable as a package. Assets and images directories sit alongside the source, and a CHANGELOG.md indicates version history is tracked in the repository. The peripheral files are the interesting part for anyone wondering how releases work. There is a `release.sh` and a `release.bat` at the root, so release automation is expected to run on both Unix and Windows. `include.xml` and `run.n` are Neko build artefacts, which is normal for the Haxe ecosystem because neko is the intermediate runtime many Haxe build tools use. `checkstyle.json` and `hxformat.json` indicate enforced Haxe formatting and lint configuration, and `.codeclimate.yml` points at hosted code quality analysis. Two details there deserve a second look. The default branch is `dev` rather than `main`, and the CI badge in the README points at a workflow filtered on the dev branch. For a Haxelib package, that means the branch you see by default on the repository is the working branch, not the last tagged release, so if you are pinning a version, pin it through Haxelib rather than by cloning and hoping. Also worth noting: this repository publishes no GitHub releases, so the CHANGELOG.md file and the Haxelib version badge are the version signals available. ## The README is a link directory, and that is the honest read It would be unfair to criticise the README for what it is. It is about three thousand characters long, and almost all of it is navigation: a logo, badges for CI, Discord, Haxelib version, Haxelib downloads, licence and Patreon, followed by a short list of the most important links. Getting Started, the documentation index, the API reference, and the community page are the four destinations it names, and there is a Turkish translation of the readme in the tree as well. What it does not do is describe the architecture, list components, show a class hierarchy, or document the API. None of that is here, and the README does not pretend otherwise: it points you to haxeflixel.com for the documentation and to api.haxeflixel.com for the API. For an engine that has been developed since 2011 and credits over 100 contributors, that documentation has had fifteen years to accumulate, and the risk is not that it is thin but that it spans two generations of the project. Community and support channels are present too: a Discord invite, a CONTRIBUTING.md for code and issues, and a Patreon for funding. The last push was on 2026-08-23 and the repository is not archived. ## When HaxeFlixel is the wrong tool The clearest case against it is 3D. This is a 2D engine, and the repository says so in its description, its topics and its docs. If your project needs 3D rendering, you are outside what this codebase is for, and the sibling repositories will not change that. The second case is team fit around Haxe. The cross-platform benefit is real, but it arrives bundled with the Haxe toolchain: Haxelib for packages, haxe compiler flags, and a build path that goes through neko artefacts. Teams with an existing Haxe investment get that for free. Teams that would be adopting Haxe solely to use this engine should weigh the language learning cost against the porting work they would otherwise do. The third case is when you need a heavily documented, actively released engine with published version tags and a conventional release process. HaxeFlixel has a CHANGELOG, Haxelib versions and release scripts, but this repository publishes no GitHub releases, so your upgrade path runs through Haxelib version numbers rather than through tags on this repository. That is workable and common in the Haxe ecosystem. It is just not what a team used to npm or cargo release habits will expect. ## Conclusion HaxeFlixel is a good fit when you are shipping a 2D game to several targets at once and want one codebase rather than a porting layer, and a poor fit when you want 3D, or when your team would rather not be on the Haxe toolchain. Two practical things to check before committing. First, judge it by the flixel-demos and flixel-addons repositories rather than by the engine repository, since that is where the evidence of what it can actually build lives. Second, budget for the documentation being elsewhere: the README is a link directory, and the substance is at haxeflixel.com and api.haxeflixel.com. The repository is not archived and the last push was on 2026-08-23, on the `dev` branch rather than `main`, which tells you where to watch for changes. ## FAQ ### Is HaxeFlixel a game engine? Yes. HaxeFlixel is a free, cross-platform 2D game engine written in Haxe and built on OpenFL, which lets one codebase target desktop, mobile and web natively rather than through emulation. It is distributed through Haxelib under an MIT licence. ### Is HaxeFlixel still actively developed? The repository is not archived and the last push was on 2026-08-23, on the dev branch, which is the default branch rather than main. Note that this repository publishes no GitHub releases, so the CHANGELOG.md file and the Haxelib version badge are where version information lives, alongside the sibling flixel-addons, flixel-ui and flixel-demos repositories. ### How is HaxeFlixel related to the original Flixel? HaxeFlixel started in 2011 as a Haxe port of the ActionScript 3 Flixel created by Adam Saltsman, and it also absorbed Richard Davey's Flixel Power Tools. That origin explains the shared API vocabulary, while the README states that the current Haxe version has moved well beyond the original's capabilities. ## Sources - [HaxeFlixel/flixel on GitHub](https://github.com/HaxeFlixel/flixel) - [Issues](https://github.com/HaxeFlixel/flixel/issues) - [License: MIT](https://github.com/HaxeFlixel/flixel/blob/dev/LICENSE) - [Project website](https://haxeflixel.com/) - [README](https://github.com/HaxeFlixel/flixel/blob/dev/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haxeflixel-flixel