This is a guide for programmers and for beginners. Which engine should I choose? Here is my experience with all of them when trying to recreate a familiar retro game that we all know.
If you want to start game development it’s not always easy to decide which engine fits best your needs.
That’s a process that has taken me almost 4 years of basic experience with engines like Melon JS, Unity, LÖVE, Game Maker Studio and now Godot. I can say I have touched all of them for a while, not very deep, but deep enough to realize which one was the best fit for me and the kind of games I want to do: 2D, sprite-based, grid-based movement (like a classic RPG).
What's the best engine? nothing in the internet will provide you the right answer: it depends on the kind of game you want to make, your experience as a programmer and what engine you feel more comfortable with.
In this article, I am always talking from my experience and probably many of the mentioned engines here may fit better for your games than others, but it doesn’t necessarily have to match my preferences. This article comes from a game dev beginner's perspective who is also a full-time Senior Software Engineer with more than 10 years of experience.
Said that, let’s begin talking about the game I was trying to develop and about the pros/cons I have found in every engine I tried to develop it with.
My project
I always loved Pokémon since I was a child. In fact, my nickname is based on the franchise.
I wanted to start game development making something that I already know well and that I’d love making: that’s right, I wanted to remake a Pokémon game, in my case Gameboy Color’s classic Gold and Silver.
New Bark engine in Unity 2020
I started in 2D to avoid having to learn all about 3D which seems more complex to me than using sprites in 2 dimensions. When I master 2D I might consider learning 3D later.
My idea is to create an engine that I can reuse later on to make my own monster-collecting games (not tied to Pokémon).
The first thing was obviously to choose the game engine. It was not an easy task (even less a few years ago): it involved a lot of googling things like “what’s the best engine for 2D game development”.
Initial project scope
My initial scope of the game was always simple: instead of thinking about all the aspects of the game I wanted to introduce or all that I need to do and frustrate myself, I always tried to create and fully cover in detail the first town of the game in every engine. That would cover these aspects:
- The tile-based map, including indoors (houses).
- The player animation and grid-based movement + running
- Collisions with tiles and other objects.
- Interacting with objects: dialog boxes, printing text char by char and auto-advancing to the next line.
- Teleport to another part of the scene with a fade-in/out transition: going inside and outside houses.
- Basic game save/loading (player position)
- Changing the background music depending on the area the player is in.
- Sound effects (interacting with dialogs, collisions)
Example in Unity (frame-rate looks jumpy because of the GIF)
The tested engines
MelonJS (5.0)
MelonJS is a good engine to play with if you have a Web / JavaScript developer background. It provides you the basic blocks to build very simple games but it’s not aimed for making big complex games.
PROS
- Familiar languages. Quick to start with if you come from a Web / JavaScript developer background.
- Compatible with browsers. You can run your game in the browsers or package it inside an Electron app for desktop.
- Ok for simple games like Flappy Bird
- Open source and free, community maintained.
CONS
- It doesn’t have a dedicated IDE to work visually with the engine.
- You have to write almost everything from scratch since the engine provides the very basic building blocks.
- Not recommended for complex professional games.
LÖVE (11.0)
With LÖVE I had a similar feeling as with MelonJS. There are not many differences apart from the language (Lua) and the way it packages and executes the games: In Android you have to install a separate app in order to execute LÖVE games. That’s something I didn’t like.
Maybe LÖVE has a more mature API than MelonJS that lets you build a bit more complex games, but still: no IDE, a lot of code required for getting started with a simple game.
So it has basically similar PROS/CONS to MelonJS.
Unity (v2017–v2020)
I tried to use Unity before any other, but the complexity of the IDE scared me a bit in the beginning and I opted for more simple engines.
I came back to Unity after discovering that I was not going to go any further with the previously mentioned engines. So I gave it another try starting from the 2017 version until v2020.
My first impression after learning the basic concepts of game development with the other engines was: wow, this feels very powerful and I have a good language like C#.
Starting a 2D game of my characteristics in Unity is not an easy task. Back then in 2017, there were no 2D pixel-perfect tools or tilemap editor, so everything looked a bit glitchy.
I had to watch lots of tutorials for a year in order to have the first town of the game working with dialogs and grid-based movement but nothing more.
I needed code for almost anything, I had to write my own physics engine because the built-in one is not so flexible, so I could not use it for grid-based movement and collisions because I always had problems (e.g. bounciness, stuck pixels, etc.).
PROS
- Industry-standard for many kinds of games (mostly mobile and PC / console casual games). If you master this engine you probably can apply for a job in lots of game dev companies.
- Robust OOP Language which is used in many other areas not only game development: C#
- The engine evolves very quickly. The jump from 2018 to 2020 was huge. Lots of things have changed.
- Future looks promising for 2D game development, but still uncertain.
- You can use the engine for free, even commercially up to a certain amount of sales. That’s great for learning the engine.
CONS
- Still feels incomplete for 2D development after all these years. I feel that 2D features are not a priority for Unity, they still seem more focused on 3D: 3D games, CAD (for automotive, construction etc) and VR/AR right now. It’s not clear nor transparent the direction they are taking for 2D game development.
- Learning curve is high, even more for 2D game development, since Unity was initially intended only for 3D. This has improved a lot in the last years but there are still many lacks that are covered in other engines very well.
- Lack of information and tutorials for classic 2D games without modern physics. This has been a major handicap and time-consuming for my case. Something so basic like transitioning from one room/scene to another with a transition, there are not good examples for that.
- The Animator frame function callbacks are not reliable like in other engines.
- Convoluted event system. They are complex to set up and you don’t have a way to have a clear overview of what happens when.
- The built-in components are very generic, they allow you to make any game you want but at the cost of also having to write a lot of code. The package system has been a good addition though.
- Migrating your game to a new version may break it. The amount of changes introduced from 2018 to 2020 is huge (and they are still in progress like the DOTS engine). It makes you think if it’s a good moment to learn this engine or wait.
- Many 2D-related bugs that you don’t really know if they will ever fix them.
- Not having a dedicated language for game development makes the usage of C# very convoluted in many cases like the mentioned game event handling.
… and I probably found more obstacles that made me give up with Unity… after trying GameMaker Studio 2.
GameMaker Studio 2.2
I won’t extend so much with this engine because I only have used it for less than 6 months, but here are my impressions:
PROS
- The engine, at first sight, seems a good choice for 2D game development. Many basic aspects of 2D development are covered here while they are lacking in other engines like Unity. Lots of aspects seem very convenient.
- Learning curve is low: I wrote the same basic town in 1 month instead of 1 year that took me doing the same in Unity.
- Good for quickly prototyping games and for learning the basics concepts of game development.
- You can make your games without writing a single line of code: using Drag-and-Drop components. That’s good for non-developers to write casual games.
- If there is any error in your whole code or some reference missing, the editor complains before running your game. That’s good in case you changed script names or refactored code.
- Undertale and Swords of Ditto were made with this engine, so it’s possible to create full complex games that can be commercialized if you don’t care about the cons.
CONS
- If you are not a developer, the engine teaches you bad practices that you will probably drag for years in your developer career. So, if you never worked with an object-oriented programming language I recommend you to avoid starting with GameMaker but start simple with an engine that has OOP like LÖVE (it uses Lua) or even MelonJS (now that Javascript supports proper classes). Later on you can try GameMaker if you want, then you will be able to notice the difference.
- GML has no OOP (Object-Oriented-Programming). Every data structure has to be in integer-indexed arrays. Managing your variables using enums and arrays is a no-go for big projects. Although OOP will be partially introduced in v2.3 and will feel similar to Javascript objects and functions, it still needs a long way to go to be mature.
- Porting code from Unity / C# to GML was not easy due to the huge differences in the way GameMaker is doing things.
- Some built-in components are opinionated (not flexible enough), meaning that they will somehow dictate how your game has to work.
- There is no built-in 2D lighting system. You have to write it from scratch or use assets from the marketplace or the community. That might be ok if you don’t need this feature for your game or you make your shadows/lights with translucent layers.
- As soon as your project gets big it becomes unmaintainable: lots of windows here and there, lots of scripts, lots of data structures as arrays and enums
- Hard to refactor code: you have to do it everywhere manually, the IDE doesn’t detect the usages of your scripts, variables, etc. that you are renaming.
- It has a trial, but after that you have to pay for a license. Not nice if you just want to learn this engine before deciding to use it commercially.
- You need to log in with your account in the IDE in order to use it, so you cannot use it offline. If your network is slow, the IDE can take a lot of time to start.
Then I started following HeartBeast tutorials and videos on YouTube and decided to give Godot Engine a try.
Godot Engine 3.2
I have heard about Godot years ago but I thought it was like another indie game development engine and I was afraid that It wasn’t going to be enough for what I wanted to achieve.
Well… I am discovering that I was wrong.
In May 2020 I started watching HeartBeast’s Godot tutorials on YouTube and, after trying all the other engines I have to say it has been very easy to learn, also because HeartBeast is a very good teacher.
Let’s say that Godot has the good stuff that I found in GameMaker and Unity combined together, plus it has a dedicated OOP gaming language that it may not be as powerful as C# but it does what it should do and it’s improving very fast.
My first impression of this engine is: wow, they got things right like I expected them to work, everything is so intuitive and works so conveniently together.
In less than one month I achieved half of what I did in GameMaker, but the quality of my code and the scenes feels much much better.
It also takes me more time because I am writing the game in a modularised component-based way: similar concept as React JS where each component can be reusable and can potentially work on its own. That combined with signals/events is very powerful.
So here is my (preliminary) opinion on Godot:
PROS
- Free and open source. Community driven. You clearly see the direction this project is taking, you can tell by the Github Issues/PRs/Milestones. So there are no surprises.
- Multi-platform without the need for extra licenses: Desktop, Browser or Mobile.
- Transparent founding system. With all the donations they hire people to take the engine to the next level. That’s something I like and the support of the community is impressive.
- Intuitive IDE. If you tried Unity and GameMaker, you will love Godot. In the beginning, you will be a bit lost to know what’s everything, but with some tutorials, you get it quickly.
- Faster than the competitors. Running my simple town is much much faster than with Unity or GameMaker.
- It also has live code editing like Unity.
- Huge set of reusable components, which are highly flexible and customizable compared to the other engines. This saves you lots and lots of code.
- I didn’t try animations much deeper than just sprites, but they seem more powerful than in Unity or GameMaker. Function callbacks in the Animation timeline are reliable and called when expected if you don’t have important frame drops.
- A great and friendly community with tutorials that still work even after minor version updates. I have found some outdated tutorials, but not so many compared to the other engines and the things I had to change to make them work were not hard to find.
- I love the node/scene system and concept. You can build perfectly decoupled and reusable scenes, helping you write better games more than with any other game engine. You can build much cleaner games by having each level (composited by multiple scenes) working as a standalone mini-game. That’s perfect for testing and learning how coupled are the different parts of your game.
- Another thing that I really love, that in other engines is more convoluted: The signals system (events). They are so visually intuitive that you feel encouraged to use them from day 1. That also helps writing better & decoupled code.
- It has a dedicated OOP language, written specifically for game development: GDScript. Although the engine also supports VisualScript (like GM Drag and Drop), NativeScript (for more low-level code) and C# !! Even If I like C# a lot, I stay with GDScript because it feels much easier and convenient for the engine, plus it seems to get new features before C#.
- Documentation of the Godot engine API is just great, extensive and well explained. You don’t have to leave the IDE to check the docs or wait for a webpage to load inside a frame.
- Shaders are very easy to integrate and learn to write in this engine. It has a visual diagram tool to build them if you don’t want to write their code.
CONS
- I wish I knew this engine before. Unity and GameMaker are better known because the most part is the hype and marketing behind them. Godot community doesn’t invest much in that, but rather focuses on the quality of the engine and spends the most part of the budget on that. I little more promotion and marketing for Godot is needed I would say.
- GDScript feels great but it there is some stuff that I would like to see improved (and actually it is being in the works): Ability to export any data structure in the inspector, variable groups and hints in the inspector, type hinting for any class.
- The IDE has serious performance issues when playing animated textures in the 2D view. It’s being investigated but I have to hide the layer so my laptop doesn’t burn.
- The TileSet editor seems very powerful but it has UX/usability problems, same for the 2D view TileMap editor. Various proposals are being considered.
- There is no built-in sprite editor but that’s ok for me since I can also work with Aseprite. Using Aseprite and GameMaker sprite editor at the same time was tedious because of the different keyboard shortcuts.
- The engine it’s not compatible with any console and it probably won’t because it’s open-source, so it is meant for developers that intend to release their games for Desktop, Browser or Mobile only. By the time your game becomes popular, probably you will have enough budget to hire people to port it to consoles using another engine.
Conclusion
I know, this is a long post to read, but thank you for taking your time.
I wanted to provide you all what I experienced using these engines (or a summary of what I can remember) so with all that information you will have a better understanding of what can you expect and the struggles you will find if you want to do similar 2D games as I do.
Of course, choosing the best game engine that suits your needs it’s always up to you.
In my opinion the clear winner here is Godot, at least for now. It seems to have everything I need, It has a quick learning curve, good tutorials, encourages good practices, … and more that I have to discover.
I will keep posting Godot tips and tutorials here as well as some of the progress of my games, mostly the parts that I think you might find interesting or that were the most challenging for me.
I end this article with this thought: if you have a game idea, don’t try to do everything the first day because you’ll get frustrated. Set yourself small scopes and goals for your game. Keep trying, do little by little every day or weekend, at your own pace and the most important thing: Never give up!
