4 ms·

> It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact,

> It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust. I think multiplayer is an area where you'd want "fearless concurrency". Rust could do well here.

andrewmcwatters 6y ago
Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. A better argument might be Rust and Vulcan, though. Even still, you can get very far with just using OpenGL.
- mlindner 6y ago
  > Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. Is that it doesn't benefit, or is it that the benefits are too hard to achieve given the nature of memory issues with games that like to have global state and are written in C++? A lot of games do a bunch of things every frame and then increment state. Those can all be parallelized as they only depend on the previous frame's state.
  - andrewmcwatters 6y ago
    No, it's that most people won't benefit from it. You can't just take any type of game logic and parallelize it either, since there are types of game logic that aren't just dependent on the previous frame. You may be wholly dependent on something that has just occurred earlier in the frame, but has not been networked to clients yet.
  - dxuh 6y ago
    Games code is very often about objects interacting. Especially the expensive stuff (collision/physics and then probably AI). Games don't use global state, because they use C++ and everyone is so bad at programming, but because that's what fits the problem domain. Not to be condecending, but you should try making a game and see how well that parallelization idea of yours turns out.
- randartie 6y ago
  I believe Bevy (rust game engine) does leverage multi-threading for running game code (most 'data oriented' frameworks do). The most popular older engines like Unity do not (unless using the experimental DOTS framework). So, the phrase "a tremendous amount of game code doesn't benefit from multithreading" is actually true since most game code is in unreal/unity, but it's not a hard constraint for all game engines.
  - andrewmcwatters 6y ago
    I think there is without a doubt a space for it. Multithreading in today's game engines should be commonplace, I think. And that's outside of the obvious threads like main and audio. The problem is that most naive "game engines" which provide nothing more than bindings to OpenGL/bgfx, OpenAL, Box2D, etc. and are really just "game libraries," don't even provide things like out-of-the-box multiplayer or level loading, so the idea that they're going to make the leap from providing basically nothing to providing mechanisms for multithreaded game logic, which requires some sort of gamerules/gamemode abstraction first is not something I think you'll see in practice. Most game libraries or game frameworks like these only provide things like load, update, draw callbacks with some nice bindings.

andrewmcwatters 6y ago

Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. A better argument might be Rust and Vulcan, though. Even still, you can get very far with just using OpenGL.

mlindner 6y ago
> Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. Is that it doesn't benefit, or is it that the benefits are too hard to achieve given the nature of memory issues with games that like to have global state and are written in C++? A lot of games do a bunch of things every frame and then increment state. Those can all be parallelized as they only depend on the previous frame's state.
- andrewmcwatters 6y ago
  No, it's that most people won't benefit from it. You can't just take any type of game logic and parallelize it either, since there are types of game logic that aren't just dependent on the previous frame. You may be wholly dependent on something that has just occurred earlier in the frame, but has not been networked to clients yet.
- dxuh 6y ago
  Games code is very often about objects interacting. Especially the expensive stuff (collision/physics and then probably AI). Games don't use global state, because they use C++ and everyone is so bad at programming, but because that's what fits the problem domain. Not to be condecending, but you should try making a game and see how well that parallelization idea of yours turns out.
randartie 6y ago
I believe Bevy (rust game engine) does leverage multi-threading for running game code (most 'data oriented' frameworks do). The most popular older engines like Unity do not (unless using the experimental DOTS framework). So, the phrase "a tremendous amount of game code doesn't benefit from multithreading" is actually true since most game code is in unreal/unity, but it's not a hard constraint for all game engines.
- andrewmcwatters 6y ago
  I think there is without a doubt a space for it. Multithreading in today's game engines should be commonplace, I think. And that's outside of the obvious threads like main and audio. The problem is that most naive "game engines" which provide nothing more than bindings to OpenGL/bgfx, OpenAL, Box2D, etc. and are really just "game libraries," don't even provide things like out-of-the-box multiplayer or level loading, so the idea that they're going to make the leap from providing basically nothing to providing mechanisms for multithreaded game logic, which requires some sort of gamerules/gamemode abstraction first is not something I think you'll see in practice. Most game libraries or game frameworks like these only provide things like load, update, draw callbacks with some nice bindings.