Phaser CE keeps Phaser 2 games running while Phaser v3 moves on

A maintenance edition of the Phaser 2 framework

Phaser CE, the community edition, is a fork that continues the Phaser 2 line rather than a new framework. The project says it plainly: Phaser CE is based on Phaser v2.6.2 by Photon Storm, and Phaser is the current and fully maintained version. That single sentence tells you how to think about everything else here. This is a repository for keeping shipped games alive, and it is deliberately frozen in the past relative to the upstream project. The audience is studio teams and hobbyists with a Phaser 2 title that still earns revenue or still needs a port, plus anyone who has a large body of Phaser 2 example code to learn from. The project describes over 700 Phaser 2 examples with full source and assets, mirrored in a separate repository, and points at a forum, a Discord channel and two CodePen templates for people who want to try the API with nothing but a browser. Nothing here is aimed at a team starting a new game in 2026.

Pixi does the rendering, and three globals must exist

Rendering is handled by a custom build of Pixi.js that supports both WebGL and Canvas, so a game runs on a desktop or mobile browser with either renderer available. Above that sit the two things that define the shape of the library. The first is that Phaser CE is developed in ES5 JavaScript and deliberately imposes no structure: the documentation states you will not find it split into modules, that it does not require a build step, and that it does not force a class or inheritance approach, while noting that none of that stops you from using those patterns yourself. The second is the global namespace. Everything lives under one single global, and you cannot require selected parts of it into a build. The framework expects three globals to exist for it to work properly, `Phaser`, `PIXI` and `p2`, where `p2` is the physics library. In a plain script tag setup the library creates them for you. In a bundler setup you have to assign them yourself, and that is the subject of the next sections.

Getting the library into a page, from npm or the CDN

The quickest route is npm, and the package is published as `phaser-ce`.

npm install phaser-ce

The package main entry is `./build/phaser.js`, and the published files are the build output, the filters, the Gruntfile, the source, the Grunt tasks and the TypeScript definitions. If you would rather not install anything, the project is on jsDelivr and the documentation gives the script tags for the full and the minified build.

<script src="https://cdn.jsdelivr.net/npm/[email protected]/build/phaser.js"></script>

<script src="https://cdn.jsdelivr.net/npm/[email protected]"></script>

For local development the project recommends running a static server, and it gives a one line install of `http-server` and a one line command to serve the current directory with caching disabled and the browser opened.

npm install -g http-server

http-server . -c-1 -o

The browser requirement is a canvas capable browser, which the documentation lists as Internet Explorer 9 and above, Firefox, Chrome, Safari and Opera on desktop, plus iOS Safari, the Android Browser and Chrome for Android on mobile.

Why Browserify and Webpack need the globals assigned by hand

Because the library is not modular, using it with a bundler requires an extra step, and the project is explicit about the reason. Phaser CE and Phaser 2 before it were not written to be modular, everything exists under one single global namespace, and you cannot require selected parts of it into your builds. The fix is to require the pieces and assign them to the three global names the framework expects, in a fixed order.

window.PIXI   = require('phaser-ce/build/custom/pixi');
window.p2     = require('phaser-ce/build/custom/p2');
window.Phaser = require('phaser-ce/build/custom/phaser-split');

For Webpack the documentation gives the same advice, using the `pixi`, `p2` and `phaser-split` modules from the `build/custom` directory and the `expose-loader` to expose them under the names the framework reads. The order matters in the snippet above, and getting it wrong produces a framework that loads with pieces missing rather than a clear error. If that friction is the deciding factor for you, the project states that full module based development is available in Phaser v3, which is the direct answer for anyone starting something new.

Custom builds that split pixi, p2 and phaser into separate files

The `build/custom` directory is the answer to two problems at once. The custom build splits the three core libraries out into their own files, which is what makes the `require` calls in the previous section possible, and it also lets you ship a smaller file when you only need part of the framework. The CDN exposes these custom builds, and the documentation gives an arcade physics build as the example.

<script src="https://cdn.jsdelivr.net/npm/[email protected]/build/custom/phaser-arcade-physics.js"></script>

