11–20 of 78 posts
I 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.
I am a huge Go fan and I figured this out working on the raytracer in a weekend project using Go.
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...)
While 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.
I 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…
Is size still an issue with Go if you wanted to compile to WASM and target the browser?
Is size still an issue with Go if you wanted to compile to WASM and target the browser?
While 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/
Personally I tend to use raylib-go much more, as it can readily supports 3D and has a strong community around it.
I 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.
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.