Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game Development in Go

j15r.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Game Development in Go

#11

Post by lloeki »

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

Re: Game Development in Go

#12

Post by rudolf0 »

falcolas wrote: post #9
zamalek wrote: post #8

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.

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…

> 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?

Re: Game Development in Go

#13

Post by rudolf0 »

thecatspaw wrote: post #7
Thaxll wrote: post #5

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

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

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-...

Re: Game Development in Go

#14

Post by zamalek »

falcolas wrote: post #9
zamalek wrote: post #8

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.

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…

> 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).

Re: Game Development in Go

#15

Post by eropple »

thecatspaw wrote: post #7
Thaxll wrote: post #5

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

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

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.

Re: Game Development in Go

#16

Post by falcolas »

rudolf0 wrote: post #12
falcolas wrote: post #9

Earlier quoted context omitted.

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…

> 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 kno…

I'm afraid not; I found this originally on a blog which specialized in lockfree concurrency, and adapted it for use in my Go programs.

EDIT: The gist of the non-go formula was to have an array of fixed size character buffers, with a next-write pointer into that array. To write, you copy the pointer and use CAS to increment the next-write pointer (taking care to wrap at the end of the array), and write your data. If you have a particularly small buffer, you may have to be concerned about two threads writing to the same location due to the buffer wrapping, but it could be resolved with other mechanisms (or the buffer size increased).

Thanks to the Go `sync/atomic` package, you could implement the same thing, or just set up a goroutine which just reads from a channel into that ring buffer.

Re: Game Development in Go

#17

Post by falcolas »

zamalek wrote: post #14
falcolas wrote: post #9

Earlier quoted context omitted.

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…

> 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 ( ga…

All that makes sense to me. That said, thanks to goroutines and channels, you can be writing out that firehose and not have to worry too much about loosing your 60 FPS (with caveats, of course, but with buffering you can do, say, 6000 log writes a second and not have to worry about overwhelming your disks too much).

> and pray that it is still there, 60 times a second is 60 times a second

Great thing about memory, most gaming and development machines have gobs of it. You could allocate upwards of 600mb to the ring buffer and not feel the pinch. That's a lot of data, especially if you want to get creative and store pointers in there to other large structures in memory (such as a copy of a texture or mesh).

Ultimately, though, I agree. Full GDB support would be better; logging like this is just a stopgap.

Re: Game Development in Go

#18

Post by joelgwebber »

zamalek wrote: post #8

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.

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.

Re: Game Development in Go

#19

Post by agmcleod »

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.

Re: Game Development in Go

#20

Post by sehugg »

eropple wrote: post #15
thecatspaw wrote: post #7

Earlier quoted context omitted.

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

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.

The JVM also has probably the most man-years of effort into GC optimization. One thing the CLR has going for it is value types, which make arrays-of-struct possible (instead of arrays-of-refs-to-objects). I assume Go supports this too.
Post reply on HN