Hacker News Reader

Comment by TylerE | Hacker News Reader

In this case it's probably a good thing.

Really, the thing to do is buy it for the name, and then start from scratch in an actually good game engine (i.e. not Unity)

View on HN

Give a man a game engine and he will write a game.

Give a man no game engine and he will write a game engine for the rest of his life.

- unknown GDC speaker

Hey, I resemble that remark :-(

Same here. At some point I had more abandoned game engines than actual games in playable state...

I didn't say write their own... but how about a proper multithreaded modern engine like Unreal?

Unity's actually great... the problem is anyone can use it.

Unity's great for small indie games. Complex simulations don't mix well with mandatory GC. Microstutters suck.

It's not that hard to work with the GC in Unity to make the game smooth, especially if you do so from the beginning. https://unity3d.com/learn/tutorials/topics/performance-optim...

How come no ones seem to do it then, or not do it well enough?

Cities:Skylines has the same GC stutters.

It's easy to fall into the trap of doing things the simple way or the unity way. To avoid it you have to go out of your way a bit and apply the same rigour as if you were writing your own engine.

Not making heap allocations in loops/Update and favoring object reuse really isn't comparable to writing your own engine.

I didn't say it was. I'm just saying that you can't allocate and instantiate all over the shop just because it's a GC language.

I've never encountered a stuttering issue in any Unity game I've played.

For a game engine, smooth performance is pretty much required. If you have to a) know that you have to worry about GC stutters (which beginners are unlikely to), and b) proactively do something about it, that seems like a major failing of a game engine. If I use a game engine, it's because I want to work on the game and avoid having to do things like manage the GC.

Besides, GC is one of those things that is classically unsuitable for real-time use cases, and games are exactly a real-time use case. So you could argue that Unity choosing a GC language was a predictably a bad decision. Again, I don't use a game engine because I want to put up with bad decisions.

All of the extra convenience and features afforded by using .NET are more than worth having to do a few simple things not to make the GC trigger at the wrong times. A game written by a beginner in any engine is going to have classes of errors that make it harder to keep using the same codebase over time. Compare the few simple suggestions (many of which like object reuse apply to C++ as well) in the article to the huge list of things not to do in C++.

If you're playing KSP, you can tame the stuttering with the MemGraph[0] mod. I don't know about other Unity-based games (nor do I even know of any other games that suffer from the issue). Also in my case they weren't microstutters, rather ~1-3 second pauses.

[0]http://forum.kerbalspaceprogram.com/index.php?/topic/139128-...

> in an actually good game engine (i.e. not Unity)

...and drop Linux support, of course.

/smh

https://wiki.unrealengine.com/Linux_Support

http://www.pcworld.com/article/2940175/cryteks-powerful-crye...

https://en.m.wikipedia.org/wiki/Source_(game_engine)#OS_X.2C...

UE4 even runs in a browser out of the box. Unity is not the Magic Linux Engine, it's just a bit more convenient because of .NET, particularly when it comes to modding.

Reply on news.ycombinator.com