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

51–60 of 60 posts

Re: Game Development in Go

#51

Post by joelgwebber »

jblow wrote: post #45
FreezerburnV wrote: post #22

Earlier quoted context omitted.

I think it's worth it to note that "a sufficiently complicated game will spend a lot of time dealing with memory issues" applies to all games. The memory issues might just be different. Or they could be simpler. Most games (especially large ones) tend to end up with multiple ways of garbage collecting eventually, even if written in pure C++. And that isn't even taking into account cache coherency, NULL pointers, doub…

It's bad. The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing. In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there'…

Thanks for taking the time to comment, Jonathan.

This is why the approach I'm experimenting with is build something very much like a custom allocator in Go, for all values that are allocated in significant numbers. I'm hoping that this will take enough pressure off the GC that it will keep pauses below the threshold where they matter (see above for a caveat about needing a concurrent or incremental GC to avoid long, but less frequent pauses). For what it's worth, I'm not 100% certain that this approach will work well enough, but I'm hoping to get some data that we can use to debate this in more concrete terms.

If this does work well, awesome. If not... well, I'm still tinkering with Rust, but I found the type-parameter explosion off-putting enough that I decided to stick with Go for my first round of experiments. I'm curious how your experience with more limited (as I understand it, perhaps incorrectly) allocation annotations are working out in Jai. After all, I'm not dead set on using Go -- I just want to avoid writing C++ for hobby games if I can possibly avoid it :)

Re: Game Development in Go

#52

Post by pjmlp »

jblow wrote: post #50
pjmlp wrote: post #48

Earlier quoted context omitted.

> You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are. Only if you write your own memory allocator, otherwise relying on the compiler provided allocator is no different.

Which is why people who are serious about memory write their own allocators (or link preferred allocators with known behavior). It is an extremely common thing.

Sure, I wasn't disagreeing with you per se, as I am well aware of your nick.

Just mentioning the issue for other readers, as many think malloc/NEW/Allocate or whatever is called, is fast.

Re: Game Development in Go

#53

Post by ANTSANTS »

joelgwebber wrote: post #25
Thaxll wrote: post #5

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

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

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.

Re: Game Development in Go

#54

Post by tshannon »

joelgwebber wrote: post #18
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 difference…

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.

Re: Game Development in Go

#55

Post by joelgwebber »

ANTSANTS wrote: post #53
joelgwebber wrote: post #25

Earlier quoted context omitted.

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

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

