Making games in Go for absolute beginners
threedots.tech
threedots.tech
Making games is so much more challenging and rewarding than almost all of the work I've done for pay. There's always so much more to learn that doesn't feel like just relearning how to do the same thing except with a different framework of the week.
It's the one point preventing large adoption of go as a gaming language I think. I haven't found a 3d lib that supports building for mobiles.
And it's really too bad, because go would be perfect for writing games.
I did this in 2021 in GO and Ebitengine and I was blown away by the performance the screen was mostly white with pixels, how easy it was to get the context running, and how many pixels I could move on the screen at 60fps... I was truly impressed. I've been using this approach for the last 30 years I guess ;-) We're a long way from moving a few hundred pixels on a 16 bit CPU per frame... greybeard out
A web project does not prepare you for a bad UI history, for example...
Re: the comments on here about the GC etc. -- I've posted about this a couple times before but I've been using a custom Go (subset / some changes) -> C++ compiler for hobby gamedev, which helps with perf, gives access to C/C++ APIs (I've been using Raylib and physics engines etc.) and also especially has good perf in WebAssembly. Another nice thing is you can add in some reflection / metaprogramming stuff for eg. serializing structs or inspector UI for game entity properties. I was briefly experimenting with generating GLSL from Go code too so you can write shaders in Go and pass data to them with shared structs etc.
The compiler: https://github.com/nikki93/gx (it uses the Go parser and semantic analysis phases from the standard library so all it has to do is output C++) (it's a subset / different from regular Go -- no coroutines, no GC; just supporting what I've needed in practice -- typechecks as regular Go so editor autocomplete works etc.)
A game made with it a while ago for raylib game jam along with the raylib bindings and other engine stuff: https://github.com/nikki93/raylib-5k
Very old video of a longer term game project I'm using it on which also shows state-preserving reload on rebuilds and also the editor inspector UI: https://youtu.be/8He97Sl9iy0?si=IJaO0wegyu-nzDRm (you can see it reload preserving state across null pointer crashes too...)
UnitOfTime is his YT & Twitch handle https://www.youtube.com/@UnitOfTimeYT Uses his own binding to OpenGL and WASM to WebGL2 for Web version.
Used to use Go myself, but fell out with it. But I can understand why people would enjoy making games with it. Just like SolarLune himself uses Golang for his gamedev. A lot of people seem to ask the same question tho: "Why make it in Go? Doesn't it have GC?" From my understanding Go's GC is quite robust as well.
In a nutshell, nice to see Go having more usage outside the norm that devs expect it to only be used in.
If you’re experiencing the kind of burnout that the author described, I’d suggest an alternative to doubling down and “reclaiming” your hobby: make your interests evolve. It could very well be your body (specifically your brain) telling you that you’re stagnating. It doesn’t have to be different getting programming, but perhaps you’ve reached a point that it is time to go deeper, possibly into CS theory.
https://github.com/sedyh/awesome-ebitengine
All of the games listed on my itch.io profile were created using Ebitengine, and they are all open source.
To fix: a hanging sentence "Here’s how an example Sprite component can look like"
For any game that doesn't require smooth frames for the experience, the best language is the one you're most comfortable with (modulo some base level of game dev community)
Edit: on the other hand, Go is a superb candidate for a back-end game server. I'd say the same goes for the network client layer, but the language interop story is not ideal.
Check their developer channel on YouTube.
The garbage collector has not been an issue, because I use memory the same way as if I were doing it in the C language: Allocate all memory used by the game at program launch. I find this scheme easier to work with in Go than in C, because Go's slice type is a natural fit for partitioning these launch-allocated blocks of memory (as they get used and reused during the game).
The garbage collector doesn't get called if you don't allocate. And for the most part¹, it's easy to reason about where Go allocates (if you know C). So my rule is: Always know where your memory is; never allocate.
This may sound like it's going against the grain of Go, but I find Go to be handily amenable to this style. I had my concerns going in, but it just hasn't been a problem. My game runs silky smooth.
At this point, my only concern about using Go to make a game is that bringing the game to consoles does not have a well-trodden path.
¹ So far, the only thing that has surprised me is that assigning a value type (like an int) to an interface allocates! (So another rule is to only assign pointers to interfaces [pointers to memory allocated at launch].) And while this was a surprise to me, I was pleased with how quick the debugging went: I noticed frames were dropping, so I ran go's pprof tool, which led me directly to the (freshly coded) interface assignment that was stealth allocating. (Also, this allocation becomes less surprising the more I think about how interfaces are implemented.)
One neat thing that Go has is built-in benchmarking (part of the built-in test package) which shows you allocations per-invocation making it easy to spot the functions which need more work.
I’ve heard this a lot and even parroted it myself, but in all honesty I would be surprised if this is true today. First, GC does not mean “no control at all” over GC pauses. Secondly, GC pauses are incredibly short in some languages, unless you have to deallocate a lot.
Without first-hand experience, I would assume that GC is not an issue for games today, given that you are aware of how allocations work, and you have access to a good profiler if necessary.
As usual, the best language is most likely the one with the best ecosystem (libs, tooling, docs) around the domain that you’re working in.
Also, you might be able to toggle the GC off, and invoke manually with runtime.GC() at opportune moments.
I am a huge Go fan and I figured this out working on the raytracer in a weekend project using Go.
It took me a week or so.
Now that I know what is going on I could do it in a couple days with additional libraries. I didnt use the popular Go vector library.
Goroutines and channels make it very straightforward to set up an ECS engine hence you can actually run a lot of the engine in parallel and not have to stick to the "game loop" structure. Build your systems similar to the actor model with a mailbox, have an event/messaging bus, and you basically have a very performant engine.
I've yet to run into issues with the GC. The only bit of tuning I had to do was be careful with interfaces in hot paths and batch all graphics calls.
Consider options and research properly before choosing tech.
In the case of ebiten + golang, you will suffer greatly from the FFI overhead when calling external graphics API:s.
That doesn't track, given the sources at the beginning. One person wrote the essay, then somebody else started hosting it at that URL. There doesn't seem to be a direct connection between the writer and the URL at all.
Some games have been shiped on that engine, even running on the Nintendo switch.
FFI .... IS ... SLOW ....
It's not really a popular tool for the job: Python, which is a simpler language, has a much larger community of gamedev noobs. Or maybe better yet: start with Godot and GDScript
I'd say using any language for game development should be embraced, not discouraged.
Imagine if William Crowther had thought, "Why Fortran for game development? The purpose of the language is to tackle scientific computing." Thankfully, he did not think like that.
All Crowther had with him was PDP-10, Fortran, a teletype that probably looked like https://en.wikipedia.org/wiki/File:ASR-33_at_CHM.agr.jpg, some sheets of paper, and a sense of fun! Without being bothered about what these tools were really meant for, he went ahead and developed Colossal Cave Adventure thereby introducing the genre of text-based adventure games into the field of computing. A player had to type their input into the teletypewriter and wait for the computer to print the output on, well, physical paper! Still it was fun. It is nice to have fun and write games with whatever technology we have got.
This seems crazy to me. How so?
...because python has changed in the last decade so that anything ever so slightly complex requires learning all it's dependency manager manager setups (conda, pyenv, etc) to set up an entire custom python implementation with it's own dependency manager (pip, whatever, etc) just to be able to run a single python application or use a python lib. Trying to do it with the actual python your system runs will always end in tragedy.
So yeah... Python is a simple language. But using python these days is so complex I actually chose C++ over it to avoid complexity. And that's really saying something. That said, there's no such thing as system 'go' at all so it brings in plenty of complexity too despite being 'simple' in it's own way.
Go is a powerful, accessible language. It yields highly optimized, tight binary output targeting a wide variety of platforms and systems. Why not Go?
Python is basically a non-starter in this space. Your other example is a scripting language inside an engine. These seem orthogonal.
* - Which is oft heavily editorialized and fictitious, such as in this case
I am the developer of Astral Divide, which is entirely written in Go: https://store.steampowered.com/app/2597060/Astral_Divide/
When I started two years ago, I basically had to choose a language and a package/framework, so I'd like to share my experience about it.
First, about the package, there are two major ones for 2D games, which are Ebiten(gine) and Pixel.
I initially chose Pixel, because it seemed more documented at the time and had a bigger community. Overall, it was good as long as the game was simple, but unfortunately I regretted this choice later.
Don't get me wrong, I am not here to discredit the author, because there is a phenomenal amount of open source work that was done, and I am thankful for it. But as my game grew more complex, the engine started to cause big architectural challenges, memory leaks (it does not correctly garbage collect OpenGL's objects for example), and it's multi-threading model is flawed. I also discovered that it was in fact not maintained. Overall it lacks too much maturity for a serious game.
In the end, I decided to ditch it, because it was easier, and my proposals for help on GitHub never got any answer. It took some effort, but having my own engine based on OpenGL was the best choice in this case.
When it comes to Ebiten, I have only used the sound library called Oto, but overall my opinion of the whole package now is that it is well maintained and architected.
Now when it comes to choosing a language, I hesitated between:
- Go, which I had a lot of experience with and seemed good enough, even if the typing system is a bit too weak
- Rust, which I was (and still is) interested in, but had no experience, and unsure if it was worth it in terms of productivity (because of the additional time spent on worrying code, and the compilation time itself). Also, it didn't have game engines which seemed as mature as in Go at this time (I wish I had known that I would end-up with my own engine).
- C++, which is the industry standard, but on which I have very limited experience. Also, I just didn't want to bother with the header files and the compilation stack.
I chose Go, and too be honest it is a choice that I now regret, but also I have to live with it because I cannot afford a rewrite at this point.
Go certainly had a lot of productivity benefits, but also major flaws when it comes to game development:
- The lack of packages related to data structures. In games, we need a lot of specific sets, trees, queues, tries and maps, but those are almost non existent in Go. The best one is "gods", which still does not support generics. Overall it is always difficult to find quality and experienced packages, even for broadly used and fundamental algorithms.
- The fact that dependency cycles are handled on a package basis, and not per-class or per-file. This is a major source of headaches for video games, because contrarily to web servers, there are not a limited number of predefined layers: everything needs to depend on almost everything else, and Go makes it even worse in this case.
- The lack of data structures is made even worse by the native map, because it forcefully randomizes the iteration order, which causes a lot of bugs and makes it unusable 90% of the time. The authors wanted to prevent people from using it as if the key order was guaranteed, but their fix also broke the natural consistency of iteration order. This means for example that the drawing order of objects is different every frame, even when the data didn't change at all.
- When it comes to modding, there are not much options, because Go does not have a very easy or natural compatibility with FFI (cgo is awkward to use, and not really usable with dynamic linking), the native plugin package is experimental (and not even working in windows), and the support for WebAssembly is still quite poor (but getting better).
Your game looks great, congrats on your progress! I especially enjoyed how the zoom works when you're leaving/arrive planets, and the unique propulsion system (also, the anchor made me giggle!).
> lack of data structure packages
I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not.
> package structure not suited for games
I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seems to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their architecture?
> maps are random when iterated
Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630) issues. You should probably be using a b-tree if you aren't willing to sort it yourself.
> modding options
If you don't care about unloading https://github.com/pkujhd/goloader
Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero
It also has a bunch of libraries for embedding scripting languages https://awesome-go.com/embeddable-scripting-languages, with Tengo _probably_ being the quickest https://github.com/d5/tengo
I'd _highly_ recommend Ebitengine in the future, as not only have there been multiple brilliant games using it, but it also has Switch/Android/iOS support, and you can find help with any issue whatsoever in their Discord. People have even built 3D games with it, and Hajime is an absolute beast of a developer.
Thank you. Feedbacks are very much appreciated. There is still a long was until an eventual release, but it's very fun to work on it.
> I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not.
I had trouble finding basic structures like sets or linked lists, as much as more specific ones like R-tree, M-tree, KD-tree quad-tree or specific kinds of tries.
When quickly searching on Google, there are pretty much always some results, but when looking at the details it's not that great. Most of the packages have some kind of flaw that was a deal-breaker for me. Most common ones are:
- The package is something developed by one guy 4 years ago, and has pretty much no stars and is abandoned
- The structure is somehow backed by the native `map`, meaning that it has the same randomized iteration order
- There is some kind of logic to try to handle multi-threading, mixed-up with the data structure's logic. Often with mutexes/locks, thus killing the performance. My game is pretty much only mono-thread, and I just need something simple and that does not care about synchronization.
- The structure is not generic, but only uses `interface{}`
- The structure lacks tests or have unreadable code made of 1-letter variables
> I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seems to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their architecture?
Thanks for the reference. After looking at it, is seems to me that they are creating really tiny packages made of one or two files. I don't want my codebase to end-up with thousands of 1-file packages, it does not seem very maintainable. I want to keep having packages with clearly defined purposes and domains.
> Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630) issues. You should probably be using a b-tree if you aren't willing to sort it yourself.
I think that you didn't understand my message (or I didn't explain clearly enough). I do not need the items to be sorted, I need the iteration order to be consistent.
Let's say that I insert A, B and C in a map, then want to iterate on it. I will get an unspecified order, maybe ABC, maybe CBA, maybe BAC, which does not matter to me. However, in any language, this order will be consistent across all future iterations unless the data is changed. This is a natural property of any data structure. So if I got CBA in the first loop, I will also get CBA in the second and third loops.
In golang this is not the case because they actively inserted a random order. It means that even if the data does not change, I may get CBA in the first iteration, but BAC in the second, then ABC... Which created a ton of issues for me.
> If you don't care about unloading https://github.com/pkujhd/goloader > > Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero > > It also has a bunch of libraries for embedding scripting languages https://awesome-go.com/embeddable-scripting-languages, with Tengo _probably_ being the quickest https://github.com/d5/tengo
Yes, I noticed those packages recently. The problem is that there is little data about how reliable and maintainable goloader is going to be on the long term.
As I care about performance and security, I don't want a scripting language, but WASM seems to be a very promising possibility. I have made benchmarks with 2~3 WASM engines in Go, and so far I am not completely convinced about the quality and performance of the available APIs. Also, when compiling Golang to WASM, the native compiler is still abysmally bad and does not have full support for imports, so Tinygo is a must-have.
Anyway, modding is still a long term idea at this point, so hopefully the ecosystem will get more mature within a couple of years.
Currently the one with best WebGPU support.
Also, shaders are a thing in 2D games.
Personally I tend to use raylib-go much more, as it can readily supports 3D and has a strong community around it.
Here's a good summary, I think I'll link it in my post: https://ebitencookbook.vercel.app/blog/2022/04/16/TPS
It is quite possible to write simple games without using any external JS libraries by sticking to first principles only, e.g., drawing simple shapes with fillRect(), simple collision detection algorithms, generating simple tones using OscillatorNode, etc. Here is one such game I wrote sometime back: https://susam.net/invaders.html
Also, if the entire game is written as a single HTML file, the game becomes immediately distributable too. All one needs to do is host the HTML file somewhere or send the file to someone in order to share the game.
Example: https://loz.payload.app/
We just need make web assembly better for higher level languages, because neither javascript not rust are an end-all great language for small games.
The web browser gives you a rich collection of things you need out of the box and fairly "cross platform" by nature. You get things like graphics, audio, networking, debugging utilities, access to webgl / webgpu, etc.
As much as I hate to admit it.. it seems the web is far more suited for it than Go. I'm sure the game dev purists out there are pointing and laughing at the idea though :)