GameDev Log #1 - Getting Started

I recently realized that I'm more capable than ever to actually turn one of my childhood dreams into reality. Creating my own video game, that is. When I was a young teen I always dreamt of making my own game. I started by doing some first experiments in Visual Basic, but as I didn't have any experience in programming I didn't get very far. That lasted until I discovered Game Maker, which made things quite a bit easier for me. I was hooked, especially after I've gotten the book "The Gamemaker's Apprentice" for my birthday, which covers the whole flow from start to final (simple) game.
Using that as a basis, I created a few small games back then. I particularly remember two Jump'n'runs I made, which were Simpsons and Spongebob themed. Me and my brothers drew the sprites together and I would create a game out of them. We even recorded some phrases from the TV shows to put them into the game. Unfortunately the results of our work are gone for good. I'd love to revisit them, especially as I don't remember much of the actual gameplay, but maybe it's for the better as I'm pretty sure they weren't as great as I remember them.
Anyway, after that I didn't think much about creating my own game anymore until recently. This was when I realized that I'm in a better position than ever to actually put that dream of mine into action. Since then I've gotten a Master's degree in Computer Sciences and several years of experience as developer, so my chances actually look decent to succeed, at least on the programming side.

Finding the right tools

After that epiphany, the first thing I needed to do is to find the right tools for the job. The great research time began!
Researching and comparing solutions is actually a thing I enjoy a lot, so this was more of a pleasant experience than a chore to me. Most information I got was from the fantastic Youtube channel GameFromScratch, which I watched for hours and hours comparing different game dev tools and engines.

The first thing I laid down for myself was that it has to be a 2D game. 3D would make it too complicated in coding as well as in creating the necessary assets. The next thing I defined was that I want to use a game framework rather than an engine, so that I can at least increase the learnings I will take from this, even if I might fail.
Since I want to go for a pixelart style game I decided to use Aseprite to create my assets, as it provides quite a lot of convenience features and also allows you to create animations directly within the software. Additionally, I bought a huge sound FX pack from itch.io, which was discounted to ~10$ and I figured I can't really create those effects on my own (maybe I'll record a bit of voice, though). Aside from that I also bought 1BITDRAGON which makes it a lot easier for people like me to create their own music. I didn't spend too much time on it yet, but even in the short period of time I tested it, I got some decent results out of it, so I'm optimistic.

Another thing you'll need is an actual game engine/framework. Here is where it gets tricky. There is an abundance of game engines out there, each with its own quirks and strong suites. And as this is the area in which I'm most experienced in (I basically got no clue about creating game music nor art), I felt a strong urge to try a bunch of them myself to see what I like the most.
So the first one I went for was LibGDX, as it seemed quite logical. I use Kotlin in my dayjob and as LibGDX is a Java game engine I can write my game entirely in Kotlin. I actually liked it and there's a lot of Youtube tutorials out there that would guide you through the whole process of creating a game. One issue I had, although not an issue with the framework itself, is that you are not forced to follow a specific way of implementation. So when I started I just followed one guy on Youtube and it took me a while to figure out that his way of doing things wasn't all that great. Maybe it's alright for total beginners, but I wanted to use a nice and maintainable architecture right from the start.
So i scratched everything I had and followed another tutorial, this one was way better and I really learned a lot of things, especially about entity component systems (ECSs), an architectural pattern I've never used before.
Although it was already going kinda well, I still ran into some issues. Especially concerning the ECS, as I never felt like I had proper control over it. But that was probably more me not getting the hangs of it than the ECS' fault (which in the case of LibGDX is called ashley, by the way).
So I moved on as I wasn't totally happy and I wanted to compare some game frameworks anyway. The next ones I tried were Love2D and Bevy.
Both were very nice in their own way and I was able to achieve results quickly. But although Love2D probably gave me the fastest results of all the engines I tried, thanks to all the amazing Lua libraries and Lua's easy to learn syntax, it did not seem like a proper fit for bigger projects as it's not type safe and your code might fail silently during runtime as well as a lot of convenience features do not work, namely autocomplete and refactoring.
I tried to fix at least parts of that by switching to a typed Lua dialect called Teal, but that in turn broke some of the libraries I was using. So I moved to the other extreme of the spectrum, to the Rust library Bevy. Bevy is still under heavy development and changing quite a bit from update to update, that is probably the reason why it's documentation is almost non existent. Although they're already planning on improving that in the future by creating the Bevy book. Aside from that I can not say anything bad about Bevy itself, except that I don't think Rust is the perfect choice for game development, although certainly also not the worst, but that's a personal opinion.
Before I arrived at my current choice, I also had a quick peek at Korge, which is completely written in Kotlin, so it can actually compile to native code and DragonRuby, which allows you to write games in freaking Ruby. Although I only checked out the latter because I got it for free when they were giving it away on itch.io for a day. I didn't implement anything in either of them, but I checked out the examples of Korge and watched around 1h of Ryan Gordon implementing Tetris in DragonRuby. I wouldn't use DragonRuby because of multiple reasons. For one it's not open source, second it requires you to pay yearly if you want to release to mobile and finally because it doesn't offer any bindings to a proper physics library (there only seems to be a very outdated Box2D binding for Ruby, but I'm not even sure if that works). And I later decided that it would be cool to have some proper physics in my game.
Korge on the other hand doesn't have any of those anti-features, but the things that didn't really convince me, were that its level editor frooze several times on me and that the whole framework is basically created and maintained by a single guy. Which is impressive, of course, but makes me worry about the project's future.

So finally, I discovered a framework called raylib, which is written in C and has a crazy amount of bindings to other languages. Although this one is also mainly created by one guy, the project itself received a lot of contributions from others and also Ray received an Epic mega grant, so I see its future more optimistic. Additionally, you can easily use the Physac physics engine with it. But as I don't want to write my game in C nor C++, I tried to find a language I liked, which has up-to-date bindings to raylib. The most promising one I found was this one here, which binds to the Nim programming language.
I've actually heard about Nim before by coincidence, or actually I've known it by its original name, which was Nimrod, but I bet a lot of developers never heard of it before as it is a rather niche language, which is a shame. It's a language that compiles to C, which in turn compiles to highly optimized native code. Because of it's compilation into C it's also very compatible with any C library, while the language itself is very highlevel and kind of Python or Ruby like, but also borrows a lot of features from other languages. This makes it very interesting as a game development language, as you can script your game in a language that is a joy to write, while still producing performant executables that can bind to existing C libraries.
Intrigued by this language I decided to give it a try and so far I've not been disappointed. The bindings work like a charm and its syntax is very readable. One issue, though, is that there's almost no library for game development yet, so you have to build quite some things from scratch. For example, if you want to use LDTK as your level editor, there won't be any SDK that you can readily use. There seems to be an inofficial one for Tiled, but it's broken. Given this situation I decided to just write my own parser for LDTK and see how I can proceed from there. The documentation of LDTK's file format is amazing and it gave me a good first task to learn Nim, so I actually enjoyed it a lot. I will probably release the outcome once I deem it usable. After that I already started rendering the map and drawing some animations, which works nicely. I have to say that I rather enjoy writing those things myself, as I got a much better understanding of how things work now and I will probably tackle my own ECS in Nim in the future. But that will be the topic of a later blog post, as this one is getting way too long already.
The next one will hopefully be way shorter and I hope to release status updates in a regular manner, but we'll see if I'll actually achieve that.