Hacker News new | past | comments | ask | show | jobs | submit login

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.


The engine or the programmers?


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


You mean like those engines done in Assembly with C and Turbo Pascal as scripting logic 20 years ago?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: