off the loop thoughts

Making a game with Go: #0 Introduction

This is an introductory issue about the goals, choices and challenges of my new quest: making a game in Linux with a framework and not an engine. Here in issue #0 I will explain the whys, the hows and the don'ts and starting from the next issue I will write a tutorial alongside an open source game hosted on Github. I hope you follow me along.

Audience

You should be interested in making a game in Go. You should also be able to code. I won't teach coding basics. If you don't know Go but another language you should be fine. Go is easy to pick up. If you are still interested, just give it a shot, it's free ;).

Motivation

The process of creating software can be very satisfying and creative. Especially making a game is a creative endeavor. I grew up with the very simple games such as Pacman and Tetris. Back then as a kid I made my own simple games with Quick Basic and Turbo Pascal. Of course they were not great but I learned a lot and it was as much fun as playing games.

Later as a student I made more games. They still were not great but a lot better than my previous ones. Over the years I attempted to make several games but I never completed them. They were either to big in scope or their core idea didn't convince me enough to keep going.

Today I have a clear plan. I want to make a game again. I want to finish it and it should be small in scope but fun to play: a coffee break game with some potential. And as additional way to stay motivated I will blog about it and maybe someone can learn a thing or two (myself included).

So what's it gonna be?

I will steal the core idea of another game and then go from there and inject my own ideas into it. Wait isn't this really cheap and shouldn't I think of my own idea? Maybe but I don't think so. Practically every game steals ideas from other games. You wouldn't consider Half Life a clone of Doom would you?

Also I will give proper credit to my inspiration: the game in question is Qonk.

Qonk Legend (source: http://anthony.liekens.net/images/qonk_legend.png)

It is a very simple real-time strategy space game. You start with a planet that is constantly producing ships. You can send these ships to conquer other planets to increase your total ship production and hopefully conquer the whole galaxy. Your enemies (AI) try exactly the same thing and thus counteract you. A game that is very similar in its design is Galcon with the main difference that in Galcon planets don't move and its main focus is on multi-player.

Now the key concepts I want to steal from Qonk are:

The following ideas I had may be crap or out of scope but for completeness I will list all of them:

I will certainly have more ideas later on and also most of them won't make it into the game. But it's always good to have a list!

As a last note on this topic let me say that this game won't have hand-made sprites. I will focus on geometric shapes and procedurally generated assets. I will have to find free music and audio effects on the internet. If you know good sources please tell me.

The tech stack

These days there are so many tools and libraries and engines to help you make a game. And a lot of them are even free. The hard part now is deciding on one and committing to it. Every developer and every game have different needs but for me it cannot be a full-blown engine. I am a coder and I don't want to learn more GUIs. I don't want to fiddle with scene graphs and attach code to some sprite node with drag'n'drop or whatever. That's why I always knew that I can skip Unity, Unreal, Godot and similar products.

The programming language is of course another important choice. One obviously should pick what he likes and has experience with. Also the ability to build for many platforms is pretty important for me personally. In the beginning I considered the following frameworks or libraries for my project.

All of those are good frameworks. However I came to the conclusion that I don't want to deal with those languages for different reasons. I have used Löve and Lua in the past and it's a really good experience but I prefer compiled languages.

Now meet my pick: raylib.

raylib (C / C++ / Go or other languages via bindings)

Raylib is a C library that aims to be simple to use and minimizes its dependencies. It is easy to build for most platforms because of the low dependency count. Ray (the creator and maintainer) is super active and knows what he's doing. Also he is very helpful and teaches students to make games. There are bindings for a few more languages maintained by other developers.

I am quite proficient with C / C++ but my language of choice has been Go over the last few years. Gladly there are bindings for go: raylib-go. My plan is to use raylib-go for this project and if there should be unexpected problems with it I can port my game back to original raylib without too much trouble. I have also created a little particle system in raylib before: libpartikel. So I already know something about raylib's very nice API.

The raylib community is still small but constantly growing and I am confident that potential problems can be figured out via the Discord channel or Github issues.

Why Go?

As I already said Go is my language of choice but I also think that it is great for making games. It has a C-like simplicity but compared to C it has a great standard library. Go uses composition instead of inheritance which is just perfect for games (see entity component systems). It can cross compile to various platforms with ease. Go has a bright future ahead of it. It is very actively developed but new features have to really add value to be added to the language. This is a good way to avoid becoming an ugly messy bloated language (sorry Java). Of course there are currently no generics but that's another discussion. The next version of Go (1.11) should add a WebAssembly (wasm) target to the go compiler. Now that's awesome too.

Now you say: "But it has a garbage collector!". Yea that's right. That can be a bummer for some games, especially for AAA ego shooters. It's a good thing I won't make such games. Most games today will do just fine with a garbage collected language. However you should not write crappy code and just allocate new objects like a madman while throwing the old ones to big bad GC.

The current state of game development tools and frameworks in Go is not great compared to other languages like C++, Java, C#.. but there is work being done and I am confident Go will gain more attention in the game dev community over time. The current major frameworks are Pixel, Ebiten, Engo and raylib-go. Pixel is still too beta-ish for my taste and does not support mobile/web target yet. Ebiten looks very promising to me but it just does not support custom shaders, which makes me pass at the moment. I am not sure about the state of Engo at the moment. It had a phase of low maintenance but it seems to have picked up some steam again. It's certainly worth observing. I covered raylib already above. The only thing I'm a little sad about is that building for the web is not possible currently (it is in original raylib via Emscripten).

Structure & content

This is a side project for me. That means I don't have a fixed schedule at the moment. Maybe I will write an issue once a week, maybe twice a month. I don't know but I have a certain set of topics in mind that I want to address over the course of this tutorial:

These topics are subject to change. They also overlap and the order is not set yet. Every tutorial issue will be accompanied by commits and tags in the game's Github repository. This way you can easily follow the code by checking out certain tags.

The end

If you made it until here there is a good chance we will see us in the next episode :-)

Discuss at Github