Game Development in Go

http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go

by jaimeyap • 11 years ago

132 58 11 years ago

j15r.com

prottmann• 11 years ago

"Over Quota This application is temporarily over its serving quota. Please try again later."

Lol, last time i have seen such a message was ten years ago ;-)

joelgwebber13• 11 years ago

Damn, that was fast. Thought billing was enabled for that site, but I guess not. Fixed!

Edit: Or at least it should be. Might take a couple of minutes to clear up.

wsc981• 11 years ago

Currently the site is unreachable (for me at least). But here I've got a Coral Cache version of the content: http://www.j15r.com.nyud.net/blog/2015/01/25/Game_Developmen...

Thaxll• 11 years ago

I already asked here before but what is the status of the GC regarding real-time games? ( for a gameserver )

thecatspaw• 11 years ago

Minecraft seems to be doing okay. The key is to have many small GC pauses instead of few big pauses.

rudolf02• 11 years ago

Go is also completely overhauling their GC for the next release (1.5). See http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-...

eropple3• 11 years ago

Minecraft's also had a ton of time invested into racing the beam with regards to the JVM GC. Not disagreeing with the viability of it, I personally use the CLR because I'm comfortable with that tradeoff and doing my work there too, but it is worth noting that a sufficiently complicated game will spend a lot of time dealing with memory issues.

I'd use either the JVM or the CLR long before Go, though.

joelgwebber13• 11 years ago

Here's my take on GC in games, FWIW. I'd be very leery of using a VM with a garbage collector for the entirety of a game. They can be fine (and are extremely common) in embedded scripting languages, but it can be far too difficult to control the size of outlier pauses when everything on the heap is subject to GC. As mentioned elsewhere in this thread, the JVM GC has had an enormous amount of effort put into it, and it's still an issue that poses problems for Minecraft, et al.

I'm far from proving this assertion yet, but I believe that Go's memory model allows for a middle way that will avoid big GC pauses. As I touch on briefly in the original post, you can use Go's C-like value types and pointers to field/elements to avoid generating garbage for large numbers of homogenous objects (e.g., by implementing a simple pool allocator), just like you'd do in C[++] to avoid heap fragmentation.

I hope to get more actual data on how this works as I expand my prototype, and will do follow up posts as I learn more.

pjmlp5• 11 years ago

There are a few German studios using Erlang and JVM languages for their MMOs on the server side.

ANTSANTS2• 11 years ago

I think you're right about Go's memory model helping a lot when compared to e.g. a typical dynamic language, but I have to ask: if you're going to be using manual memory management techniques like object pools and avoiding heap allocation whenever possible, what exactly does a garbage collected language buy you? I'm more of a C guy myself, but presumably RAII with smart pointers in C++ would get you most of the productivity benefits of garbage collection for the parts of the code that "don't matter" with much more reliable soft-realtime guarantees, while providing you with much greater memory management controls and optimization opportunities for the parts that do, and having far superior debugging support to boot.

a-priori• 11 years ago

Java can be okay for soft real-time applications, like games, as long as you're very careful about the lifetime of your objects.

The most recent versions of Hotspot, the most common JVM, has two memory pools for (non-permanent) objects: young and tenured. Objects start off 'young'; when they survive a few collections they become 'tenured'. Young objects are collected with a minor collection, which can happen concurrently with your code and doesn't stop the world. Old objects are collected with a major collection, which does stop the world. If you're writing a game, then minor collections are okay, but you want to avoid major collections at all costs.

This means that it's okay to produce temporary objects that have very limited scopes; e.g., they're allocated while processing a frame/game step and are discarded immediately. It's also okay to produce objects that survive forever, because they won't become garbage. The problem comes in the middle, if you make objects that last a while (significant fractions of a second or longer) but eventually become garbage. They have a chance of becoming tenured, and will build up until they trigger a major collection. At that point your game will stall for a while.

The other thing you'd want to change is to tell the GC to optimize for a maximum pause time with `-XX:MaxGCPauseMillis=<nnn>` (by default it optimizes for throughput). For a game server, a maximum pause of something like 500ms would probably be unnoticeable by players.

More information:

http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gct...

karka91• 11 years ago

I was experimenting with the idea of learning game dev with golang but shortly after starting I realized that there's very little tooling for that and I'll probably drop that project midway. Needing to make my own engine/tools/bindings on every step drained all the enthusiasm.

Would love to see something like LÖVE made available for golang

MoOmer• 11 years ago

