Game Engines [ARCHIVE]

PLEASE NOTE: this is an archive from my original blog. It was my only post.

Before we begin: A game engine is a tool which is used to create games. It
usually has a user interface and a scripting language (a specialized programming
language unique to the engine) of some sort.
A game _framework_ is a library of code which can be added to your code so it's
easier to make a game. These generally require substantially more knowledge and
coding skill.

So, as many of you know, I like to make games. A lot. I’ve published four games (as of writing) and have created several more. However, my choice of game engine hasn’t always been consistent. The first engine I tried to use was, as is many people’s first choice, Unity. My time with this engine was short, and I had a great deal of trouble trying to grock how it works.

My Issues With Unity

Unity is a great engine… for some people. It’s very powerful, and it’s become the industry standard for games, if there is one. It’s been used for many well-known and well-regarded games. Including one of my favourites, Hollow Knight. However, Unity is signifcantly better optimized for 3D games than 2D games because when Unity was first released in 2005, many people were still writing their own game engines. However, this meant that if you were an indie developer without a major studio, you were more likely to make a 2D game than a 3D one because it’s much easier to create a 2D engine. Unity picked up steam by focussing on 3D. Because Unity based itself on filling a gap in the market, it gained a large amount of success and is now responsible for around 45% of games being released[1]

However, despite all of these remarkable achievements, Unity never clicked for me. I had a few major issues that come to mind, with my first one being how Unity is designed for 3D games, not 2D. That’s not to say it can’t do 2D, it does it perfectly well (See Hollow Knight or Thomas Was Alone,) but its implementation of 2D… leaves a lot to be desired. How Unity Engine implemented 2D was it took its 3D engine and locked the camera into a fixed perspective. There we go boss, 2D engine is done! Now, this sounds like a perfectly fine implementation on paper. It even has some benefits! For example, you can import a 3D model and it’ll fit with everything else just fine! However, in practice, this makes it difficult to create 2D games for a variety of reasons. The main ones I ran into were having to use 3D physics and the lack of a distinct type of measurement unit. These, combined with many other issues, such as the need to import many different packages to achieve some extremely basic functionality (If you want text to look nice, add a package called TextMeshPro.)

But the thing that prevented me from really using this engine was the choice of scripting language- C#. Now, C# isn’t a difficult language- if you have experience coding. But 12 year old me in 2018 was not an experienced coder. He was fresh out of Scratch and taking a Codecademy Python course. All of this proved to be a little much but in the end I did learn some basics of Game Engine functionality. But all of this kept me off Unity no matter how many times I tried to come back over the next year.

Then, in March 2020, the world went into lockdown.

With nothing better to do, I browsed Reddit. Then, one day, on r/gamedev I saw a post that Clickteam Fusion: standard edition (an engine I had been eyeing for a while but had never gotten due to the over $100 price tag) had a free 3-month trial so people had something to do during the pandemic.

Fusion 2.5 Isn’t Jazz, Disappointingly

Clickteam Fusion 2.5 is a remarkably powerful engine. It is also an extremely easy to use engine. On top of all this, it is an extremely frustrating engine. Knowing the first two, I excitedly downloaded it in near the end of March, and started creating my first game with it. This is where I discovered the Engine’s strengths and weaknesses. On the one hand, all you need to do to create game logic is to create a new row in its spreadsheet-style event editor, set up what triggers that row, and then set up what happens when that row is triggered. And you can do all of this with just your mouse. Not a single line of code needs to be written. And this works great… for extremely simple games. Because the minute you want to start adding enemy AI, or even multiple enemies for the plyer to collide with, you need to duplicate many rows of events, and change one thing each time. Now do this for everything in every level and it starts to get tiring. The biggest game I made with the engine was a birthday gift for my mom. A small 2D platformer where you need to collect the letters of “HAPPY BIRTHDAY” while exploring a small map. While doing this, I discoveredone of the most annoying things about fusion- no tilemaps. A tilemap is essentially a little sheet of tiles which can be selected and placed in a level. From this tilemap you can select any tile, and place it. Every tile is stored in the one object, and this keeps things clean and easy to manage. Clickteam Fusion 2.5 does not have these. So when I started creating a large level, I had to create a new object for each unique type of tile. So this got messy, and it got messy FAST. The game turned out simple and cute and fun. It is with this engine that I entered my first game jam and published my first game, Pack the Pack for the LebGameDev Quarantine Jam. From this I started to work on my next game. One which I never finished because around this time I watched some videos by Miziziziziziziziziziz or however the fuck many “iz"s he has in his name. And his engine of choice was a little open source project called Godot.

Waiting For Godot

As my time with the free version of Fusion grew shorter, its outdated interface, high costs, and complications all began to make themselves more and more present. Because of this, I began to look for other engines. Thinking on what engine I could use that wasn’t Fusion or Unity, I thought of what free engines I’d heard of, and remembered Godot. I looked into it, downloaded it, and looked at some of the built-in demo projects. After thoroughly misunderstanding the interface, I found a short 15-minute tutorial by Heartbeast which let me make a simple 2D platformer in about 20 lines of code. This taught me the basics of Godot’s node system which, while hard to understand at first, makes creating complex objects really simple due to the engine prioritizing the Object Oriented model of Composition over Inheritance. Godot has a scripting language called GDScript, a pythonic scripting language designed specifically for the engine. Everything I’ve looked for in a game engine appears here in Godot, and it does it all well. I’ve released 3 games with it so far, and development with the engine is just fast, easy, and streamlined. None of these things done to make development easier come at the price of efficiency or safety, though. Godot has a dedicated 2D engine which uses pixels as its units of measurement. This makes it so that there are less issues with physics types and creating 2D games efficiently. This is great for me, who definitively prefers 2D games and creating 2D games to 3D ones.

Godot is also a comparatively new engine, so it hasn’t had any hits releaseed with it just yet. It does. however, have a strong community and many people working on making the engine better. It has many small features that make it a pleasure to work with, and it makes several of the more frustrating bits of game development, such as input, a breeze. For these reasons and more, I have been working with Godot as my engine of choice for over a year and plan to continue using it for the forseeable future. Godot doesn’t make everything extremely easy, though. For example, while it isn’t difficult to do drawing with code in Godot, the engine is definitely better optimized for using sprites. So, when looking at other engines, I found a little Lua-based project called LÖVE2D.

All You Need Is LÖVE

LÖVE is an open source game engine with no GUI, working exclusively through Lua scripts. LÖVE makes many of the things that are difficult in Godot extremely easy. I wrote my first program (without a tutorial) in LÖVE in 60 lines of code, which functioned perfectly on the first try. And it was all readable. LÖVE’s strenghts are in its simplicity and its efficiency. However, it also complicates many of the integral parts of game development, such as scaling and input, which Godot simplifies. So, as of writing I have settled on a system where when I create games I use Godot, and when I just make live graphics projects I use LÖVE. I find this to be effective for me because it allows me to use the strengths of each engine, while largely avoiding the weaknesses.