A few weeks ago, I posted about my experience attempting to make a prototype in a bunch of different 2D game engines/frameworks to learn what makes them tick.

If you're shopping around for an engine for your next 2D game, this article will provide some things to consider that may help in your discernment process.

Do note that I'm not attempting to cover every 2D game engine out there; nor am I positioning one engine or framework over another. These recommendations are from my personal experience using different engines and frameworks for prototyping.

And if you'd prefer to watch rather than read, I've created a video version of this post (26 minute watch):

React

At first glance, you might be thinking, "React is a front end framework for making interactive websites. It's not a game engine!" And you'd be mostly correct.

React doesn't provide native support for game development basics, like, for example, 2D physics, but it does handle state extremely well. If you're already a JavaScript developer and willing to pair React with something like boardgame.io to make a simple 2D game, you could potentially get a prototype up and running pretty quickly.

For all other types of 2D games, you'll want to look elsewhere.

Unity

Unity has made itself ubiquitous in the 2D and 3D game development spaces. I'd position it as an excellent 3D game engine, and a serviceable 2D one.

The Unity editor is fairly complex, with a lot of nested menus that take some time to wrap your head around (check out this article for a tour of its 2D features). If you don't already have a background in C#, which Unity uses for scripting, you'll want to brush up on it prior to learning Unity, as doing so will ease your overall learning curve.

Unity also does a lot of things the "hard way" when it comes to 2D game development, which doesn't feel native compared to other game engines. Creating a 2D game world in Unity, for example, feels like you're shoehorning a 2D plane into a large 3D space, and things like animation and pixel perfection are more clunky than in other 2D-specific engines.

You can make any type of 2D game with Unity if you're willing to wrestle with the editor and underlying 3D idiosyncrasies. It has extensive community support, and you'll find that working with C# is a delight. Additionally, Unity's Asset Store has all kinds of art and templates for you to download and purchase, but buyer beware: you might spend as much time rewriting someone else's code to fit your project as you would just starting from scratch.

Unity is, in general, free to use, but pricing becomes more complex if you want to use everything it has to offer (see this page for more details).

Godot

Godot is a free and open source 2D and 3D game engine that supports GDScript, C#, and even C++ and Python if you're willing to do a lot of the heavy lifting to make them work. It supports a node-style workflow and is super lightweight.

If you're a) willing to invest in learning GDScript or b) already super good at C#, C++, or Python, you'll probably be fine in Godot, particularly if you like working with open source software. If not, you may get easily frustrated, as there isn't nearly as much support for C# or other languages as there is for GDScript. Still, Godot is a pleasant engine with which to work, and although it may not have the same pedigree and community support as something like Unity, if you're a self-starter you might feel well at home.

Construct 3

If you just want to make 2D games and don't care about programming language or subscription fees, you'll find Construct 3 to have everything you need to get a demo up and running, and quickly. All of your work will be done in a browser, using drag-and-drop tools (and custom JavaScript support if you need it).

Don't expect to have a meaningfully productive experience with Construct 3 for free, however. There's a simple demo that you can try out, but impactful game development with Construct 3 is locked behind a paywall, and a subscription at that.

Game Maker Studio 2

