44
\$\begingroup\$

Google's new Go language is still in its infancy, and it has yet to find widespread real-world use or support. Even so, it seems like a promising experiment, and I wonder if it could have a future in game development. I haven't been able to find much game-specific discussion of Go elsewhere, and figured a CW discussion may be appropriate.

Some thoughts:

  • According to golang.org, Go programs "run nearly as quickly as comparable C or C++ code"--quick enough?
  • Is Go's garbage collection well suited for games?
  • How much mental re-tooling is necessary to create games in the land of concurrent goroutines?
  • Go is frequently called a "systems"-level language, with server software given as an example. It's hard not to think of multiplayer game servers when hearing this.

Your thoughts?

| improve this question | |
\$\endgroup\$
  • 1
    \$\begingroup\$ I would advise anyone not familiar with GO to actually follow the link before answering as opposed to just responding based on the given "thoughts" that being said if your answer is generic and not specific to this language then i guess it doesn't matter \$\endgroup\$ – lathomas64 Sep 15 '10 at 16:36
  • 1
    \$\begingroup\$ I wonder if you can make games in go (the game) :P \$\endgroup\$ – RCIX Sep 16 '10 at 7:02
  • 4
    \$\begingroup\$ Not sure if 'Go' is considered turning complete (then again it's human operated). But the storage space is very limited (at least if using a regulation board). \$\endgroup\$ – David C. Bishop Jan 22 '12 at 6:18
  • \$\begingroup\$ @DavidC.Bishop Funny... \$\endgroup\$ – Brian Ortiz Dec 16 '12 at 19:14
  • 1
    \$\begingroup\$ If you make a go game engine you should make sure you take advantage of what the language can do, instead of trying to use it in the same way you would with a more "conventional" language and copying what already exists. \$\endgroup\$ – user41958 Feb 9 '14 at 12:46
35
\$\begingroup\$

My take on your questions:

  • The language is plenty quick enough. The slower Java language is used for game development. Even Python (pygame) is used for game development, and it's significantly slower than Java. It all depends on the type of game and how processor-intensive it is.
  • Garbage collection in general is not very good for games. However, Go has a particularly bad garbage collection system (mark-and-sweep) which stops the world while it cleans up stuff. It'll be difficult to cope with and will cause something of a stop-and-go framerate.
  • A decent amount of mental retooling is necessary to create games with goroutines. Graphics and logic can't be concurrent in the traditional sense; but at a smaller level, parts of the logic are great candidates for concurrent goroutines (e.g. parallel processing of AI decisions, particle systems, etc.)
  • A multiplayer game server may indeed be a great candidate for the Go language.

In my opinion, if you have a strong enough urge to try writing games with a language, go for it. Obviously if you're considering it then you have a passion to do so, and why not follow that passion instead of forcing yourself to conform to the norm? I could say a lot more but I've already said a lot in my answer the question, "Is Ruby a suitable language for game development?"

| improve this answer | |
\$\endgroup\$
  • 6
    \$\begingroup\$ "a particularly bad garbage collection system (mark-and-sweep)" mark-and-sweep does not inherently stop the world - Java has a concurrent mark-and-sweep collector for example, and Lua used a naive one for a long time - and a lot of the length of the pause can be controlled via a careful generational system. That being said, Go's is stop-the-world mark-and-sweep. But the former, not the latter, is the issue for games. (The Ruby thread had some weird claims about this too.) \$\endgroup\$ – user744 Sep 15 '10 at 15:02
  • 1
    \$\begingroup\$ The current Go GC system seems to be something of a placeholder: "The current implementation is a plain mark-and-sweep collector but a replacement is in the works" (golang.org/doc/go_lang_faq.html#garbage_collection). Replacement options have been discussed; I'm not aware of any firm decisions on the matter. \$\endgroup\$ – TSomKes Sep 15 '10 at 21:34
  • 1
    \$\begingroup\$ Joe, thanks for clarifying! I wasn't aware of that. And yeah TSomKes, I did see that, so we can keep our hopes up that Go will implement a better garbage collector at some point. \$\endgroup\$ – Ricket Sep 16 '10 at 1:50
  • 4
    \$\begingroup\$ Note that the above answer is out of date when it comes to the current Go garbage collector. It's a whole different ball game with Go 1.5. I wonder how much of a concern this still is. \$\endgroup\$ – Jonas Oct 14 '15 at 19:23
  • 3
    \$\begingroup\$ And it seems with go 1.8, the GC will be reduced to 100μs of concurrent stop-the-world. groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8 \$\endgroup\$ – Dolanor Oct 29 '16 at 22:07
18
\$\begingroup\$

I've written a small engine in Go for OSX (using OpenGl for the graphics window). I have some experience with C++ game engines (http://morganjeff.weebly.com/) and decided to try out Go after reading about some of the features it offers.

As of the Go 1.1 release go has support for most of the features I needed to write a game engine (really a game core as an engine suggests editors and what not) including:

  • Member function binding (for the messaging system)
  • Reflection is built-in (useful for serialization, external tool support, etc)
  • Interfaces (for implement polymorphic behavior for systems, components, etc)

Some of the benefits to using Go (for a large project):

  • Testing is built into the language (this includes benchmark tests and some assertions)
  • Examples are easy to add to the language (and they are compiled for correctness)
  • Architecture specific code is easy to add (through file naming conventions)
  • Profiling is built in to the language
  • built-in versioning of imports (allows for adding large binaries to a separate repository from the source, while keeping it versioned and up to date)

Some benefits of using Go in general:

  • Easy to refactor code
  • Go supports threading (unlike C++ which layered it on top)
  • super fast compilation speed reduces the need for scripting language support
  • static typing system (interfaces are satisfied via duck typing aka implicitly)
  • multiple return values, named parameters, tagged struct attributes
  • great built-in tools and documentation
  • managed language

Some downsides of using Go:

  • No macros or templates
  • Doesn't have the library support of more mature languages
  • managed language (listed twice on purpose)
  • NO IDE

There are ways to get raw memory in go (import "unsafe") and I'll link an article that shows how a go program can be profiled for memory and speed. All in all, Go's claim that it's a modern C seems very true. I think it's "smartly" designed (for a lot more reasons than I mentioned) and, more importantly, it's well documented. An engine designed in Go is going to be a little different than an engine designed in C++ (something I'm still getting used to), but the Go engine solves a lot of problems that aren't really solved in C++ (namely parallelism, the complexity of C++s language, and the mis-use of inheritance).

Here's the article I promised: http://blog.golang.org/2011/06/profiling-go-programs.html

-Jeff

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ try out Sublime with GoSublime, it really feels like an IDE, and it is much more reactive than many(if not all) IDEs for Java. \$\endgroup\$ – Arne Sep 6 '13 at 9:02
  • 1
    \$\begingroup\$ can you specify what you mean by "built-in versioning of imports", I'm only awarye of the version tag of the go language itself. \$\endgroup\$ – Arne Sep 24 '13 at 21:33
  • \$\begingroup\$ @jmorgan any perspective changes since Go 1.2 and seeing the Go 1.3 upcoming changes? \$\endgroup\$ – ylluminate Jan 25 '14 at 22:17
  • \$\begingroup\$ @Arne: Good call! I really do like GoSublime, a lot. What I meant for no IDE is that to get a visual debugger you have to use gogdb (which is a great tool), but it isn't as nice as visual studio. Here's what I meant about package dependencies and versioning: golang.org/cmd/go/… golang.org/cmd/go/#hdr-Import_path_syntax \$\endgroup\$ – jmorgan Feb 14 '14 at 0:17
  • 1
    \$\begingroup\$ GO has IDEA GoLand IDE :) \$\endgroup\$ – STEEL Oct 25 '18 at 3:56
