Skip to content

Narwhal Simulator 4: Choosing a Game Engine

PS. Sorry this one's a bit late, I messed up the scheduling tool.

Hi everyone! Today, I’m going to begin the development stage. I’m going to compare several game engines I could use to develop Narwhal Simulator. This is a very important decision since it is very hard to change later. Most choices can be reworked but changing game engines is very difficult. This is going to be a long one, so buckle up.

Why use a game engine at all? I could totally just write it in straight C#, maybe with a small game library on top or maybe not. It would surely teach me a lot more than using an engine and it would be much cooler to show off since I could brag about not only making a game but also the engine. That would be great if I had unlimited time and patience, and if I was ok with spending tons more time on the planning stage. Unfortunately, I don’t think that making these updates twice a week would be much fun if I didn’t actually start making the game for a hundred installments, so I will be using a game engine to simplify things and speed up development.

First I’ll talk about the criteria I’m looking for. Narwhal Simulator is a 2D game, so the engine needs to be designed for 2D games, or at least compatible with them. It should be free for my use. It should have basic stuff I need, like a physics engine and a way of easily drawing graphics. I will also take into account the programming language it uses. C# is my favourite language, but I would also accept using C++, Java, or maybe Python if I really have to.

First up is Godot. Godot has been around for a while, but it has only become popular recently. It has a 3D and 2D mode, and from what I have read they both seem to be well fleshed out. It is free and open-source. It has 2D physics, sprite rendering, and tilemaps, so the 2D version seems to have everything I would need. The primary language of Godot is GDScript, a language similar to python. That’s no good because Python is one of my least favourite programming languages (although thanks to PHP it doesn’t take the bottom spot), but luckily Godot also works with C#. I have never used Godot before.

Next is Processing, a Java library. It’s not really a game engine, but whatever. It gets to be here because I might use it. Processing is primarily 2D, but I think it does have some 3D capabilities. Processing, as a drawing engine rather than a full game engine, doesn’t have features such as a physics engine, but it does have good support for drawing. If I were to use processing, I would have to make all of the physics stuff myself. I don’t really have a problem with this, but chances are the physics engine of any game engine is going to be better than anything I could produce. I used Processing to make Project Luna and I rather like Java. 

Next I’ll talk about Game Maker Studio 2. Game Maker Studio 2 is a game making engine that’s been around in some form or another for a long time. I first learned to program games in Game Maker. I don’t remember which version it was, but it was definitely before Game Maker became Game Maker Studio. It was pretty good and I was OK with it for a while until I moved on to different programs. Game Maker didn’t cost money back when I used it, but I had the pro version. I don’t know if this would allow me to use Game Maker Studio 2 since it costs a yearly fee now, but I’d have to look into it. From this point on, now that I’ve talked about the original Game Maker, I’ll just call Game Maker Studio 2 Game Maker from now on, even though they’re different things. Game Maker uses GML (the Game Maker Language unsurprisingly) which is based on C, which means it lacks many of the things modern programming languages have, like Object Oriented Programming (classes and stuff). I used Game Maker (the old one) to make many of my first games, although none of them are worth talking about.

Next is Unity. Unity was originally a 3D game engine, although it is now as much a 2D game engine as a 3D one. Unity is free to use for teams who earn under $100k a year, so I can use it for free. Unity has a physics engine and sprite rendering out of the box, as well as quite a lot of other stuff. Unity uses C# as a programming language, so that’s great. If I used Unity, I wouldn’t need to make very much stuff myself at the start, but I might decide later to make a new physics engine depending on how Unity physics2d works out for me. I have used Unity for a long time but I haven’t made very many finished games from it, and only one has actually been published here. I made Mars Rover Simulator, which you can play here

Finally, some honourable mentions that didn’t make the list. I could have used Unreal Engine, but from what I’ve read online, the 2D support isn’t very good. I also looked into Cocos2d but it seemed to be a lot more focused on mobile games. 

I’ve narrowed the choices down to two, but this is not factually correct and if you decide to make your own game, make sure to look into the options yourself to see what fits your criteria the most. I’m ruling out Game Maker Studio 2 because of the lack of Object Oriented Programming support in GML. I really like my classes and I don’t want to give them up. I’ve also decided to rule out Processing because making almost a whole game engine myself, except for basic drawing to the screen, is daunting and would take me a long time. That leaves us with Godot and Unity.

Choosing between Godot and Unity for Narwhal Simulator is a tough choice. They’re both quite similar. They both support C#, my favourite programming language (but Godot doesn’t primarily use it) and they both are primarily 3D but have good 2D support. They both provide the actual editor for free, although Unity offers services like premium training and expert support for a monthly fee. One difference from what I’ve read is that Godot’s physics engine is a bit worse than the Unity physics engine. The main difference I believe is the sheer difference in the user base between Godot and Unity. Unity has tons of people using it, while Godot has a rather small community. Having a larger community means chances are if I run into an issue, many people have had it and asked about it before, while if I used Godot, I’d be a lot less likely to find threads about my issues. Because of this, I’ve decided to go with Unity. This paired with my previous experience with Unity will hopefully make development easier than if I decided to use Godot. I think it would be a shame to use Godot but not use their custom-made language anyway. If you are planning on making a game, I’d definitely recommend checking Godot and Unity out.

If you read the whole thing, thanks, or if you decided to skip to the bottom, I decided to use Unity, but Godot was a close second. Over the next few days, I will configure the GitHub repository for Unity and get the project started, and maybe I’ll have some player movement implemented to show off. I’m excited to finally be showing things! Thanks, see you Friday.

Links recap:



Leave a Reply