Go can absolutely be used for gamedev and has been since Go was released in 2012. While the number of golang gamedevs and game projects has slowly grown, I propose three explanations, philosophical, practical, and technical, to make Go gamedev more popular.
The philosophical explanation is perfectly presented in Rob Pike’s Less is exponentially more. A great article which answers why games should be developed using Go. All the reasons for creating Go, and all the benefits of Go, also apply to gamedev code.
Moreover, the key point of the article discusses why C++ [game engine] devs do not switch to Go, and it has to do with “Do you think less is more, or less is less?”
I think Go’s “less is more” view point would initially lead to the creation of high-value packages for the essential gamedev libraries. My own golang hobby engine1 is a wish list of the core functionality that I would love to see supported in pure Go, eg:
Overall my experience of creating small games in UnrealEngine and my own golang engine2 has reinforced my belief that the gamedev community would benefit tremendously from “less is exponentially more”.
The philosophical leads to the first practical consideration, and it is the need for core gamedev devs. These devs understand “less is exponentially more” and are supported by company $$$ to allow the creation and maintenance of the golang core gamedev packages. Every few years, like a gopher, I pop my head up and look around, but they seem to be absent. Historically, three devs are needed to get things going.
The second practical consideration is that coding can be a very small part of the total gamedev process. Go does not directly help with:
Even with code being a small part of overall game production there are substantial efforts being made to reduce coding effort by providing visual scripting languages like Blueprints in Unreal Engine. I argue here that Go is, by design, exactly what can help improve the gamedev code experience. Go for game code as well as game engines.
One of the challenges in creating the core gamedev packages is the technical issue
I’ve seen referred to as the golang impedance problem.
Currently many golang gamedev packages require cgo to interface
with non-golang libraries like:
I find wrapping C API’s with cgo frustrating. Frustrating to the point that
it is easier in the long term to port the essential parts of existing open source
libraries to Go packages. Another benefit of porting is that it can be selective
in the “less is exponentially more” sense.
Ideally there is no C compiler in the gamedev tech stack (I’m spoiled, I know, and don’t forget lazy).
Recently I reduced my game engine support to win64 which allowed me to replace cgo with syscalls.
Coding became noticeably more enjoyable once it was golang only.
My thinking is that the technical impedance problems are solvable. How much time and effort would need be clarified. For example, is it even possible to write a golang Vulkan API layer without wrappers? Probably? Does it make sense? Worth the effort? Heck yes! I would love it if a Vulkan golang package popped up one day.
Go game development is slowly growing but needs some core work to become a viable alternative for new gamedev coders. Existing technical issues can be solved with some practical time, effort, $$$ and the “less is exponentially more” passion. In the meantime golang gamedev as a hobby is fantastic!