Hacker News Reader

Comment by mysterydip | Hacker News Reader

Agreed. The number of times I've read "don't worry, this doesn't change anything" in the press release of an acquisition is too many to count, and the number of times it's been true has been close to zero.

View on HN

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)

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

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

Hey, I resemble that remark :-(

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

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.

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

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

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

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.

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

Yes, but it wasn't EA who did the purchase.

Reply on news.ycombinator.com