Edit History

12 minutes ago, Ricowan said:

Here's the thing with multithreading:
Threads are independent, they are NOT aware of what each other is doing.  If you spin off a thread to work on one thing, but main thread changes that thing, then the first thread is now invalid.  So you have to add in specialized thread managers, or just live with the fact that you will occasionally waste processor time by throwing away incomplete thread work.

Once a new thread has completed it's work, that work has to be re-integrated into the main thread loop somehow.  In many cases that will add more performance hit than the new thread saved.

Multithreading is great for splitting up a single task that works on data that doesn't change.  This is not a common scenario in a fast paced multiplayer game where the terrain can be changed by players and NPCs at any time.

 

That's a good simplified explanation of multithreading.  I like it.  People often think that multithreading is some easy thing to do that works in every situation and automatically speeds things up.  That just isn't the case.  And even games that have multithreading usually only have it for very specific things and not for the game as a whole.  In a game, you often have many different things all working in an interconnected way and trying to pull a piece out and run it separately and then intertwine it back in and still get some kind of performance increase rather than a loss isn't always possible.  It works best when you have some part that is entirely, or at least almost entirely, separate from everything else that can be done in its own thread without affecting other things.  There are places where this is an option but there are many more places where it isn't a good option.

A very simple and basic example that might help people to visualize the issue...

Let's say AI is on one thread and building/destruction of blocks are on a different thread.  The AI sees that it can walk a zombie forward without anything in the way.  Someone builds a wall at the same time that would prevent the zombie from going forward.  The AI thread doesn't know about that wall because the two processes are in different threads and so still tells the zombie to go forward.

Now, there are ways to integrate threads and provide some interaction/updates to them, but the more things you do to tie the threads together, the less benefit you can get from them being separate threads.  Also, to be clear, that example is NOT how they are doing things and isn't what I'd suggest as a good way to do things.  It is just a very simple and basic example about why something would be a challenge.  So you don't need to tell me that it's not how someone would do multithreading because I know it isn't. 

12 minutes ago, Ricowan said:

Here's the thing with multithreading:
Threads are independent, they are NOT aware of what each other is doing.  If you spin off a thread to work on one thing, but main thread changes that thing, then the first thread is now invalid.  So you have to add in specialized thread managers, or just live with the fact that you will occasionally waste processor time by throwing away incomplete thread work.

Once a new thread has completed it's work, that work has to be re-integrated into the main thread loop somehow.  In many cases that will add more performance hit than the new thread saved.

Multithreading is great for splitting up a single task that works on data that doesn't change.  This is not a common scenario in a fast paced multiplayer game where the terrain can be changed by players and NPCs at any time.

 

That's a good simplified explanation of multithreading.  I like it.  People often think that multithreading is some easy thing to do that works in every situation and automatically speeds things up.  That just isn't the case.  And even games that have multithreading usually only have it for very specific things and not for the game as a whole.  In a game, you often have many different things all working in an interconnected way and trying to pull a piece out and run it separately and then intertwine it back in and still get some kind of performance increase rather than a loss isn't always possible.  It works best when you have some part that is entirely, or at least almost entirely, separate from everything else that can be done in its own thread without affecting other things.  There are places where this is an option but there are many more places where it isn't a good option.

A very simple and basic example that might help people to visualize the issue...

Let's say AI is on one thread and building/destruction of blocks are on a different thread.  The AI sees that it can walk a zombie forward without anything in the way.  Someone builds a wall at the same time that would prevent the zombie from going forward.  The AI thread doesn't know about that wall and so still tells the zombie to go forward.

Now, there are ways to integrate threads and provide some interaction/updates to them, but the more things you do to tie the threads together, the less benefit you can get from them being separate threads.  Also, to be clear, that example is NOT how they are doing things and isn't what I'd suggest as a good way to do things.  It is just a very simple and basic example about why something would be a challenge.  So you don't need to tell me that it's not how someone would do multithreading because I know it isn't. 

8 minutes ago, Ricowan said:

Here's the thing with multithreading:
Threads are independent, they are NOT aware of what each other is doing.  If you spin off a thread to work on one thing, but main thread changes that thing, then the first thread is now invalid.  So you have to add in specialized thread managers, or just live with the fact that you will occasionally waste processor time by throwing away incomplete thread work.

Once a new thread has completed it's work, that work has to be re-integrated into the main thread loop somehow.  In many cases that will add more performance hit than the new thread saved.

Multithreading is great for splitting up a single task that works on data that doesn't change.  This is not a common scenario in a fast paced multiplayer game where the terrain can be changed by players and NPCs at any time.

 

That's a good simplified explanation of multithreading.  I like it.  People often think that multithreading is some easy thing to do that works in every situation and automatically speeds things up.  That just isn't the case.  And even games that have multithreading usually only have it for very specific things and not for the game as a whole.  In a game, you often have many different things all working in an interconnected way and trying to pull a piece out and run it separately and then intertwine it back in and still get some kind of performance increase rather than a loss isn't always possible.  It works best when you have some part that is entirely, or at least almost entirely, separate from everything else that can be done in its own thread without affecting other things.  There are places where this is an option but there are many more places where it isn't a good option.

A very simple and basic example that might help people to visualize the issue...

Let's say AI is on one thread and building/destruction of blocks are on a different thread.  The AI sees that it can walk a zombie forward without anything in the way.  Some builds a wall at the same time that would prevent the zombie from going forward.  The AI thread doesn't know about that wall and so still tells the zombie to go forward.

Now, there are ways to integrate threads and provide some interaction/updates to them, but the more things you do to tie the threads together, the less benefit you can get from them being separate threads.  Also, to be clear, that example is NOT how they are doing things and isn't what I'd suggest as a good way to do things.  It is just a very simple and basic example about why something would be a challenge.  So you don't need to tell me that it's not how someone would do multithreading because I know it isn't.