This is part 2 of a series of articles evaluating web game engines. In part 1 I reviewed engine sizes.

Engines

For the next and last phase of evaluation, I selected the following engines:

1. Heaps
2. Phaser
3. PixiJS
4. ctjs
5. melonJS

Test requirements

I want to make sure the engine supports the features I will be using for the project. These include:

1. A “Character” (sprite) that can rotate towards and move to where you click or touch. Sprite art from Kenney.
2. Render a tilemap created with Tiled. Tilemap art from Kenney.
3. Basic collision detection against a specific tile.
4. Interaction with a specific tile: Colliding (overlap) with a specific tile would toggle some text to appear.
5. Render some text with a ttf font. Font is Gudea from Google Fonts.
6. Play music in the form of ogg or mp3. Music from soundimage.org.
7. Play SFX when interacting with a specific tile. Audio from soundimage.org.
8. Spritesheet animation test. Spritesheet from Kenney.

Implementation notes

These are my engine development experiences presented in chronological order.

Heaps

This was the first engine, and it was also my first time writing code in Haxe. It was quite intuitive and quick to get up and running. Since it was the first, some of my time was spent finding or creating assets that I ended up using with all the engines.

Phaser

I started with sample boilerplate Javascript in a HTML file. Most of the code structure was easily translatable from Heaps. I had to export the tilemap JSON slightly differently (using the “Embed in Map” option) for it to load correctly. The only other tricky part was ttf font loading, but there was a solution that worked well. Overall development was very quick and helped a lot by: basing the code after the Heaps project, having all the media assets ready, and Phaser having support for everything I wanted to test built-in. I also started to notice how engines handle sizes and scales differently.

PixiJS

Like Phaser, I started with sample boilerplate Javascript in a HTML file. PixiJS has a focused set of features, so I had to bring in other libraries. There are several tilemap-related PixiJS libraries, and it was a bit confusing to sort out which one did exactly what I needed. I ended up using pixi-tiled. I also needed pixi-sound for audio support. The Phaser ttf font link trick was required, and it even needed a further setTimeout (delay) hack to get the font to show up. Overall, the code was easily translated from the Phaser implementation. Most of the time spent was finding other libraries and writing my own collision math since PixiJS doesn’t provide a math library.

ctjs

This was the only editor-based engine in the list, and after about 10 minutes, I decided not to proceed with it. There are two main reasons. The first is that it has a built-in tilemap editor and doesn’t seem to support importing or loading from Tiled. The other is that the interface latency of the editor (ARM build on a Macbook Pro 2020 Apple Silicon) is too high; it seems to be using Electron. I found the latency to be frustrating.

melonJS

They have a boilerplate repo GitHub template which I used to generate a new project. It was easy to get started. It comes with a structure to follow for screen logic, resource loading, and game logic. I had to manually fix up part of the tilemap data (it reads the tiles image value differently than Phaser). It also required the Phaser ttf font trick as well. To test sprite sheet animation, I had to author some JSON. With the other engines, I could test animation purely from code.

Time to implement

Takeaways:

Heaps

• I like the language and tools; everything seems to just work. Concerns are:
  • Control over JavaScript output. I don’t think there are any PWA features, code splitting, or other advanced web app features.
  • Resources are embedded directly into JavaScript code (giant base64 strings). It seems the community has figured out a dynamic load option, but a lack of first-party support is a concern.
  • Learning the Haxe language would be fun, but less transferrable than TypeScript with the other options.
• A bonus would be that I could target other platforms than the web. But this project doesn’t benefit from that.

Phaser

• I am most comfortable with it from prior usages and TypeScript/JavaScript familiarity.
• It contains everything I’d ever need for a 2D web game project.
• Typescript can be used directly, as well as any web APIs.

PixiJS

• It’s only rendering, so other libraries are required to build a game with it.
• Phaser uses it under the hood, so you might as well use Phaser.

MelonJS

• It’s very opinionated (not a bad thing), but for the sake of speed on this project, there might be too much structure to learn.
• Larger teams and projects will enjoy the structure it provides.

Conclusion

After a week away, I reviewed the codebases and decided to proceed with Phaser. It has a very active community and a complete set of features. I’m now setting up a repository with TypeScript, unit testing with coverage, and CI/CD.

In this two-part series, I reviewed twelve game engines and wrote test projects for four of them. While my criteria excluded some of the most popular engines on the market, there are great choices for web game engines available. Most are open-source and actively maintained.