Hacker News new | ask | show | jobs
by markatkinson 3790 days ago
I got pretty excited and rushed through the article trying to clarify what engine and language it is based on.

Got a little bleak when I saw CryEngine and C++. As someone who uses C# and Java it's becoming pretty clear I need to start learning C++ if I want to explore game dev.

I realize Unity uses C# but when I compare UE, Unity and CryEngine it really feels like Unity still has a long way to go. The features you get out the box with UE for example are far superior to Unity.

Anyway, I just went off topic. It looks like an interesting option for developing multiplayer focused games.

6 comments

Trust me when I say they all lack a fully polished end to end solution when it comes to authoring modern games.

Depending on the graphical fidelity you're chasing Unity is probably the most polished of the 3 majors.

UE4 is a great tool but has a slower development cycle.

CryEngine is almost broken unless you're willing to do a deep dive in the source.

If by "explore game dev" you mean, "make games" Unity or UE4 will serve you well. UE4 has a nexus of great artists using the tool so recruiting artists that are familiar with the toolset is easier. Unity is some multiple of more productive, pending your skill level with C#.

I've evaluated all 3, am a proficient programmer in C++ and C#(among others), and have shipped several games with Unity. I've also worked on a couple of shipped titles with UE4.(nothing major)

UE4's editor is also filled with bugs and inconveniences, and tooling and documentation for programming outside of Blueprints is haphazard at best. Crossing the C++/Blueprint boundary can be a pain, especially with interfaces. And the 2D support pales in comparison to Unity's.

On the other hand, Blueprints and the node-based material editor are really nice for quickly snapping content together.

That is great feedback, thanks.

Yea I think it is about time I gave Unity another go, and will set aside some time to go over some tutorials.

Depends on what you mean by "exploring game dev". I would say Unity is pretty perfect for that and you have a lot to learn before you will reach its limits, if ever. After all, some of the best and most successful games are made with Unity. If you want maximum eyecandy, then UE or CryEngine might make more sense, but even there Unity in its latest version is not that far off.
I'll check it out again, it was over a year ago.

I just recall doing things like setting up path finding and AI was much easier in UE and setting up player characters etc was all already built into UE templates.

The whole UE IDE or workflow also just made more sense to me, and was more polished. Maybe I just didn't give Unity enough of a chance.

Five years ago using C# for a serious game would get you laughed at. But every day the balance shifts: computers get faster, but developers don't get smarter, so a language that sacrifices performance for ease of development becomes a better choice. If you're looking to the future I'd recommend sticking with C#.
isnt the main problem with C#, Java and similars the garbage collector? which can at its worst kick in while you're in the middle of a fight or something. Even if its just 20ms, in a online FPS it potentially makes the difference between winning and loosing it.

edit: I am a Java guy myself, and would like to do some amateur gamedev in that direction (online FPS), but im worried about above mentioned point.