C++ management can of course be workable with enough care. I worked on Chrome for a bit while at Google, and saw that it more or less holds together with enough reference counting and smart pointers. At the same time, it still requires a lot of care, and plenty of bugs have been caused by subtle mistakes in this kind of code (which is why Chrome uses a sandbox around the actual rendering engine, because it's far too complex to be trustworthy). But even Blink/Chrome is moving to a garbage collector (http://www.chromium.org/blink/blink-gc) for C++ objects because of all the memory management complexity.

What I'm hoping is that you can have a GC that allows you to avoid all these issues without having to be super-careful all the time, while mitigating the pause issue by reducing the garbage using pools and similar techniques. My hypothesis is that most of the little allocations that game engines perform are homogenous enough that moving them to pools will be fairly easy. And that this will be sufficient to avoid big pauses. But we'll see how it plays out in practice when I get some hard data on big scenes.

Finally, memory management isn't the only reason I'd prefer to avoid C++. I'm particularly sick of long compile times (they could really kill you on a big project like Chrome), and among other things I believe that Go's concurrency model will prove a big improvement over C threading.

Re: Game Development in Go

#56

Post by ANTSANTS »

joelgwebber wrote: post #55
ANTSANTS wrote: post #53

Earlier quoted context omitted.

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

C++ management can of course be workable with enough care. I worked on Chrome for a bit while at Google, and saw that it more or less holds together with enough reference counting and smart pointers. At the same time, it still requires a lot of care, and plenty of bugs have been caused by subtle mistakes in this kind of code (which is why Chrome uses a sandbox around the actual rendering engine, because it's far too…

Interesting, thanks. The idea that Chrome is moving to garbage collected C++ is... a bit surprising to me, though I suppose it makes some sense given their focus on security.

I can see why you'd want to get away from C++'s compile times, though they're a lot more manageable if you can avoid templates like the plague. Have you considered a coroutine library for C or C++? I'm using libco right now for my hobby game project and much like "goroutines" would, it's significantly improving the clarity of a lot of systems (though of course I don't get the "free" parallelism because it doesn't handle scheduling across threads or anything like that).

Re: Game Development in Go

#57

Post by joelgwebber »

ANTSANTS wrote: post #56
joelgwebber wrote: post #55

Earlier quoted context omitted.

C++ management can of course be workable with enough care. I worked on Chrome for a bit while at Google, and saw that it more or less holds together with enough reference counting and smart pointers. At the same time, it still requires a lot of care, and plenty of bugs have been caused by subtle mistakes in this kind of code (which is why Chrome uses a sandbox around the actual rendering engine, because it's far too…

Interesting, thanks. The idea that Chrome is moving to garbage collected C++ is... a bit surprising to me, though I suppose it makes some sense given their focus on security. I can see why you'd want to get away from C++'s compile times, though they're a lot more manageable if you can avoid templates like the plague. Have you considered a coroutine library for C or C++? I'm using libco right now for my hobby game pro…

To be precise, Blink is moving to a GC for stability (including avoiding leaks), but I don't believe it's for security -- the renderer remains sandboxed because it's effectively impossible to secure such a huge pile of C++ code. This presentation (which assumes a lot of familiarity with the WebKit/Blink smart pointers) goes into some interesting detail: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...

It includes particularly intriguing bits like "You can remove all on-stack RefPtr's. This is the biggest reason why Oilpan performs better than the current reference counting." I don't know whether that always holds true -- as of the middle of last year, I heard that they'd gotten to the point where most things perform roughly at parity, some worse, and some better. Keep in mind that this is an opt-in system -- if you don't use the smart pointers the GC knows about, it will ignore them (IOW, it's not some crazy conservative beast like the C++ Boehm collector). Also, my understanding is that, the vast majority of the time, Oilpan only runs when the event loop goes idle, which makes perfect sense for a browser, and has an obvious correlate in a game's simulation/rendering loop. I think they only walk the stack looking for pointers in rare cases.

It's not hard to imagine a hybrid world where you opt-in to GC'd pointers, but are free to use different allocators for performance-sensitive bits. This smells a little like Rust, but without the need to satisfy the lifetime checker thing.

Thanks for the pointer on libco. I'll definitely have a look at that. I've not written much C++ (apart from Chrome and a few odds and ends while at Google) in a long time, so it's quite probable I've missed some significant improvements on that front.

Re: Game Development in Go

#58

Post by sntran »

pjmlp wrote: post #49
joelgwebber wrote: post #25

Earlier quoted context omitted.

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

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

Do they have websites I can take a look?

Re: Game Development in Go

#59

Post by pjmlp »

sntran wrote: post #58
pjmlp wrote: post #49

Earlier quoted context omitted.

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

Do they have websites I can take a look?

Wooga is using Erlang

http://www.wooga.com/

http://www.gdcvault.com/play/1016648/Why-Erlang

EA uses it as well

https://github.com/Eonblast/Emysql

Blizzard / Activision / Demonware paper of Erlang

http://www.erlang-factory.com/upload/presentations/395/Erlan...

As for Java, Deep Silver FISHLABS is using it

http://www.makinggames.biz/features/the-backend-development-...

I have lost my Making Games magazines, so I cannot remember of the other names.

Re: Game Development in Go

#60

Post by 4ydx »

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.

Post reply on HN