Choosing my game development tech

Introduction

As I went full-time into game development recently, I started having a more serious look into game development tools. I already spent some time at the beginning of the year, and tried game engines such as Unity or Godot, and frameworks such as love2d. But now that I’m going all in, I needed to do a proper research to decide what tool suits me better.

Requirements

Before studying the tools available, I had to make sure I had a clear idea about what my requirements are. This is not a easy task, as you cool potentially need anything, depending on the next game you are going to make. I’m going to focus on 2D games, as I like them more than 3D ones, and are also easier to make (which is appreciated when you work solo or in a small team). Given this, I tried to constraint myself to the following:

Must have’s

Reasonable development speed

As a -probably- solo developer, I need a tool set that makes me reasonably productive. I could theoretically spend enough time without making money, as long as I live frugally, but it’s better to think about game development as a business, not just a passion. I could be doing other things (web, mobile, or backend development), which means that the opportunity cost is high, so making some money soon will be important.

Potential support for any platform

I believe this is very important for indie devs (not even just game devs, but any kind of independent developers). If you can diversify by porting your games (or products/services) to multiple platforms, you have more chances of surviving.

Nice to have’s

Flexibility

Being a software developer, I would like to have some control over the way I code my game. This means that, the less intrusive the tool is, the better.

Low initial investment

Having a tool that doesn’t require a lot of up-front time to learn is ideal, as being a solo developer means that you are short on time.

Performance

No one wants their games to run at 20 FPS, right?

Access to low-level

Even if I don’t want to be dealing with low-level stuff all the time, it’s important to have the possibility of accessing the low-level APIs if needed (e.g. for performance bottlenecks, or specific requirements).

Good ecosystem

The better the tools around, the less time you could spend (if you choose to) on building them yourself.

Development on more than one OS

I still haven’t decided what’s going to be my next laptop for work, so it would be nice if my development tools were available for the three main OSs, Windows, Mac, Linux, specially the first two.

Battle-tested

Ideally, the tool will have some games that have been a commercial success, proving that it’s a solid “real-world” alternative, not just used for hobbyist games.

Healthy future

No one wants to invest time in learning a tool and building utilities around it, and then have to start again because that tool gets out of the scene somehow (unmaintained, company out of business, etc.). This is difficult to predict, and there can be very unexpected and difficult to understand decisions when using proprietary tools (see XNA), but we can get a gut feeling to have some confidence that our tools won’t be trashed in the next 3 to 5 years.

Pricing

Not a massive deal, as long as the tool saves you good time, but still important.

Don’t need’s

Everything can potentially be useful, but you need to cut off somewhere when deciding. I definitely don’t need 3D features for the games I want to make, so I won’t be taking them into account.

Candidates

I researched about quite a lot engines, frameworks, libraries, and programming languages, for game development. However, I wanted to pre-select only a couple of tools, to avoid making the decision too long, so I chose the ones that “looked better” (larger community, better suited for making games, baked by a big company, etc.). These are the ones:

• Unity
• Godot
• MonoGame
• Love2D
• Custom tools

First round: Must Have’s

I’m going to focus on the Must Have’s first, to discard the options that don’t pass the minimum requirements. Let’s go through all the points.

Development speed

Unity

• Is a game engine with a fully-featured editor. Unity focuses on developers’ productivity by providing lots of features and an assets store.
• Uses C# as the programming language, which is a good compromise between speed and performance.

Godot

• Is similar to Unity, although it has a much smaller assets store. On the contrary, I found working with Godot easier, with a nicer editor, being more 2D-oriented, and using a Python-like language that makes development quite fast.

MonoGame

• Is a framework, which does less for you than engines like Unity. It is still high level enough to have things working quickly, as it handles for you things like rendering, audio or input.
• It doesn’t provide an editor, apart from the Content Pipeline tool to manage assets.
• Uses C#.

Love2D

• Similar to MonoGame, it focuses on providing the basic tools to help the developer get started with coding the game.
• Uses Lua as the programming language, which means that it’s good for prototyping and getting stuff done quickly.

Custom tools: SDL2 + Low level APIs (OpenGL, Vulkan, Metal, console-specific)

