Currently, the situation about games and multimedia in Go is kind of not ideal. However, I think, that Go is an awesome language for doing these kinds of things! Why? Because it’s:
Reasonably fast.
Easy to make great APIs, due to interfaces, closures, methods, reflection, and so on.
Great to work with, when working with good libraries, feels like a scripting language.
So, I’d say, that Go is probably not (at least yet) an ideal language for AAA 3D game development, however, it’s very suitable for lower-budget 2D (or sometimes 3D) games.
However, if you want to start developing a 2D game in Go these days, you basically have these options:
SDL2 - first link in pastebin - these bindings give a full-featured access to SDL2, which provides graphics, audio and everything. However, SDL2 is C. And it feels like that in Go too.
OpenGL - second link in pastebin - for windowing use GLFW. Well, this is even harder to use than SDL2. Also, I haven’t found a way (so far) to do cross-platform audio in Go without SDL2.
Engo - third link in pastebin - enforces Entity-Component-System paradigm, which can be restrictive at times, and suffers the same issues as OpenGL: no cross-platform audio (doesn’t work on Windows).
So, as you can see, the situation is not great. Right now, I’m stuck with SDL2, I can deal with it, but the situation could be so much better.
How to solve this? I can see a few solutions:
Build an easy to use and powerful game library for Go on top of SDL2. (I started some work, you can find it here: fourth link in pastebin)
Make a cross-platform audio library for Go and then build a game library on top of OpenGL+GLFW+thatAudioLibrary.
Make a bindless native low-level graphics and audio library in Go and then build a user-friendly library on top of that.
Regarding the third option: guys at Rust have build a native bindless graphics API for Rust: fifth link in pastebin. Would it be possible in Go too?
Also, Go would be way more appealing to beginners, if it was easy to write games in it.
Currently the cleanest thing for writing beginner games I’ve seen is raylib. The whole approach should fit Go very well. Whether it’s a binding or rewritten from scratch, doesn’t matter as long as it works seamlessly.
Hello, I’m a core maintainer on Engo. @faiface I do agree that Go would be perfect for a 2D game engine. Speaking on behalf of engo and why we talked about SDL2 and chose to stay with OpenGL for the time being is that OpenGL is really portable, with little change I added in support for the web using WebGL, and Ettienne (another core maintainer) added in support for Android and soon we plan to support iOS. As for audio, we currently support linux, osx, web. It has crossed my mind to use gosdl for audio on desktop platforms or just windows. On the issue of ECS, I’m not the biggest fan of ECS but it pushed for a way to organize everything. I personally prefer a Cocos2D X style approach. We also are planning to remove ECS and make it optional so you can build other libraries on top of engo or games on top of engo as a library and not a game engine (https://github.com/EngoEngine/engo/issues/331). I personally want to explore building a game engine with a simple API most likely on top of engo because it already does the heavy lifting with: cross platform opengl bindings similar to goxjs, cross platform audio API (https://github.com/EngoEngine/audio) which currently does not support windows but is going to in the near future. It felt nice to get that out of my mind, once again thank you for bringing this up for discussion.
I’m developing Ebiten, which is a simple game engine. This has 2D graphics and audio libs and works on Linux, Mac, Windows, web browsers and mobiles (Android and iOS). I’d be happy if you could take a look at this.
@otraore I’d just like to say why specifically ECS didn’t suite me. I’m actually working on a game and as one of the alternatives, I tried Engo. The main problem was, that in my game, I need to have two copies of one world that are able to synchronize with each other, which I found to be very difficult to implement using Engo’s ECS (since there are pointers here and there, you don’t really know where, you have to study the source code of Engo, if you want to make a copy of a world, because implementation of Engo matters there). Another potential problem that I can see (I haven’t run into it, because I quickly switched to SDL2) is that it’s hard to optimize performance with ECS. It’s hard to lay your memory out as you need to and so on, avoid unnecessary iterations through entities and such. Of course, it’s possible, but it’s a bit of an overhead. In my game, it was necessary to do numerous performance optimizations so far, because I need to update the world ~50 times per frame (yes, I need to do that).
@hajimehoshi Hey, this library looks very functional (= is working) and quite well designed, I kinda like it. Could you just explain, how is it SNES-like? And how that differs from a “general-purpose graphics/audio library”?
This means Ebiten has a capability at least to perform SNES-like games which have features like raster scrolling, mosaic or color-changing for a sprite. Ebiten is well tested to develop a game in relatively low resolution (320x240) by me, and not in higher resolution. Ebiten should work also in such higher resolution, but performance could be problematic especially on web browsers.
The exact definition of SNES-like games is not clear (even to me), but when I consider what to add to Ebiten, I always think if this is required to perform actual SNES games.
IIUC general-purpose graphics library would have HTML Canvas-like API, but Ebiten has a minimum set of API to perform SNES-like games I mentioned above. For graphics, Ebiten can draws sprites but not shapes like arcs. For audio, Ebiten can play 2ch 16bit PCM sound, but not 5.1 surround or 3D positional audio like OpenAL.
Ok, thanks everyone for contributing to this discussion so far. You can still continue contributing and I’d be happy to see that.
I ended up with this decision: I’ll continue developing my own library Gogame (https://github.com/faiface/gogame) which uses SDL2 as it’s backend. Engo is nice, but still forces ECS (I may change my mind, once it gets “freed” from it) and Ebiten is nice, I may use it someday, but the game I’m working on right now is by no means SNES-like.
You can check out the Gogame library, it’s still small and not fully-featured yet, but will get bigger alongside my game. But I think it’s got a nice design and is really easy to use, even for an absolute beginner.
If you’ve got anything to say regarding game development with Go, continue posting.
I think it could make for an interesting blog post if someone were to write about the state of Go game libraries/engines (which engines are out there?, how well are they supported?, how popular are they?, what kinds of games are they good for?, etc).
The problem is not that Go isn’t suitable for games, it’s not perfect though, it’s suitable. The problem is the community doesn’t have their ■■■■ togheter. People don’t want to cooperate and 1 man is never enough to get anything done. A serious game developper would never consider Go as a good starting point because of that. Sure Go’s syntax is nice and the tools are great, but by using something else (eg. c++) they get ~20 years of tested, proved and robust utilities to build their games. No one can catch up to that on their own. 70 engines everywhere is just gonna lead to 70 engine that sorta work, but can’t rival anything.
@hydroflame I can’t really argue, because you’re right. However, we’re not completely out of libraries in Go. There is SDL2 bindings, and I’d say, that that’s reasonably enough for a single person to build a small game. And that’s what I’m doing. What I’m doing additionally, is open sourcing the technical parts of the game into the Gogame library, so that others can possibly find use of those. I’m doing it, because I found other higher-level libraries to be unsuitable for my needs.
But other than that, you’re correct, we can build a good game library for Go only if we work together, but I think, that the way to achieve it, is to build something reasonably useful and people will catch on. Maybe I’m wrong, I don’t know.
Ok I’m gonna skip over, for now, the assumption that c++ was a small language at the same time as game development was widespread. So because Go is a small community that gives us the right to be morons about it ? I don’t mind the “everybody did it so it’s ok to do it” attitude, I just want to know where you stand.
I gotta give extra brownie points to faiface for having some beautifully written go code though, kudos.
I’d rather be in the “everybody did it so it’s ok to do it” attitude. I admit there should be things we can cooperate in game libraries, but while we refer the libraries all as “game library”, there are a large variety of them.
There’s like 3 version of standard lib math for float32, there’s at least 8 vector/matrix library, I’ve seen 2 box2d lib and I’m pretty sure overall at least 6 2d physics libraries. We can count, just in this thread, 3 rendering lib for 2d and you all do the same thing.
11/10, A+ on the “everybody did it so it’s ok to do it” attitude.
FYI if the next newcomer also has that attitude he’s gonna start from scratch, again, and you cna add +1 to a couple of these.
They look different things to me. Actually they are same to some extent in terms of rendering 2D graphics, but they have different features and concepts. Just out of curiosity, how do you think they are same?
