I would like to start off today by saying thank you to all the readers out there who had such a positive response to my first article in this series. It always makes the writing more rewarding to know that people out there are reading it and enjoying it; and I find that I learn just as much by writing and talking about design and programming and such as I do from doing it. Now that we have the mushy stuff out of the way, let’s get down to the business at hand for this week’s article: game engines. I said before that I would make a point of not assuming what my readers know or don’t know about game design and development, since probably everyone out there has a slightly (or drastically) different skill-set, so I will start off by talking about what a game engine is.

What is a game engine anyway?

The reality is that a game engine is just a bunch of pre-written code with an attached user interface to help you get your head around it. That does mean that, strictly speaking, they aren’t actually necessary. If you are comfortable enough with your programming skill level, you could just as easily find a game development API (if you don’t know what that is, this isn’t you!) for the language you prefer and write it all yourself. The upside to doing so is that you have complete control over what your engine can do, since you are building it custom for your piece of software. You aren’t limited by the capabilities of an engine someone else wrote. The downside is that you now have to write a huge chunk of code that you can skip if you are using a pre-built game engine. I am not that person, and I am going to assume that you, the reader, aren’t that person either.

Choosing which engine you want to use will generally come down to what kind of game you are making and what programming language you are most familiar with (or want to learn). Different engines are better at handling different games and styles, so it’s important to have a firm idea of what you want your game to do and how before you decide on the engine.

Okay, so what are my choices?



Unreal (https://www.unrealengine.com/)

Probably the most easily recognized engine, it is popular enough that even big studios have used it to develop their games. Both XCOM and XCOM 2 were built using Unreal, as was Ark: Survival Evolved. The scripts (programming) for Unreal are all written in C++, but if you are familiar with any object-oriented C-based language you shouldn’t have any trouble picking up the differences. It is a good all-around engine for any 3d game you want to make, and even has some pre-built ‘blueprints’ for specific kinds of games and objects within those games that include scripted basic interactions. For example a gun blueprint might automatically have a fire interaction, a reload interaction, etc that will call your animations and assets without you having to write the script to make it do that. All you have to do is tell Unreal that it’s a gun and point it at the assets and it will do that part for you. This allows you to avoid re-inventing the wheel and focus on what makes your game unique. The biggest drawback of Unreal (which was a deal-breaker for me) is that there is no integrated 2d support. That means that building a retro 2d game in Unreal requires you to essentially create a screen as an object in the 3d world, fixing your camera in a set point where said screen takes up the whole view, and rendering the graphics and a changing texture on said screen. It’s a lot of work, and gets especially awkward when you want to use physics in your 2d game for collisions or gravity or something, since the game is being rendered as a texture.

Unity (https://unity3d.com/):

The second most common engine that I have seen used for indie developers, Unity gives you a choice of using C# (the one you want to use, trust me) or using Javascript (but not real Javascript, old archaic Javascript that hasn’t seen any of the modern updates to the language). Feature wise, Unity and Unreal are pretty comparable. Both claim to be superior to the other because X, Y and Z. Honestly I am not well versed enough to be able to figure out if any of the things that make them different are important. For my purposes, the only important distinction is that Unity includes 2d support. Kind of. In reality, you are still putting all your assets on a screen (or several screens, more on that later) and fixing your camera position. Unity actually has an integrated asset type called sprite (the accepted term for any 2d visual asset), which allows the use of physics to be applied to them in a special way without you having to code the workaround. At the end of the day, it is still a workaround, but the benefits may be worth it for a large number of 2d games and their developers. The biggest of these is the ability to ‘layer’ your 2d sprites by moving them forward a few pixels without it changing their size to the camera. This means that you can render any piece of a sprite independently of others by simply putting it on a different layer. This is super useful if you want to have a character be able to swap outfits easily, or render their legs moving without having to re-render their torso. The tutorial on the Unity engine’s site walks you through doing that and it’s pretty slick. I actually tried making unity work for my game. I think that the biggest reason that I passed on it was that there aren’t many resources available that I could find for how to make the kind of game I wanted to make (a 2d RPG) in Unity. Most 2d resources are assuming a retro platform style game. Still, for someone who is more willing to dive into unknown territory head first than I, Unity is a solid choice.

Game Maker Studio (http://www.yoyogames.com/gamemaker):

I actually have been using this in my early phase of development of Apprentice. There is a huge community associated with this engine, so resources are everywhere to be found, and it is intended for 2d game development, so there are no workarounds necessary. I found it to be by far the most user-friendly engine without sacrificing too many features. The biggest downside of Game Maker is that the scripting language ( a proprietary language called Game Maker Language or GML) is not terribly robust. It feels a lot like Javascript but things are just different enough that someone who is familiar with JS will scratch their head at some of the design choices (like declaring array variables one cell at a time, which defeats much of the point of having an array). Still, the language is capable of a great deal, and the engine can do a lot of it for you. If you are making a 2d game, and you don’t have much programming experience, I highly recommend it. I was perfectly satisfied with Game Maker as my development platform until I came across the last item on my list.

Godot (https://godotengine.org):

Godot is an entirely free (no seriously, read the license. It’s like 25 words long and basically says do whatever you want with it), open-source game engine. My experience with it is VERY limited so far (only found it while doing the research for this article and tried re-creating some of what I did in Game Maker), but everything I have done has felt awesome and powerful. It is designed for both 2d and 3d game development, and the menus and editor are context-sensitive, so it only shows you options that are relevant to what you are doing at the time. Importing assets was a breeze. The most important thing for me is that the 2d editor is a fully dedicated 2d engine with custom physics and screen size scaling built right in (!!!). Time (and this article series) will tell if this is the right choice or if I am about to tumble down a rabbit-hole of game-design nightmares. For sure, a flaw that both Godot and Game Maker share is a unique language. Godot uses a Python-like language, though it does have a plugin that allows for C++ code if you prefer. I was already resigned to learning GML, so I am just going to learn their custom language and see how it goes. Still, I am optimistic enough to have surrendered my engine-level progress on Apprentice (though I still have the assets I made at least) in favor of moving the project to this new engine.

This is a far from exhaustive list of game engines available; specifically it is the engines I looked into when getting ready to create my game. I have heard good things about both Love and Monkey X and I am certain there are plenty of others I have never even heard of before that are excellent as well.

So, what next?

Once you have selected your engine, now it’s time to sit down and start making your game. You will need some assets before you can start creating much of anything, though using very basic placeholder assets is strongly recommended, or else you can spend most of your first few weeks creating assets rather than actually building your game. Yeah, I did that. And then I went and revised the assets anyway because I went a different direction with the style. Go figure.

So next time on So You Want to Create Your Own Game, I will go over some basics of what assets you’ll need, how to get/create them, what kinds of tools you will want, and probably post a video on making pixel sprites (the kind of art asset I am using in my game). Until then!

< Part One: Tips and Tutorials for the Indie Game Designer To-Be

Part Three: Assets and Getting Started>