Building them yourself is a Grunt task, since the repository carries a `Gruntfile.js` and a `tasks/` directory at the root, and the npm scripts wire the common jobs together. The `test` script runs the source lint and the TypeScript declaration checks in sequence, `test:src` is an eslint pass over `src`, `test:ts` runs `tsc` with `--noImplicitAny` over the declaration files in `typescript/`, and `test:build` runs a node syntax check over the compiled output in `build/` and `build/custom/`. The `test:dist` script goes through grunt and then checks the distribution bundle. So a contributor has both linting and type checking available as separate commands rather than one opaque build.

ES5 source with TypeScript definitions for old compilers

There are two different eras of tooling in this repository, and they do not quite line up. The library source is ES5, which is a deliberate choice for the browser support range described in the requirements section, down to Internet Explorer 9. Alongside it there are comprehensive TypeScript definition files in the `typescript` folder, and the documentation says they target TypeScript 1.4 and later, which is a very old compiler version. The package points `types` at `./typescript/phaser.comments.d.ts`. The consequence for a modern team is that the typings are documentation shaped like compiler input rather than something written for a current `tsconfig`, and the definitions cover `phaser`, `pixi` and `p2` as three separate declaration sets that the `test:ts` script type checks individually. The documentation also notes that a browser with a canvas tag is required, and warns that device limits, especially memory and GPU limits on mobile, and legacy HTML5 compatibility, are worth accounting for before a title ships on a range of hardware.

A version string kept in five places

The release history tells you how this repository is maintained. The latest tag is v2.20.2, published on 2025-03-04, the package version is `2.20.2` with a release date of 2025-02-20, and earlier tags sit at v2.20.1 from 2024-10-08 and v2.20.0 from 2022-12-13. The last push to the default branch was on 2026-10-19, so commits continue to land well after the newest published release, which is the pattern of a maintenance branch that accepts fixes without cutting a new numbered tag for every change. The version is duplicated across the codebase, and the project guards against drift with a dedicated npm script that greps for it in `src/Phaser.js`, `build/phaser.js`, `package.json`, the `CHANGELOG.md` heading and the readme release tag. If you fork this or patch a build, that script is the thing to run before you publish. The licence is MIT, so vendoring the library into a commercial game carries no distribution obligation beyond keeping the licence text.

Phaser CE against Phaser v3, and the plugin ecosystem question

The alternative to Phaser CE is Phaser itself, and the project is direct about the difference in approach. Phaser v3 is distributed as a modern framework with full module based development, so the global namespace and the manual `window` assignments disappear, along with the extra bundler configuration the older line requires. That is not a free change, because the v2 and v3 APIs differ and a working Phaser 2 game is not a Phaser v3 game. The counterweight is the plugin ecosystem and the example corpus: the project points at Phaser plugins on GitHub and on npm under the `phaser-plugin` keyword, and at over 700 Phaser 2 examples with their source and assets, none of which transfer to the newer API unchanged. So the real decision is about the age of the code you are responsible for. Maintaining a Phaser 2 title means the plugins, the examples and the existing code stay usable, which is what Phaser CE is for. Starting something new means the API you learn today will be the one that still exists, which is what Phaser v3 is for. A middle path exists for teams with a large v2 codebase and a long runway, and that is a migration project rather than an adoption decision, with a Phaser 2 to Phaser 3 upgrade guide in the upstream documentation as the starting point.

Editorial conclusion

Adopt Phaser CE if you are maintaining an existing Phaser 2 game and need the 2.x API, the Phaser 2 examples, or the plugin ecosystem that shipped against it, and if you can live with a global namespace and an ES5 codebase. Skip it for anything new, because the project states that Phaser is the current and fully maintained version and that Phaser v3 offers full module based development, and skip it if your target devices are modern-only and you can afford the migration. Verify three things first: that the version you pin matches the `phaser-ce` package version your build expects, that your game does not depend on the P2 physics polyfills for IE9 unless it truly does, and that the `check-version` npm script passes, since the version string is duplicated across `src/Phaser.js`, `build/phaser.js`, `package.json`, the changelog and the readme.

Frequently asked questions

Official sources

1. License: MIT
2. phaserjs/phaser-ce on GitHub
3. Project website
4. README
5. Releases