Learning Gamedev the hard way

In "Learning Gamedev the hard way" I want to share my journey so far in learning to make games. I had a very slow progression due to some big mistakes I made by being hard-headed. I started years ago and I am still a beginner with very little to show for. I will dive into my memory and bring up stuff I experienced along the way. Maybe you can avoid some of the mistakes I made. Or learn something from the things I did right.

"Epsiode 0": The very first attempt I ever made at coding games.

Part I: overview

I had spent my whole childhood dreaming about making a game myself or with friends. I remember fantasizing about crazily complex games that I wanted to make. From long point&click adventures to full MMORPGs!

In late 2015 (much older now) these dreams got triggered by a retro Warcraft2 LAN session with a couple of friends. Playing the game got me thinking about the details of the game’s underlying model. Like its movement system: In every tile there is always only a single unit, and a unit is always one tile in size. So I thought: "Seems easy enough. I wanna build my own Warcraft2-like RTS!”. My first very positive lesson:

Lesson 1: Observe the games you play closely, so that you can figure out details about their implementation. And these observations can in turn trigger your creative thinking.

I had zero experience, so I probably should have started with something much easier than this. But it got worse: I wanted my game to be multiplayer. With buildings you could enter, loads of spells, heroes and so on. This hints towards a very important lesson that I could have learned then, but wouldn't learn for years to come:

Lesson 2: Scope realistically. You should be able to finish the game with the time, skills and resources that you have. Prefer smaller plans to begin with. You can always extend them and add features later.

I knew some basic C and a bit of C++, so I started searching for how to make 2d graphic games with C/C++. I ended up finding this famous tutorial for SDL: https://lazyfoo.net/tutorials/SDL/. So SDL and C++ it was. I had heard rumors about this "Unity" thingy, but I thought "Good god that's not open source, I'm not gonna use something like THAT!"I went ahead, read the SDL tutorials and then built everything from scratch.

Lesson 3: If you start learning how to make games, use simple tools, use an engine. It will be hard enough, and you need to learn a lot anyways. You can always come back later and do the low level stuff if you really want to. Watch/read tutorials to steepen your learning curve!

Some of my friends had similar dreams about making games. So I convinced one friend of mine to start working on this Warcraft2-like project. To get him motivated, I came up with a first prototype for the game world – a scrollable background made from two hastily drawn tiles. Just making this very simple thing took a lot longer than I expected, which brings us back to the problem of scoping correctly. I presented the "game" to my friend and he actually debugged a single line of code. That was all he contributed to the project. Ever.

Lesson 4: If you want to collaborate with others, be sure that they are actually motivated, and that it wasn’t just you who talked them into it.

But even though I was alone, I went ahead developing the game. I wrote plans for milestones, and what I wanted to implement in what logical order. This helped me stay motivated and I always knew what I had to do next. To this day I feel that writing stuff down, especially by hand, is supremely important. You get your mind into a different state, a “planning mode”, where you don’t get bogged down by every detail of implementation. Once you have your plan, you go ahead and implement, and your mind will switch into “problem solving” mode. An additional bonus of having a plan is the dopamine boost that you get from crossing out “action items”. Celebrating your achievements is easier this way.

Lesson 5: Making (hand)written plans is a powerful tool to stay on track and stay motivated.

What I did wrong however was to plan too far into the future. This is somewhat related to the scoping question. You might discover that, in order to make the game work or to make it fun, you need to fundamentally alter something about it. This might mean that you have to throw away plans that you spent precious time and energy on.

Lesson 6: Stay focused on the next task ahead, don’t waste time planning stuff that you will eventually have to scrap

Another grave mistake I committed is related to me not using an engine. I did ultra low level C++ coding. For people into C++: I even coded linked lists from scratch, instead of using the standard library’s std::list class. Or I implemented the A* pathfinding algorithm myself, instead of taking someone else’s implementation from the web. This is one of my biggest hurdles to this day; I tend to want to build everything myself.

Lesson 7: Use as much leverage from other peoples’ tools as you can. Don’t reinvent the wheel.

Of course I ran into another problem: "What about graphics"? I need to mention that I am a terrible "artist". My hand drawings look like a 5year old's. So I decided to make pixel art, which I thought would be the most manageable option graphics-wise. I read tutorials on pixel art, and I started painting some. With "kolourpaint", the KDE linux clone of MS Paint. In the end, I was surprised at how "well" my art turned out. I mean it's ugly, but it wasn't as ugly as I feared. So I think I will share some sprites with you.

To this day I feel that giving new things a try is worth it. Conquering tasks that you think you are bad at often feels more satisfying than conquering tasks that you are already good at. On the other hand, if I had gotten an artist on board, I am sure the project would have progressed a lot further than it did.

Lesson 8: If you have the time and energy to learn something new, even in areas you feel bad at, go ahead and do it. It feels empowering and it will give you more motivation. At the same time don’t fall into the trap of doing unproductive work and hindering to progress of your project.

I followed through a few milestones. I implemented units, movement, combat, spell-casting and even multiplayer. But one random day I just stopped working on the project. Back then it felt like a failure. Looking back I would say: Not bad for your first project! My biggest problem was probably that I didn’t have an achievable plan on where the game was headed. There was always a mountain of things I could add. I had no strategy for finishing, polishing and showing the game. This is something I struggle with to this day: Getting my stuff “shipped”.

Lesson 9: Know what kind of project you are working on. Where do you want to put it for other people to see? A game is made to be played.

This is what the final version looked like, which I found on my long forgotten hard-disk:

After my first project, it took me three years to pick up gamedev again.

Next time, I will tell you more about the game itself, its model and its mechanics.

Me on itch: https://daju.itch.io/