Ask A Game Dev! - We Are Your Friend's Uncle

The Something Awful Forums > Discussion > Video Games > Ask A Game Dev! - We Are Your Friend's Uncle

Namen: Mar 23, 2004; BEES! BEES IN THE CAR! BEES EVERYWHERE!

Stexils posted:

do bigger games (outside of unity) ever use C# or are they usually C++ for optimization? what languages are most common for different types of games? i'm curious how much the choice of language is a factor in speed for something like, say, GTA as opposed to engine optimization or efficient algorithms or whatnot.

It really depends on the game. Once you start making "bigger" games, you start running into interesting optimization problems that a lower level language (C++, for example) lets you tackle. For example, once the data structures and other tech start to really get nailed down, you can start making memory optimizations with your data in mind. You can also make low level optimizations to algorithms / design such that you optimize hardware usage (eg: CPU cache).

When working in a managed language (like C#), you can run into problems where you are fighting against the framework (contrived example, garbage collection running in a way you don't want it to which causes a hitch).

Conversely, if you don't need to deal with the optimization / low-level headaches, a C# / Unity approach is totally valid.

Namen fucked around with this message at 06:05 on Sep 20, 2017

# ¿ Sep 20, 2017 05:55

Adbot: ADBOT LOVES YOU

# ¿ Apr 19, 2024 23:07

Namen: Mar 23, 2004; BEES! BEES IN THE CAR! BEES EVERYWHERE!

Chev posted:

Actually, using a variable delta does cause inconsistent behavior with physics. Game simulations, including physics engines, belong to the family of explicit methods, and the results of those vary with the size of the delta. That is to say, running the same physics over two frames of 16ms or one frame of 32ms, even multiplying with the delta, will normally yield different results, purely due to numerical integration. On top of that, having a variable physics timestep will cause extra instabilities too (and not just in complex physics engines, an oldschool shmup or street fighter style game is also best served by a fixed timestep). In general using a fixed timestep will make everything more stable, predictable and reproductible, which also carries some implications for networking, debugging and replays. However, what happens if the frame rate itself is too slow or instable?

So, the most flexible option is to separate the update rate (at which the simulation is run) and the rendering rate (at which the frames are rendered, thus usually called frame rate). Although that can introduce some stuttering if done in the most straightforward way there are ways to smooth that.
Note that there may be extra issues when separating them these days, like using the GPU for gameplay tasks. For example the behavior of the water in From Dust was affected by the framerate unlocker mod because it was simulated on GPU as part of the render loop.

Due to its technical lineage, UE traditionally uses variable timestep, though I think there's an option for fixed timestep in UE4 (and some companies like Arcsys certainly managed to use fixed update in UE3 already). Here's an article about all that: https://gafferongames.com/post/fix_your_timestep/

This is pretty much dead on.

# ¿ Sep 22, 2017 16:47

The Something Awful Forums > Discussion > Video Games > Ask A Game Dev! - We Are Your Friend's Uncle