71–80 of 125 posts
Depends on what you consider safety to be. A game engine that doesn't deadlock and doesn't crash should definitely be high priority!
A lot of games run on Mono/.net Java etc. IIRC these languages have far more overhead. (I could be wrong.) So unless you suspect you need >9000 fps OR you are going to be doing a LOT of processing / complex game you might not need to worry about it ?
The JVM can run pure Java code to within 2× of native code (although it has a pretty weak vectorizer, so if you're getting vectorized speedups in native code, Java won't get you that). However, calling a native function from Java is a really high overhead call. Which means that the core engine likely can run at essentially the same speed, but the graphics is going to be slower.
However, the real reason Java and C# apps are most often much slower than native apps is because idiomatic C# and Java is a lot more work to execute. If you want to write really high-performance Java or C# code, you have to make it allocation free on hot paths, you have to be very careful with what types are on the stack and which are on the heap, and you have to pay a lot of attention to data layout (In java that doesn't have structs especially, making lots and lots of types as SoA instead of collection of objects for example).
The bottom line is: while you can make C# and Java code run really fast, it's very hard and non-idiomatic C# and Java code you end up with. It's so hard, that it's actually no easier than writing e.g. Rust or C++ code to do the same thing! And that is exactly the point where C# and Java no longer makes sense: if you can't use the idiomatic and ergonomic way of writing it, it has lost its value.
First of all, they are both great languages, no matter what anyone tries to tell you.
I went through this same dilemma and, while I have great respect for C, I soon realized that my situation would be more productive with C++ and its tools immediately available. For one thing, a lot of important libraries that are common in games and graphics have C++ interfaces, so if you use C you are asking of yourself to exclude some great tools out there, or, go through significant steps to wrap some of them (which would still involve some C++ anyway).
A good article, but what disturbs me is that the author, while obviously aware of relatively good C++ and programming practices, has somehow arrived in a place where he discounts essentially all of C++s core competencies... like claiming RAII is "far from optimal", that exception safety is "a constant mental overhead", and that copy and move semantics involve writing "a lot of code". These are fairly outrageous claim…
>These are fairly outrageous claims, and it all smells of total burnout, and losing sight of the forest for the trees, to me. Maybe, I don't know. I have been a lot happier with C though, while still writing some C++ code during the year.
You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…
Unity is written in C. That the game logic is written in C# is hardly relevant as you explain. In fact this guy might still embed C# at some point if he wishes for his logic to be less painful to write. The author states at the beginning that his goal is writing an engine and only after that write a game. You are right on all other points though, most people working on game engines simply never get to the making a ga…
You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…
I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.
Earlier quoted context omitted.
Unity is written in C. That the game logic is written in C# is hardly relevant as you explain. In fact this guy might still embed C# at some point if he wishes for his logic to be less painful to write. The author states at the beginning that his goal is writing an engine and only after that write a game. You are right on all other points though, most people working on game engines simply never get to the making a ga…
I guess, my question to the author should've been: why are you trying to write a game engine? It's a completely different task than writing a good game, and mostly conflicts with it.
You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…
I don't personally think it matters all that much even on AAA games. Unreal has GC. Take a look at the games made in Unity. Plenty of AAA or close to AAA games. Cities Skylines, Firewatch, Ori and the Blind Forest, Pollen, Endless Legend. I've written several game engines in the past. I hope to never do it again.
I think we may have differing standards. I've only played one of those, Ori, and it had massive problems with long frames. Like, often, and sometimes even half a second long pauses during normal gameplay. I don't know if Unity is to blame for that, but that game is not a good argument in favor of it at least.
A good article, but what disturbs me is that the author, while obviously aware of relatively good C++ and programming practices, has somehow arrived in a place where he discounts essentially all of C++s core competencies... like claiming RAII is "far from optimal", that exception safety is "a constant mental overhead", and that copy and move semantics involve writing "a lot of code". These are fairly outrageous claim…
For example, the paragraph about loading and saving game state postulates "using the ideas of polymorphism and encapsulation", automatically throwing a lot of pointers and vtables in the way of reading and writing a binary blob like in the C engine. A serious C++ engine with a "data oriented" design would have the same arrays of primitive types and dumb structs as its C counterpart, merely dressed as std::vector or std::array.
You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…
Unity is written in C. That the game logic is written in C# is hardly relevant as you explain. In fact this guy might still embed C# at some point if he wishes for his logic to be less painful to write. The author states at the beginning that his goal is writing an engine and only after that write a game. You are right on all other points though, most people working on game engines simply never get to the making a ga…
I mainly use Unity now.