But, but, love + Lua is just beautiful. I've only messed around with it some, but it is really a thing of beauty.

Haxe is one of my biggest current interests, and Snokit + Luxe is looking better every day.

otikik• 11 years ago

Every language deserves LÖVE-like package. It is so good.

Programming a LÖVE-like lib is an excellent way of learning a language. I did a javascript one some time ago, and it worked very well. You can find it at https://github.com/kikito/luv.js

zamalek4• 11 years ago

Did you at all find that the printf methodology of debugging got in the way of the gamedev? I've been keeping an eye on Go, but have been hesitant to approach it seriously because of that debugging approach.

falcolas3• 11 years ago

I have worked with GDB and Go before; it's not intractable, just more difficult to interpret.

Printf frequently works very well for most debugging, especially server side. I use the regular logging module pointed at stdout instead of printf specifically, and increasing the debugging level works most of the time.

Its also nice that with a bit of metaprogramming and goroutines/channels, you can make log printing nearly free. I once saw a technique where you simply write your really detailed log messages to a ring buffer (using a lockfree algorithm), and spit them out when you fail. This is even easier to do in Go, since you can just send the messages over a channel and not have to worry about properly implementing a lock free algorithm, and spit them out in a `recover()` function surrounding your main (or look at them in GDB).

rudolf02• 11 years ago

once saw a technique where you simply write your really detailed log messages to a ring buffer (using a lockfree algorithm), and spit them out when you fail. This is even easier to do in Go, since you can just send the messages over a channel and not have to worry about properly implementing a lock free algorithm, and spit them out in a `recover()` function surrounding your main (or look at them in GDB).

Do you know of a library that facilitates this?

zamalek4• 11 years ago

I once saw a technique where you simply write your really detailed log messages to a ring buffer

While this is incredibly cool, my initial concern was mostly this:

I have worked with GDB and Go before; it's not intractable, just more difficult to interpret. Printf frequently works very well for most debugging, especially server side.

The thing about your non-niche dev is that, unless you are debugging prod (gasp), you can control the influx of data/output of data. E.g. If you want to debug a specific webpage you can simply hit that webpage in the browser yourself, and you are guaranteed to only see code executing that has to do with that request.

The problem with gamedev is that things are happening 60 times a second. There is a firehose of data and there is nothing you can do about that. Logging is definitely used, but it is more useful on client machines once you have actually shipped a working product.

I guess what you could do is force a fail once a condition is met, to access the last data in the ringbuffer (and pray that it is still there, 60 times a second is 60 times a second).

joelgwebber13• 11 years ago

I'll be honest -- I hate working without a debugger. Go's gdb support was never great, and the team appears to have decided it's a fool's errand. On the other hand, the Delve project looks like it's serious about building a "real" debugger for Go (https://news.ycombinator.com/item?id=8595407). Supposedly it works on Linux, but I'm waiting on Mac support, which I understand is held up on Linux/Mach/Darwin differences.

In the meantime, I've gotten pretty good at printf() debugging (I worked on embedded systems in a past life, so it's a skill I've had to develop). I'm also considering adding some more structured log/trace/metrics stuff (perhaps exposed via a simple web UI) that would allow me to escape the "tyranny of the ever-scrolling console".

But in the end, I'll consider Go dead for game development (at least for me) if the debugger situation doesn't get fixed. I'm just betting that it will.

tshannon• 11 years ago

In my hobby game programming, the first thing I got nailed down was writing messages to the screen.

Not as good as debugger, but invaluable when you need to see the specific value (position, etc) of an object right next to the object on screen.

I'd also usually have a key bound to spit out a frequently change buffer of debug information that I could call up at any time.

lloeki• 11 years ago

When I decided to take part in LD48 #29 (which was the first time I did a gamejam), I went with golang. I did some research beforehand on the language, a few basic libraries and got me back on track with OpenGL which I did not use for years (and only ever as a toy). I maintained a log[0] and fed twitter regularly about my progress.

To sum up I was 1) on the move, 2) in a new language, 3) in a domain I only superficially know. Not precisely the best conditions to say the least, but I managed to read and map keyboard and mouse input, draw sprites, animated water (screenshot missing), and (almost) working point physics. Were I not aiming for the realistic physics but some crude old skool implementation, I'd definitely have a (very basic) platform game out as the last screenshot.