Yes. Explicit control of memory is one of the big reasons C++ wins for high performance realtime applications like games.
True as far as it goes. Modern GC can mostly be done concurrently (it's only heap compaction that requires stopping the world). Fully pauseless GC is very much possible (see e.g. Azul C4), as are e.g. architectures involving multiple short-lived processes with individual heaps. Even without that, it's often possible to do a relatively small amount of manual work to do the things that require pausing only at appropriate times.
Possible != usable in production.
C4 is absolutely a production product. It's used in systems that insane amounts of money depend on. As for the manual approach, I've seen it work in production.
Well, not everyone is writing the next version of Crysis.

There are plenty of production games that can live with < 10ms pauses.

It's not just the pauses though. Cities Skyline has terrible performance, far worse than other more-intensive 3D games, and I can't help but feel that their choice of game engine is a major reason behind that.
Modern C# allows you to define a code path where GC is not allowed to run. I'm not sure if unity allows for this.

I'm also not sure about the new c# -> to native compilers coming out.

Could you link to the feature you're talking about? Unity uses a relatively ancient version of Mono IIRC, so it's unlikely that the feature is available in Unity unless your definition of "modern C#" is "after generics were added".
Modern C# means .NET 4.6

For example GC.TryStartNoGCRegion

https://msdn.microsoft.com/en-us/library/dn906201%28v=vs.110...

SafeBuffers

https://msdn.microsoft.com/library/system.runtime.interopser...

Or using array segments

https://msdn.microsoft.com/en-us/library/9cc4bx8k(v=vs.110)....

Unity has made a lot to spread C# love among game devs, but it also gave a bad reputation to those unaware how .NET really is.

> If you're looking to the future I'd recommend sticking with C#.

Not really. If you look to the future, I'd recommend Rust for making game engines. They by nature should be latency sensitive, and any kind of non deterministic behavior caused by garbage collector is really unacceptable.

"Really unacceptable"? The literal hordes of games using Lua, JavaScript, and Python as game-logic languages seem pretty acceptable to me.

Rust is a nice language, but Unity already uses C++ outside of the user-facing scripting layer.

"computers get faster"

Not everywhere. Phones, tablets and older or low end laptops are very popular.

Phones are really quite fast these days. C# is a perfectly reasonable choice for a phone game.
C# is a perfectly reasonable choice for a phone game that can afford garbage collection pauses. This means turn-based.

In every other case, you're better off using a language whose resource management model doesn't fight you.

Swift is the best of both worlds in this regard.

Considering virtually every major mobile game is unity these days, is this really an issue?
Not at all. Memory management for games is something you have to pay close attention to, no matter what's your strategy for dealing with garbage. But this whole GC discussion is missing several years of technology development and best practices.

Besides, it is not guaranteed that you'll succeed with a manual strategy for dealing with garbage. Naive strategies have a really low throughput. They may not stop the world, but will be slow.

Unity is a C++ engine. Only the game code is done in C#.
And around 20 years ago using C for serious game development was also a joke.

Apparently we need to go through this cycle every few decades.

Yeah, especially when you consider Carmack basically volunteered to rewrite Minecraft in C++ for Microsoft (and VR use). I'm not a game developer so I have no idea if C++ is as widespread as it seems but to me that's a pretty big indication.
The rewrite had already taken place (the pocket version of Minecraft). He "just" tweaked the graphics pipeline to minimize latency using techniques such as asynchronous timewarp, optimize framerate and add the other VR related stuff.
Ah, I see. Thanks!
I spent some time going through tutorials for different game engines, UE, Unity, Chaos and researching others, it became pretty clear that C++ the most pervasive and valuable across them, which is probably obvious to some of the more involved players in that space.
I think it's become something of a chicken and egg problem. All the hard-core game developers moved up from assembly to C, then introduced bits of C++ in the late 90s. All the books and tutorials end up getting written in C++ (or C with classes...). APIs get written in C/C++. More people learn C++ because its what the game devs do, and it's harder to find resources on learning how to do it in any other language. It's usually possible to make a wrapper for C++ code in a managed language, but it's not easy, if somebody else hasn't made a good binding already.

Garbage-collection has a bad name for some reason in game-dev circles, which maybe makes sense if you're developing a fast-twitch action game or shooter - a GC pause might drop enough frames to matter there, but for most games, Java or C# should be fine.

The console manufacturers have typically provided a C/C++ compiler and nothing else, so it was very difficult in the past to use any other language for developing console games. Some studios did retarget existing compilers like gcc but it was pretty rare; you don't usually have the time for that! If you're doing cross-platform that then limits your code base, so you can't even use the latest features of a language on one platform but not another (e.g. some platforms don't support C++11 in their compiler).
"if you're developing a fast-twitch action game or shooter - a GC pause might drop enough frames to matter there, but for most games, Java or C# should be fine."

Are most games adventure, puzzle solving, or turn-based?

or otherwise not dependent on single-frame precision, yeah.

certainly "fast-twitch action games" and "fast twitch shooters" are a minority of all games.

Action games may be the minority of all games developed, maybe. They're definitely the most desired and most market viable. It's easier to write a turn based game in garbage collected language. There's a surplus of these games, so they don't even sell well.

The best selling console games are sports simulators and first person shooters. The next popular are open world RPG/action (Skyrim, Fallout), then we have fighting and racing games. 2.5D platformsrs are also popular now. All of these games need the deterministic guarantees of "fast twitched action games".

It's not so much performance as much as control. Objective-C is a lot slower than C++, but making action games in pure Objective-C is viable because you are still in control of a system that allows for deterministic resource cleanup and stable frame rate.

In the US, I'd say turn based RPGs and puzzle games are by far the least popular genre on consoles across the board. They may be most widely produced games, they are hardly the most widely consumed ( outside of Mobile).

Well, yes, the idea that there will be GC pauses and you just cannot get a _consistent_ framerate no matter how hard you try does not sound good. (Disclaimer I currently write games with Unity ;D)
> I need to start learning C++ if I want to explore game dev.

You surely need it if you plan to work on high performance engines. Hopefully Rust will find its place there as well.

If you are coding on your own, then C++ can be great as one can make use of modern C++14.

If you are coding with others, be prepared to deal with some kind of C with classes.