5 ms·

> due to multiple threads trying to edit the world ref 50+ times per second. Of course you get no benefit if you serialize the game through a single ref. Just

by sbov 10y ago

> due to multiple threads trying to edit the world ref 50+ times per second. Of course you get no benefit if you serialize the game through a single ref. Just because you have a fancy feature like agents doesn't mean you don't have to think about how your concurrent code is behaving. I chose Clojure for the server side code of my MUD. It wasn't for the agents or STM, it was for immutability. Immutability gives me the ability to easily have a consistent snapshot of the world which I can use to perform some operation, such as saving, event propagation, or some AI calculations.

corecoder 10y ago
Which MUD?
lgas 10y ago
If you don't serialize the game through a single ref (or the equivalent) how do you get the consistent snapshot of the world to perform an operation on?
- glhaynes 10y ago
  Event loops are heavily used — basically process input, process physics, process NPCs, render, repeat. (Likely not in that order — I'm not much of a game developer.) This is what the author lands on in the "Success" section. Speaking of event loops, I feel like they weren't discussed very much at all at my school, despite being at the core of not just most game engines, but most GUIs. I think if I'd embarked on writing a GUI system when I was fresh out of school, I'd probably have done it in a massively threaded way like the developer in the article started their game. An event loop would have somehow seemed too … primitive.
- sbov 10y ago
  Architecture can heavily affect how serial your process is. By randomly throwing agents at a single ref you can easily turn parts of the process that can be done in parallel into a serial process. Beyond that, throwing massive concurrency at an inherently serial process tends to give you worse performance vs just recognizing that it's a serial process and not trying to throw concurrency at the problem. This isn't just about fancy concurrency primitives like agents or STM, I've seen plenty of hobby games that ran terribly because they threw concurrency at the problem without analyzing it first, but ended up completely serial because of critical sections in the form of Java synchronization blocks. As an example of concurrency that you would probably have in every single player game: game logic feeds into render logic, but render logic shouldn't be changing the state of the world. So you can be performing the game logic of game loop #N+1 while the render logic of game loop #N is running. Also, usually, when saving the state of the game all you need is a consistent snapshot at the time. Immutability makes both of these easy. The rest depends upon the features and design of your game though. If you aren't going to actually try to analyze where you can benefit from concurrency, you're better off not just randomly throwing concurrency at the problem.

by sbov 10y ago

corecoder 10y ago

Which MUD?

lgas 10y ago

If you don't serialize the game through a single ref (or the equivalent) how do you get the consistent snapshot of the world to perform an operation on?

glhaynes 10y ago
Event loops are heavily used — basically process input, process physics, process NPCs, render, repeat. (Likely not in that order — I'm not much of a game developer.) This is what the author lands on in the "Success" section. Speaking of event loops, I feel like they weren't discussed very much at all at my school, despite being at the core of not just most game engines, but most GUIs. I think if I'd embarked on writing a GUI system when I was fresh out of school, I'd probably have done it in a massively threaded way like the developer in the article started their game. An event loop would have somehow seemed too … primitive.
sbov 10y ago
Architecture can heavily affect how serial your process is. By randomly throwing agents at a single ref you can easily turn parts of the process that can be done in parallel into a serial process. Beyond that, throwing massive concurrency at an inherently serial process tends to give you worse performance vs just recognizing that it's a serial process and not trying to throw concurrency at the problem. This isn't just about fancy concurrency primitives like agents or STM, I've seen plenty of hobby games that ran terribly because they threw concurrency at the problem without analyzing it first, but ended up completely serial because of critical sections in the form of Java synchronization blocks. As an example of concurrency that you would probably have in every single player game: game logic feeds into render logic, but render logic shouldn't be changing the state of the world. So you can be performing the game logic of game loop #N+1 while the render logic of game loop #N is running. Also, usually, when saving the state of the game all you need is a consistent snapshot at the time. Immutability makes both of these easy. The rest depends upon the features and design of your game though. If you aren't going to actually try to analyze where you can benefit from concurrency, you're better off not just randomly throwing concurrency at the problem.