4
\$\begingroup\$

Something else to think about is that since Go is still relatively new, there may not be bindings for a lot of the common libraries used in game development yet.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Definitely the case. For example, I've come across two Go/SDL projects, one of which seems to have been abandoned. I've found a bare handful of (relatively small) games that use either of them. \$\endgroup\$ – TSomKes Sep 16 '10 at 17:11
  • 1
    \$\begingroup\$ You should definitely check out github.com/go-gl it's not SDL but a good alternative if you use OpenGl. For vectors there is github.com/Jragonmiris/mathgl, but I found bugs there. Go makes is super easy to wrap C libraries, there is no need for makefiles at all. You can also import C header files and use their functions directly. \$\endgroup\$ – Arne Sep 6 '13 at 8:58
0
\$\begingroup\$

Do not use Go to develop a game, it will just be an albatross around your neck. The toolchain for game development extends so much deeper than just the language that you write things in that you're going to find obstacles at every turn that just won't be there if you just go with something established.

Don't get me wrong, I love playing with new languages, but if you are trying to make games pick a language that has a community and support and you will be much better off.

| improve this answer | |
\$\endgroup\$
  • 9
    \$\begingroup\$ On the other hand, if you're just going to hardcode stuff on a small indie project to play with a new language, worrying about the "toolchain" is overrated. \$\endgroup\$ – user744 Sep 17 '10 at 9:57
  • 2
    \$\begingroup\$ I have to disagree here. Most stuff related to game development has nothing to do with the language. Asking questions about OpenGL has nothing to do weather you program in C C++ Go or even Java. And by the way what toolchain are you talking about? And why should it be incompatible to go? \$\endgroup\$ – Arne Feb 15 '14 at 13:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.