Is size still an issue with Go if you wanted to compile to WASM and target the browser?
If the browser is the main target, I would just use browser native engines like Pixijs.
Making games in Go for absolute beginners
21–30 of 78 posts
Re: Making games in Go for absolute beginners
#22I always wondered if Go would be a good language to make a game in due to its concept of goroutines. Maybe one of these days I’ll give it a shot.
Unfortunately, garbage-collected languages have historically not been great for real-time action games. Throughput and performance can be excellent, but without control over the garbage collector pauses can wreck the experience. 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…
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.)
Re: Making games in Go for absolute beginners
#23Re: Making games in Go for absolute beginners
#24This is great. I feel it's missing something about delta time though.
Here's a good summary, I think I'll link it in my post: https://ebitencookbook.vercel.app/blog/2022/04/16/TPS
Re: Making games in Go for absolute beginners
#25Re: Making games in Go for absolute beginners
#26Re: Making games in Go for absolute beginners
#27Re: Making games in Go for absolute beginners
#28It 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.
Re: Making games in Go for absolute beginners
#29While ebiten is fun, it absolutely will be limiting for your larger project. 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.
Beware the factory factory factory. https://factoryfactoryfactory.net/
Re: Making games in Go for absolute beginners
#30Is size still an issue with Go if you wanted to compile to WASM and target the browser?