I've had a busy few days contemplating and evaluating each of the engines/libraries that I previously listed, and thought it would be good to follow up on what I liked or didn't like about each of them.

So let's get straight into it....

 

Three.js

As I said last time I have a lot of experience with Three.js - enough to know what it can and can't do without the need to spend any time on it.

As much as I love it and know I will use it again in the future, it is definitely a better solution for 3D work than 2D (I have done both with it before rendering building interiors from both 3D models or from 2d floor plan images).

However since it is not dedicated to game creation there is a lot I would have to program myself that other systems already handle, and since I am planning a 2D game here this was a pretty easy one to knock off my list.

 

PixiJS

I didn't even really evaluate Pixi. I figured that since Phaser is based on this, I would just go straight to checking out Phaser, and would only go back to Pixi to compare if I felt there was something lacking in Phaser.

Pixi also suffers slightly from one of my negative feelings towards Three.js for this project - it is not built specifically for game development, it is made for creation of dynamic content which just happens to include games.

 

Phaser

Tutorials can tell you a lot about software like this. If the tutorial is in any way long-winded, confusing, lazily written, or feels like you are missing something because you don't already know how to use it, more often than not that will reflect in the software and its documentation.

But Phaser absolutely does not suffer from any of those problems. The tutorial actually feels too easy, like you are missing something. But my opinion so far is that this reflects the powerful simplicity of Phaser.

In less than 2 hours I had a basic platformer up and running, starting with nothing more than the asset pack I downloaded from their site (the asset pack includes code for every step of the tutorial, but I purposely ignored the later stage files and instead only used the boilerplate and built up to the later steps myself).

Most important is that I am confident enough in what I learned to adapt it to any of my potential concepts.

It really is quite simple to use, and since it is code and not a graphical builder you can implement as much complexity as you need in a way that is more familiar to a programmer like me.

Working with sprites and animations is also amazingly simple, and their handling of objects in groups with shared behaviours is really nice.

 

melonJS

There was a lot to like about melonJS - I love just how integrated it is with Tiled, allowing you to build your maps and add your sprites, collisions etc. in Tiled and have them natively imported into your game without any additional work. I like their in-game debugger, found just by adding #debug to the URI which then lets you enable/disable certain options while seeing memory usage stats etc. But their platformer tutorial is seriously frustrating!

Some of it is obviously just outdated information, like screenshots and information about Tiled that have long since become obsolete - these things you can forgive because the datedness is caused by an external project.

But when the asset pack for the tutorial contains images that break recent versions of the library, and when the tutorial tells you NOT to set a variable when the only way I could get the tutorial to work was by explicitly setting the variable, then you have to worry about how much other obsolete, irrelevant, or incorrect information there is, both in the tutorial and in the main docs.

Also being a web-based project, not having all your dependencies listed in your package.json ready for an `npm install`, and just expecting everyone to know what Grunt is and what to do with it is kind of annoying!

 

Pygame

As much as I love Python, the quality of the games I have seen on Pygame is pretty low (many of the projects listed on their website don't even exist anymore), plus the inability to target mobile in any way is a bit of a letdown.

I may be wrong here and may cop some negativity from this, but I get the impression making a game with Pygame is more about "look I made a game with Python" than about making a high quality game.

 

Clickteam Fusion 2.5

I worked my way through one and a half tutorials, which basically gave me two different functional versions of the same game. The tutorials are easy enough to follow, but kind of long and boring. I even have a playable game out of it, and I feel like the knowledge I gained would have enabled me to step out of the tutorial and begin work on a game with not too much friction.

But trying to use this on Mac feels wrong. So, so, so wrong.

It is Windows software packaged up with Wine, so there are some oddities. Normal key combos don't work. To cut/copy/paste/etc. you can't use Command+X/C/V. You have to use Ctrl+X/C/V which is incredibly annoying.

Add to that there is a lot of awkwardness to the UI/UX that wouldn't even feel fine if I was on Windows. Having a list of options in a window where the changing the third option resets the first option is just bad UX design. Many workflows also feel more complex than they need to be.

Overall Clickteam Fusion 2.5 just feels dated, and there are much more modern, intuitive, and easy to use solutions out there.

 

GDevelop

I tried GDevelop directly after Clickteam Fusion, went through their platformer tutorial, and had a working product within a few hours.

It has similarities to ClickTeam Fusion, but where Fusion is awkward and clunky, this is streamlined and mostly quite intuitive.

While they have the graphical event system similar to Fusion they do not abstract away all the coding completely. It feels more like an interface between you, the code, and the variables than something that removes you completely from the code. 

After the tutorial I spent a further 6 or so hours building my own little platformer level which had some relatively complex (for the hours spent) animation and control handling, some basic enemy AI, and a 4-layer parallax background.

But GDevelop definitely does have some flaws.

You can't work directly with sprite or tileset images - you have to create animations from individual images on the object. At least they bundle a sprite editor called Piskel that helps you cut tileset images, but there is still a bit of friction there.

There are some little things about the interface that also bug me, like no grouping of objects in the list (you have tags which are for searching, but no way to group them visually to minimize the screen space they take).

You also can't work with maps or tilesets made in Tiled (although this is in the works and may be released soon).

 

Godot

Godot definitely feels polished. It really is trying hard to compare with Unity and the other big engines, and the devs are doing a pretty good job too.

I followed one of their tutorials to build a simple game, but honestly I felt like I didn't learn much from it. I did learn, but it felt like what I had learnt wasn't even scratching the surface.

I doubt I could have stepped out of that tutorial and immediately started working on a different style of game without some serious time spent learning more.

 

 

So, after all that I am now down to a very short list of just two - Phaser or GDevelop.

They are both very different solutions, with Phaser being "just" a library, while GDevelop is more of an interface with which to build games.

My next step will be to rebuild my platform level from GDevelop in Phaser as a direct comparison that is independent of any tutorials, and look into how Phaser handles Tiled maps and tilesets.

Meanwhile I am also working on a few different game concepts that I will be writing something about here some day soon. But real life will have to take over for a bit too, since I have about 7 weeks to find a new apartment!