Game Maker Studio 2 has a user-friendly editor that supports a proprietary language called, appropriately, Game Maker Language (GML), along with visual scripting. It also has a lot of tutorials, great community support, and an asset store (which comes with the same caveats as Unity's, above).

The general workflow of Game Maker Studio 2 and doing things like animating sprites, setting up your game world, and so on, are straightforward and intuitive. GML might not be your cup of tea if you're coming from another, more widely-used programming language, and I would not recommend it as your first introduction to learning how to code. It employs some of the basic concepts of programming, but not important details such as coding best practices or how to write clean code.

Additionally, you can try Game Maker Studio 2 with a free 30-day trial, but will need to pay to continue to use it after that time.

Phaser 3

If you want to code everything and learn a lot about the JavaScript ecosystem while doing it, check out Phaser 3 (or wait for Phaser 4, which is on the way).

Phaser is a lightweight and powerful JavaScript framework for making 2D games. Whereas Phaser 2 was extremely well-documented and had excellent community support, Phaser 3 is quite the opposite. There's good official documentation and a bunch of examples (without much context around them, it must be said), and a dreadfully small amount of tutorials.

Expect to build everything yourself, but if you're looking for ES6 or TypeScript support, or if you really want to polish your skills as a JavaScript developer, you'll be able to go a long way with Phaser 3.

In the interest of fairness, I should mention a two other 2D game engines that have been recommended to me since I started writing on the topic: LÖVE 2D, which uses Lua, and MonoGame, which supports C#. I haven't used either of them (or others, such as PyGame), and can't speak to their usefulness, but they may be worth checking out.

Let me know which 2D game engine you wind up using, and why!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

I'm a tabletop game developer. In designing a new card game, I decided to build a digital prototype to help me run simulations and easily share a proof of concept with collaborators.

I have some background in JavaScript and C#, and I set out as many do: by spending an inordinate amount of time in "what framework should I use" threads and reading documentation without actually making anything.

Flash forward many months, and I've now spent more time working in (and wrestling with) React, Unity, Godot, Construct 3, Game Maker Studio 2, and Phaser 3, in an attempt to understand what makes them tick.

Admittedly, I think I've spent way more time in each of them than necessary to make my little game, and I probably could have just stuck with the first one and blundered my way through the prototype. I'm hoping the below info will be helpful for anyone else who is shopping around for an engine or framework.

Bunch of caveats: I'm not attempting to sell one engine or framework over the others, and I'm also not suggesting that one or any of these frameworks will work for your game better than another. I'm also not comparing pricing, back end functionality, or platform deployment. So depending on your requirements, the below information might be of differing value to you.

Additionally, this experience is based on development for a 2D card game, so I won't be discussing 3D engines, physics, etc.

You can also skip to the bottom for the TL;DR.

The Prototype

My game, Entromancy: Hacker Battles, is a competitive cyberpunk card game with TCG-light mechanics. You can read more on our website or watch how it's meant to be played in this video. But suffice it to say that, as a card game, it requires a potential digital framework to support basic things like state management, UI, drag-and-drop UX, and back end hooks for implementing multiplayer.

Given these requirements, I explored the following frameworks and engines to see which one would be most suitable for making my game...instead of actually making the game (I'm happy to say that now that I've settled on a framework, I'm making a lot more progress).

You can access a playable version here, and although the game is further along than the live prototype would suggest, this version is pretty stable (in Chrome at least).

React

Having already built a character generator prototype in React for a tabletop RPG I designed, I thought a natural step would be to give the framework a spin for the card game. I found state management to be a breeze (it's what React does, after all), whereas implementing simple drag-and-drop functionality for cards proved to be a nightmare.

There are some libraries out there that can help with basic drag-and-drop (e.g. React DnD), but I found that with a card game, I needed a more elegant solution for dropzones, as Hacker Battles is very specific about which cards can be played where, and when.

This experience led me to check out boardgame.io, which can work in tandem with React. But this ultimately required me to learn another framework on top of an existing framework, which was less than ideal for my purposes.

Unity

Out of general interest, I had spent a lot of time in Unity doing tutorials and learning how to use the editor before attempting to remake the card game prototype with it. The asset store is a great resource, and there's so much documentation, official and unofficial, out there that I was confident I could find an answer to any issue I might encounter.

My experience with Unity thus far has been a mixed bag. I really enjoy working in C#, and anything code-related has been a relatively pain-free experience. However, Unity is very specific about its implementation and can feel counter-intuitive at times.

The editor, on the other hand, is a bear to work with. To harness Unity's full potential, you need to spend a good long while wrestling with the UI to understand where everything is and how to use it. It's also desperately behind the times with 2D game development, clearly attempting to flatten a primarily 3D engine into a 2D plane, with mixed results.

To be fair, I quite enjoy working in the Unity editor, clunky as it is. But if you're looking for a 2D game engine, your quality of life will be a lot higher elsewhere (watch a video on Unity's animation system or achieving pixel perfection and you'll see what I mean).

Ultimately, Unity's handling of the 2D space is a bit more complex than I need for my prototype, but I will return to it for other types of games.

Also, a sidebar that might be useful to some: I was initially extremely excited about the asset store, with the idea that I could purchase a card game template that would make the development process that much easier for me. It didn't work out. Most of them were MTG/Hearthstone/etc. clones that would require just as much development time on my part to restructure them for my card game as it would to just start from scratch.

Godot

My first thought upon encountering Godot was: "open source game engine that supports C#? Sign me up!" Then I downloaded it, worked through a couple of basic tutorials, and had it crash on build. Hurm.

Several Google searches, reinstalls, and hairs pulled later, I figured out it had something to do with my version of VS Build (I think?), which led me down a separate rabbit hole. I knew from experience that other engines - Unity chief among them - could cause game-breaking issues completely outside of your own code, but this was an annoying hurdle that likely colored the rest of my experience with Godot.

In terms of the editor, I quite liked Godot's node-based implementation, which I actually found counter-intuitive coming from Unity's prefabs, but eventually warmed to. I'd actually go as far as to say that its 2D functionality is better than Unity's, but it's missing the community, asset store (see sidebar above), and especially, the documentation that Unity has. If you're intending in working in C# with Godot, for example, be prepared to look for answers in the engine's custom GDScript and then translating them to C#.

I have heard, however, of people experiencing great success with Godot while using GDScript, so if you're willing to invest the time to learn it you might enjoy what Godot has to offer.

Construct 3

In the caveats that I listed above, I mentioned that I'm not including pricing as a point of discussion. Still, I feel like I need to bring it up with Construct 3, as it turned out to be impactful in my experience.

Unlike the other game engines listed here, which are, for the most part, free to use (Game Maker Studio 2 has a 30-day free trial), the vast majority of Construct's functionality is behind a pay wall, and a subscription fee at that. Ugh.

I really, really like the cut of Construct's jib for simple 2D games. The editor feels a bit like an upgrade from MS Paint, but it handles sprite and object management really well, and is just plain easy to use. I don't love that it uses a "visual scripting" style, but they've recently added the feature of writing plain old JavaScript and it seems to more or less work.

I was able to spin up a very rudimentary architecture for the prototype in a brief amount of time before closing the Construct 3 demo (which runs in a browser)...and then trying it all again later with a new demo. I feel like, at least for this card game, I could do a lot with Construct 3, but I'm just not willing to pay $99/year (or more, as a business) for a prototype.

Game Maker Studio 2

YoYo Games has clearly done a lot of work to make Game Maker Studio 2 accessible and easily navigable, and it shows. Of all of the engines that I've used for this project, I like the GMS editor the most. For a small project, it's easy to find your way around and go about your business. I suspect, however, that a larger project might get out of hand pretty quickly.

This might be influenced by Game Maker Studio's proprietary language, GML (although GMS 2 supports visual scripting, which I did not use). It works, but if you're coming to it from another OOP language (or, truly, any other widely used language), you might scratch your head at the implementation or figuring out how to do some things. If you're a beginner or willing to spend time figuring out how GMS wants you to use GML, you'll probably be fine.

I experienced some quirkiness with Game Maker Studio's drag-and-drop functionality - namely, mouse pointer detection upon dragging is a little wonky and requires some scaffolding to make work correctly.

I think - and this is totally personal preference and laziness on my part - that if GMS offered the ability to use another, non-proprietary programming language, I would spend the time to do more damage here. I'm all for leveling up multiple skills while working, whereas spending the time to become an expert in the GMS editor and GML without being able to easily apply that knowledge elsewhere doesn't seem worthwhile.

Still, it's a pretty workable 2D editor, and although the community support may not be on par with Unity's, it's still pretty good. Beware, also, that once your free trial is up, you'll have to pay to continue using Game Maker Studio 2.

Phaser 3

Phaser is a lightweight, open-source JavaScript game framework. There are some Phaser IDEs around, but if you're of the sort that wants to work primarily in code, you might wind up here, using Atom, Sublime, or your favorite editor.

Phaser 2 was and is widely used and well-documented with a ton of tutorials to draw upon. Phaser 3 is the opposite. It has a comparatively high learning curve for beginners, with a bunch of examples and not a lot of context around them.

A lot of the tutorials out there support Phaser 2, and while the learning is transferable, the code is not. Additionally, the devs recently announced that they'll be moving support to Phaser 4 (and TypeScript rather than ES6), which is not great if you've spent time working in Phaser 3.

If you're not a professional programmer (I'm not) and up-to-speed with ES6 classes and JavaScript best practices (I wasn't), you might become quickly frustrated with Phaser's lack of handholding and having to set up your own IDE and work flow (I was).

However, I've found it to be a powerful, lightweight framework that does a lot of things in a much more streamlined fashion than other game engines. Drag-and-drop functionality for the card game has been a relative breeze, and the ability to separate card types into classes (sort of like Unity's prefabs) has compartmentalized some of the cognitive load that this kind of game requires.

If you're a front end developer, you might like or be comfortable with hard coding pixel coordinates for everything, but sheesh, is this painstaking work. Additionally, if you're not up-to-speed on everything JavaScript, you'll most likely be searching for answers in non-Phaser circles and then applying them to your project, which has its own benefit, I suppose.

One other note in case it's not clear: Phaser 3 does have quite a bit of official documentation and examples, but it doesn't have the community or Stack Overflow answers that a lot of other game engines enjoy. If you run into an issue or can't figure something out, you'll have to figure out your own solution or post your question on the Phaser Discord server, which has been helpful in my experience.

Conclusion

Given all of the above, the prototype I've stuck with and continue to iterate upon is the one I've built with Phaser 3. I realize that this may be anti-climactic, as Phaser isn't inherently "better" than the other frameworks and engines at 2D game development (except for, perhaps, React, which isn't trying to be a competitor in the digital game space).

Phaser does, however, seem to handle drag-and-drop and game loop management for Hacker Battles more smoothly, and for my purposes, that's important. I also enjoy that using Phaser is requiring me to invest more heavily in the JavaScript ecosystem(s) and communities, but I'm interested in doing that anyway so it feels like a bonus.

If you're more of the "what can I use to build something quickly and not care about the context in which the engine is situated" type, YMMV.

TL;DR

React: great for front end development. Wouldn't use it for games, particularly drag-and-drop.

Unity: you can make any type of 2D game if you're willing to wrestle with the editor and underlying 3D idiosyncrasies. Great community support, and C# is awesome. Asset store exists, but may not be useful for your purposes.

Godot: open source and supports GDScript, C#, even C++ and Python if you're willing to do a lot of the heavy lifting. Good 2D implications but not nearly as much community support as something like Unity. Also, my experience was buggy.

Construct 3: really easy to use, high barrier to entry because of the subscription paywall. Visual scripting may get on your nerves if you're looking to use or learn code, although there is now some JavaScript support.

Game Maker Studio 2: user-friendly editor with good community support. GML or visual scripting might not be your cup of tea if you're coming from another more popular programming language, but hey, when in Rome. Also, requires payment after a 30-day free trial.

Phaser 3: expect to code everything, and do a lot of searching to figure out how to make things work. It's working for me for this particular game and prototype, but Phaser 4 is on the way, so there's that.

I hope this post is useful in your own search and discernment process. I'd love to hear about your own experience(s), too, with any of these frameworks/engines or others!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

Hello FreeCodeCamp Reader Community! This Tutorial is made as a little thought experiment but might have some merit for the one or other person.

Please keep in mind that this plugin is making an example by adding a product via Construct 3 Forms + REST API cURL Request to an existing WordPress + WooCommerce installation.

The principles still are valid for other purposes you might have with the REST API, and I included the .c3p on the bottom of this tutorial. There are more elegant ways about feeding the arrays of information to the application, but this is a quick demo as proof-of-concept that I put together within 2 hours and felt like sharing it due to the lack of API and AJAX information for Construct 3.

Here is the entire code in a single screenshot:

Construct 3 Source Code Screenshot

The Code Broken Down once we click on 'Create Product' button

• productjson is an obligatory text field outside of the viewport on the layout.
• productjson contains our entire payload data pre-formatted as json to allow the REST API to work properly.
• The payload contains dynamically created content which are the forms in the layout such as product name, sku, price, etc.
• The AJAX module that I renamed AJAX_Data will set the Request_Header to "Content-Type" with the value of "application/json", because the REST API via cURL request will utilize JSON.
• The next AJAX_Data with the 'Post to URL' request will be our actual API request.
• The Tag is merely a name which can be utilized for example to return the values of the request, in the example of my project - as debugging information.
• The URL will start with your domain, i.e. 'https://www.example.com' The next part of the URL is the API request you would like to make, in our example as per WooCommerce documentation to add a product we need '/wp-json/wc/v3/products?'
• Last but not least for the URL we need the consumer key and secret in this manner: 'consumer_key=&consumer_secret='
• The full URL looks like this: "https://www.example.com/wp-json/wc/v3/products?consumer_key=&consumer_secret="
• Next up is the Data. This is simple since we already have made a text box for this exact purpose. Simply refer to it here, in my example the Data will be 'productjson.Text'.
• And at the very end, what type of Request. Since we are creating a product we will need 'POST', if we were to retrieve a product we would want a 'GET' request, see the respective documentation of the API you are using.

.c3p File Download:

https://drive.google.com/open?id=16DKq5RJD5tCw57oZPruGk_mtTIAe-Um9

Requirements for my .c3p example

• WordPress Installation with WooCommerce installed
• REST API enabled and issued a consumer secret & key
• Replace my API secret and key example in the code
• Uploaded an image in the media gallery within WordPress
• Created a Product Category within WordPress/WooCommerce

If you need a free WordPress environment to play around with, I used https://pantheon.io, under the free plan you can get 2 sandbox sites. Just make sure to install the WP-CORS plugin first and set allowed sites to '*' as seen in their documentation here:
https://pantheon.io/docs/platform-considerations/#cors

https://wordpress.org/plugins/wp-cors/

API Source Information & Relevant C3 Documentation:

WooCommerce REST API Documentation
Construct 3 AJAX Documentation
JSON Validator tool to verify if your JSON is properly formatted.
Original Tutorial I wrote on Construct.net