So, even at the lowest levels and using a few techniques I gleaned from watching Notch's Twitch stream on LD48 #28 it was loads of fun and extremely productive, even without support libraries or a dedicated engine. Hint: binding a reload hack thingy[1] to cmd+R[2] was the best thing I did, being stubborn about the Real physics thing was the worst.

[0] https://github.com/lloeki/ld48-29/blob/master/log.mdown

[1] https://github.com/lloeki/ld48-29/blob/master/ld48-29.go#L31

[2] https://github.com/lloeki/ld48-29/blob/master/ld48-29.go#L65

joelgwebber13• 11 years ago

Nice work. Assuming my experiments convince me that writing games in Go is worthwhile, I'd love for the ecosystem to evolve to a point that it's trivially easy to get up and running. The fast iteration time is very nice for these competitions (now I just need a debugger).

I think it shouldn't be too much trouble to get to the point where we have a set of basic composable libraries for loading and rendering meshes and other graphics, as well as sound/input/etc. that doesn't require so much wiring. I haven't done the exercise yet, but I'm also hopeful that SWIG will provide good enough bindings to Bullet Physics, so that you won't stub your toe on "real physics" again :)

agmcleod4• 11 years ago

My concern with using go is definitely the GC. I mostly build games in Javascript, which has a nasty GC. But to invest in a new language, I feel like the gains need to be better than that. Java definitely has better perf than JS no doubt, and there's good tooling around it. But I'm happy working in the web space of things.

The only thing im considering looking at for gamedev is Rust, but i need to let that grow a bit first.

joelgwebber13• 11 years ago

See my comment elsewhere on this thread, about techniques for limiting garbage in Go. I'm far from proving that this is sufficient for avoiding significant GC pauses, but I'm tentatively hopeful. I'll post more as I get more data on large scenes.

I did play with Rust a bit, and I do find a lot to like there. Unfortunately, I quickly found myself dealing with an overwhelming explosion of type parameters (both of the garden variety, and the 'lifetime' variety). Some of this may have been my own naïveté in the language, and some bad library design (the graphics library I was using ended up forcing me to pollute nearly every type with three or for type parameters). But that, coupled with my own Go experience, a slow-ish (though better than C++) compiler, and no better debugging support than Go, led me to stick with the latter for the time being.

hedgehog2• 11 years ago

Generating garbage slowly will reduce the frequency of collections but it won't reduce the amount of time each individual collection takes. If you need to reduce collection times then reduce the amount of data that the garbage collector needs to traverse each time, that is move some of your data off-heap. The concurrent GC in 1.5 should help as long as the STW deadline can be reduced enough (10ms is too long for a game) but going to a generational algorithm may be necessary to get GC overhead as low as you'd want.

agmcleod4• 11 years ago

Oh god yeah, the system in rust really got me infuriated a few times lol. But it was at the same time very satisfying to fix things and figure it out. I think it's a neat language, but I am going to wait to use it seriously.

I do want to learn Go at some point though, as i'd like to do some web back end experiments with it.

swsieber• 11 years ago

I'm curious, what frameworks do you use in JavaScript? Do you have any suggestions for getting started?

agmcleod4• 11 years ago

I use MelonJS personally. Phaser is also pretty good, quite a bit bigger in size. That's for 2d. If you want to look at 3d, checkout three.js or babylonjs. I find three.js has a larger community, and is easier to find stuff on stack overflow. But i had issues with PhysiJS plugin performance on mobile. Babylon's physics works pretty well.

pjmlp5• 11 years ago

Unity is really making a disservice to games development in safer languages by bundling that prehistoric Mono runtime.

Anyone that isn't aware of that will assume C# in Unity == other runtimes.

niix• 11 years ago

Interesting article, and I'm glad to see some progress has been made. I look forward to the repo when its available.

mseepgood• 11 years ago

There are also these debugging tools in the works: https://github.com/golang/debug

4ydx• 11 years ago

I have also been developing something in my free time with go-gl. The GC issue does bother me conceptually, but I have yet to make anything so complex that stop-the-world GC makes me curse the screen. I tried writing something minecraft-like in c and then c++ a couple of years ago, disregarding the fact that I don't have deep professional experience in either, but I eventually hit a place where my confidence dropped off too precipitously. Considering that learning modern opengl/openal is at the forefront of my concerns, using a simple language that is compiled felt like a good fit. If I were to choose a different language, it would probably end up being C#.

Incidentally do you find that compiling is actually disappointingly slow? My current project takes about 2.5 seconds to build and that feels very long.

Game Development in Go

Related Stories