Hacker News Reader

Comment by edoo | Hacker News Reader

Most industry game dev is also done on top of C++ engines and libraries. I can see Go being used in the near future as the big engines offer bindings but I bet in 5-10 years the average startup is using something like C#. It is slow as beans but eventually CPU speed will make it much more reasonable for real use. The Unity engine is a good example. It has a weird easy powerful super bloated paradigm.

View on HN

You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead.

Rust? I don't see it either.

A big part of this is ecosystem. You have so many game libraries and software that are written in C and C++. To many gamedevs, Rust is just a systems language Go. It doesn't bring anything significant to the table compared to just using a limited subset of C++.

The big game mills don't care about languages, they care about the bottom line. If you can churn out the same quality product with more junior engineers because the language is less difficult to master it is going to happen rather soon.

His point is that many studios nowadays use an established engine and do not develop in the C++-from-scratch-style. Especially smaller studios do not have the capacity for this and also depend much more on cross-platform availability to generate more sales. So they use Unity or stuff like Gamemaker Studio and use whatever binding is available (C#/Boo/Js for Unity, Gamemaker Studio has its own language). Or they even turn to something more exotic, like Haxe/Heaps.

I see it in the sense of writing your game logic in Go using bindings for Unreal or one of the big ones. The real performance critical stuff will probably always be in C++. The popular game Rust (not language) uses Unity and the overall engine is pretty bad but it works and made them a fortune. By its nature it is incredibly extensible. You can mod it by dropping source files with hooks right into a directory without compiling anything. The ease of that kind of stuff draws people like crazy.

Garbage Collection is not per default something bad, even in game development, its a method of memory management, just like reference counting, or manual memory management.

If you are allocating memory in your renderloop, your likely doing it wrong. Allocation outside of this critical path, well, chose your poison.

GC will consume more memory, but likely to be faster when it comes to allocating and deallocating large amount of small blocks.

Reference counting, if you do it properly (to avoid thread starvation), is costly. Cheap atomic reference counting, involves a calculated risk that you may have threads hanging.

Manual memory management, well, we all know the cost of that :)

That being said, many many games are today developed with Unit which uses C# as its primary programming language.

Sure, you can. But then you need to manage when GC triggers. Because if you don't, you'll drop frames. And then the real choice is between C++ where there is (little) extra work getting RAII correct vs GC languages where you need to keep preventing GC up to a point where it's okay to freeze the universe.

There are plenty of predictable garbage collectors now days, Shenandoah for example, Azul's C4 implementation is completly pause-less and concurrent. ZGC provides very low pause times (1 ms)

A clever approach for VR that was used in Downward Spiral [1] (a Unity game) is to add a periodic eye blinking effect and trigger the GC on a black screen.

[1] http://www.3rdeyestudios.fi/downward-spiral-horus-station/

You can allocate stuff on the stack instead, or keep things in a game state.

You might want to stretch that estimate out. I'm running an Intel Core i5-3550 from 2012. Furthermore, I foresee no reason to upgrade in the next 4 years. The current i5 on userbenchmark.com's front page is the 9600k, which says it's ~53% faster than my 3550. 7 years later.

CPU performance is barely going anywhere. Developers should instead try to figure out how to do more with less growth.

GPUs are also overpriced, and playing older games and comparing them to new ones doesn't show great payoff. As far as I'm concerned, we've plateaued. Maybe going from a GTX 760 to a 1060 would give me a few more frames, but frankly, more often than not, the games are programmed like utter shit.

This. When you think about it, it's an exciting time to be a dev. We need to be clever at stuff and can't just expect next-generation CPUs to make coffee for us.

You should read http://lucasmeijer.com/posts/cpp_unity/

Reply on news.ycombinator.com