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.
Game Development in Go
31–40 of 60 posts
Re: Game Development in Go
#32My 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…
I'm curious, what frameworks do you use in JavaScript? Do you have any suggestions for getting started?
Re: Game Development in Go
#33Earlier quoted context omitted.
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 g…
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 ga…
Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtooth" pattern, because you generate garbage until hitting a fixed ceiling threshold, collect it all, then wash, rinse, repeat. But a game that's not completely pegging the CPU will have some idle time that can be used for small collections, so limiting the amount of garbage produced on each frame should put an upper bound on the amount of work done during each frame.
When I was helping Rovio port Angry Birds to the web a few years ago, we ran into serious frame hitches that were being triggered by GC pauses in Chrome. Two things fixed this -- the first was fixing a bug that caused it to run a full mark/sweep far too aggressively; but the second was when V8 committed an incremental collector (not concurrent, just able to spread the work out more by being able to run a partial mark/sweep and resume it later). After that, the GC pauses disappeared into tiny ~N00µs pauses that never impacted the game.
Re: Game Development in Go
#34Interesting article, and I'm glad to see some progress has been made. I look forward to the repo when its available.
Re: Game Development in Go
#35When 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 superficia…
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 :)
Re: Game Development in Go
#36I 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
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
Re: Game Development in Go
#37My 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…
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 g…
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.
Re: Game Development in Go
#38My 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…
I'm curious, what frameworks do you use in JavaScript? Do you have any suggestions for getting started?
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.
Re: Game Development in Go
#39Earlier quoted context omitted.
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 ga…
Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtooth" pattern, because you generate garbage until hitting a fixed ceiling threshold, collect it all, then wash, rinse, repeat. But a game that's not completely pegging the CPU will have so…
> but the second was when V8 committed an incremental collector
Did the chrome developers have to fix v8 for that one?
Re: Game Development in Go
#40Earlier quoted context omitted.
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 ga…
Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtooth" pattern, because you generate garbage until hitting a fixed ceiling threshold, collect it all, then wash, rinse, repeat. But a game that's not completely pegging the CPU will have so…
Right now Go uses the naive heuristic you describe, there's no concurrent or incremental collection so no matter how long it takes to get to the GC it'll be a stop-the-world collection and potentially take a long time. I forgot to mention that besides reducing the amount of on-heap data you can also speed up collections in the current GC by lowering the GC threshold (SetGCPercent). This does come at the cost of collecting more often though so it's only really helpful if you're generating a lot of garbage on a relatively small heap. The impression I get is that for Angry Birds you would be fine with the 1.4 GC but Sim City might have some issues.
https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...
Go might eventually get a generational GC but my understanding is that that pretty much requires a copying GC and there are concerns with C interop (right now you can point to Go memory from C).