• SDL2 is a low level library to handle graphics, audio, and input. It provides you with less out-of-the-box utilities, compared to a framework. It has got bindings for a couple of languages, but I only considered C++ and Rust, as going for the low level approach makes sense if using a proper systems programming language with no garbage collector (this is why I don’t include C# here).
• C++: Is the industry standard programming language. It generates the most performant code. However, even with all the recent improvements, it’s still quite easy to shoot on your foot. Also, managing dependencies and builds is a pain, compared to other languages.
• Rust: As a programming language, I like it a lot more than C++. Not only has got cargo, which simplifies dependencies management and builds, but also helps you write concurrent and memory safe code, which generate some of the worst kind of bugs a game can have. I didn’t consider Rust + existing engines, as they are still very young.

The game engines and frameworks above give me a fast enough workflow to be happy about them, so they pass this test.

As much as I like low-level programming, and gives me so much flexibility, going that path would probably be unwise for a solo developer that needs to build its own tech from scratch. Specially with Rust, it sounds like going down a path which is still too brave, as it is still a bit young and doesn’t have a big adoption in the games industry. I really want to eventually use Rust for game dev, but I have to be honest with myself and realise that I wouldn’t be productive with it, compared to other alternatives. Maybe in a few years my feeling will be different. Even using C++ would involve a lot of work on top of low level libraries. I might reconsider this in the future though, specially if I hit any bad roadblocks during my first games.

Platforms support

Unity

• Supports all the major platforms (desktop, mobile, consoles), plus a bunch of other platforms.

Godot

• Supports desktop and mobile out of the box. It doesn’t include exports for consoles, but the engine is written in C++ and it’s open source, so nothing would stop you from using the native APIs.

MonoGame

• Supports desktop, mobile, and all the major consoles. The integration with the consoles requires talking to the maintainers of MonoGame, though, as NDAs don’t allow including them in an open source project. I haven’t tried them personally, but I’m quite confident that the integration is good.

Love2D

• Supports desktop, and mobile (although it’s not straightforward). It doesn’t support consoles. The engine itself is written in C++, which means that you could potentially add support for consoles. However, the main programming language for the developer is Lua, which implies writing bindings (extra complexity).

Custom tools: SDL2 + Low level APIs (OpenGL, Vulkan, Metal, console-specific)

• C++: This is the best language to interact with low-level APIs, as the code is usually in C.
• Rust: It is possible to call C code from Rust. It requires bindings tough.

All the options either support many platforms out of the box, or have their source code available, which means that you could add support for the missing ones (mainly consoles). However, languages like Lua or Rust require writing bindings, which means extra complexity and work.

As much as I like love2d (my favourite tool for prototyping), it needs some work on the exporting tools. Using the low-level approach, with either C++ or Rust, would also require adding support for some platforms (mainly consoles).

Conclusion

The only options that fit these two requirements so far are Unity, Godot, and MonoGame. I will keep my options open in the future for Rust though, if the ecosystem improves and gets more adoption, and I can afford spending the time to switch.

Second round: Nice To Have’s

At this point, there are 3 suitable choices. However, some of them will offer more interesting advantages than others. Let’s have a look at all the points.

Flexibility

Unity

• As with any engine, you need to make you code fit in it. This means that you lose flexibility when writing your code.
• Only C# is supported.
• Unity is proprietary, and the source code is read-only. You can’t modify it or send pull-requests to fix problems or adapt it to your needs.

Godot

• Being an engine, it suffers from the same problem as Unity in terms of the way you have to write your code.
• C++ and GDScript are the main languages, but C# is also supported, as well as Visual Scripting. There are unofficial bindings for other languages, such as Python or Rust.
• It’s open source.

MonoGame

• Being a framework, it doesn’t dictate the way you have to write your code.
• Only C# is supported.
• It’s open source.

MonoGame has better flexibility than the two game engines. Godot offers the largest variety of programming languages to choose from.

Low initial investment

Unity

• Unity is quite a complex engine. It would require a good amount of time to learn. Also, some skills wouldn’t be transferable to other engines.

Godot

• Same as Unity, although Godot is simpler.

MonoGame

• This is a really simple framework that provides the basic blocks and a few other utilities. It requires little time to learn.

MonoGame seems to be easier to learn, as it’s smaller. Although you can get started with the basic stuff on Unity or Godot, and learn-as-you-need new features.

Performance

Unity

• Difficult to say. It’s getting more and more optimisations, so I believe that it should have an acceptable performance. However, if you hit a bottleneck, you might be blocked, as you can’t tweak the engine source code.

Godot

• Written in C++, which usually means good performance.

MonoGame

• This is tricky to say. As Unity, it uses C#, which can be slow especially if the garbage collector is triggered at an inconvenient time.

I haven’t tested this area enough, but I can get a feeling. All three options should be ok, specially for 2D games.

Access to low-level

I don’t know much about this yet, and haven’t tried it personally, so I’ll just base my opinion on some research that I’ve done.

Unity

• It is possible to select the graphics API (DirectX, OpenGL, Metal) to be used. However, the code is closed, which means that you can’t go into the low-level in some situations.

Godot

• Same as Unity. At least, the source code is available, and could be adapted to our needs.

MonoGame

• It is a lower-level tool compared to game engines, which gives you more control.

MonoGame seems to offer the best control over low-level features.

Good ecosystem

Unity

• The asset store is full of useful utilities for developers, some of them for free.

Godot

• Not as good asset store as Unity.

MonoGame

• It has some tools build around the main MonoGame framework, but probably not so many compared to Unity.

Unity beats both Godot and MonoGame here.

Development on more than one OS

Unity

• Can be used on Windows and Mac.

Godot

• Can be used on Windows, Mac and Linux.

MonoGame

• Can be used on Windows, Mac and Linux. Also, the main tools (Visual Studio, and Content Pipeline) work on all three.

Unity doesn’t work natively on Linux, although Windows and Mac would probably be my choices for game development.

Battle-tested

Unity

• It has, by far, the largest amount of hits and successful games built with it.

Godot

• There aren’t many successful games built with Godot, yet. I think it will be a matter of time though.

MonoGame

• There are a couple of very successful indie games shipped with MonoGame.

Both MonoGame, and specially Unity, have big indie titles out there. I’m not so sure about Godot at the time of writing this blog post.

Healthy future

Unity

• Unity seems unstoppable. It’s probably the most used tool by indies.

Godot

• It’s improving a lot, specially in 3D features. I’m concerned about the 2D side though, which is where it really shines. I feel like the developers are more focused on 3D stuff, and bugs on the 2D engine are not high priority.

MonoGame

• This framework is maintained by a couple of people, which makes it the more “fragile” out of the 3 remaining options. However, MonoGame started as a replacement for XNA (which was left behind by Microsoft), and being open source makes me feel confident that someone would pick it up in case it gets unmaintained.

Unity seems to have a rock solid future. Both Godot and MonoGame are open source and have a good community, so they should be relatively safe.

Pricing

Unity

• Paid, once you need something beyond the basic features, although it’s possible to ship a game with the free license.

Godot

• Free

MonoGame

• Free

Conclusion

For the final round, I would like to choose two different options: a game engine, and a framework. The framework is pretty clear (MonoGame). Out of the two game engines, Unity feels much more mature. Godot is better for 2D, but I found issues with the physics engine that concerned me and made me lose confidence in it. Also, Unity has been used for big games, which is a CV that Godot doesn’t have yet.

Other tools

I should also mention another two options that didn’t go through the pre-selection. Both have very successful games made with them, so it’s interesting to have a brief look at them as well.

UnrealEngine 4 is, probably, the best 3D engine out there. But, as I’m going to work on 2D games, this is not really an advantage, and its 2D features are not on par. Also, it’s more complicated than Unity.

GameMaker is the second most noticeable tool missing on the list. As much as I think it’s great for 2D games, its prices are too expensive for a solo developer, specially if you plan to release on consoles. Also, being proprietary, it suffers from some of the problems as Unity does.

Final choice

As much as I think Unity is an amazing tool (and looks like the 2019 releases are going to make it even better), it is too closed for me. As a software developer, I can’t give up on making things in my own way, so I prefer a framework that gives me the basic tools and lets me build on top of them. Also, the fact that you can’t adapt Unity’s source code to your needs really puts me off. My last major concern is that you are at Unity’s mercy and changes in their pricing model, the way you can use their tools, licenses, bug-fixing, etc. While you get a lot of good things in return for this trade-off, I personally feel more comfortable with something more open.

The only battle-tested open source tool from the list above that fits my requirements is MonoGame, which has been used to ship games such as Towerfall, Celeste or Fez. Overall, I think it is a good compromise for programmers who don’t want to constraint themselves to what an engine dictates, but don’t want to go into the low(est) level that SDL, OpenGL, Vulkan, etc. require. Also, it’s open source, which can be a big an advantage (ability to fix bugs on your own, adapt it to your needs, support new platforms without waiting for an official release, etc.). Even the language it uses, C#, is a good compromise between development speed and performance, specially for 2D games.

I’ll find out whether MonoGame is the best choice as I make some games with it. If Unity gets open source’d, things would change, and I might consider it again as my first option. Also, as I mentioned before, I’ll keep an eye on Rust. It’s a very promising language to replace C++, and I would eventually like to build my own tech to have complete control, but I feel like Rust is not quite there yet, and also, for now, I should focus on making games, not tech.

NOTE (08/01/2019): I drafted this post by the end of October. I decided not to edit it, but leave the original post and add a couple of notes. I’ve been using MonoGame since then, and I’m not looking back. I had a few problems on Mac (not-so great IDE, and some stuttering issues), but on Windows everything feels right. I’d still like to play more with Unity, and I’m learning Rust for the long run. But, for now, MonoGame gives me the degree of control I was expecting, while still being productive, so I’m sticking with it for a while. I also have to say that the developers were really helpful when I had the issues, this is really appreciated and definitely a bonus.

NOTE (10/01/2019): Here we go, someone had problems with Unity’s terms of service. This is what concerns me the most and makes me stay away from an otherwise good tool. If they become more open, I’ll reconsider it. Unfortunately, this is an example of the concerns explained above.

NOTE (01/02/2019): Unity updated their Terms of Service a few weeks ago. This is a good move towards becoming a more open platform.

Originally published at srodrigo.me on January 11, 2019.