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?
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.
Game Maker Studio (http://www.yoyogames.com/gamemaker):
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!