109

Any system which had a thread for each of so many characters would run out of resources very quickly. Threads may give you access to extra processor cores but they don't make anything intrinsically more efficient, and they come with overhead. The simple answer is just to be efficient about processing each entity in the game. Don't process every entity each ...


78

Now how does the game handle those 30 Projectile and 70 units by handling them on 100 different threads No, never do that. Never create a new thread per resource, this doesn't scale in networking, neither does it in updating entities. (Anyone remember the times when you had one thread for reading per socket in java?) 1 thread that moves all of them ...


64

Dwarf Fortress is not open source, and while there is a lot of conjecture and reverse engineering that can go into how that all works, I will instead focus on some basic techniques for optimizing a 3D (not 3D graphics, 3D world) roguelike of the same type. As is the case with all video games there are a lot of smoke and mirrors that are creating the ...


51

From this page: Well [the pathfinding] looks amazing from my end, since there's a metric ton of characters all doing it at once. TA: The dwarves themselves mostly move around with A*, with the regular old street-distance heuristic. The tricky part is that it can't really call A* if they don't know they can get there in advance, or it'll end up ...


47

Update: In 2018, Unity is rolling out a C# Job System as a way to offload work and make use of multiple CPU cores. The answer below predates this system. It will still work, but there may be better options available in modern Unity, depending on your needs. In particular, the job system appears to resolve some of the limitations on what manually-created ...


41

I may be wrong, but your question makes it seem like you are missing a lot of knowledge in order to successfully write an MMO server. I know this message will likely fall on deaf ears because I was in your position when I started programming. My answer: If I were you I would start smaller. If you want to learn to write an MMO server I would do the following....


41

Yes, this is normal for a real-time game to try to use 100% CPU to perform as fast and good as it can. So that player sees as much frames per second or as good physics simulation or anything else as his PC can provide. In your case - No, this looks like an inefficient design, to take a thread and make it poll for events in a loop (while true do ...


39

Rule number one of multithreading is: Don't use it unless you need to parallelize on multiple CPU cores for performance or responsiveness. A requirement "x and y should happen simultaneously from the users point of view" is not yet sufficient reason to use multithreading. Why? Multithreading is hard. You have no control over when each thread gets executed ...


36

What you have here is a classic O(n²) algorithm. The root cause of your problem has nothing to do with threading and everything to do with the fact that your algorithm has a high complexity. If you haven't come across "Big O" notation before, it basically means the number of operations required to work on n elements (this is the super-simplified explanation)...


26

The other answers have handled the threading and power of modern computers. To address the bigger question though, what you are trying to do here is avoid "n squared" situations. For example if you have 1000 projectiles and 1000 enemies the naive solution is to just check them all against each other. This means you end up with p*e = 1,000*1,000 = 1,000,000 ...


25

For a simple 2D engine with sprites, a single-threaded approach is perfectly good. But since you want to learn how to do multithreading, you should learn to do it correctly. Do not Use 2 threads that run more or less lock-step, implementing a single-threaded behavior with several threads. This has the same level of parallelism (zero) but adds overhead for ...


24

The Don't Dread Threads series by Intel, is quite good. It has 3 parts, the basics are covered in the first 1.5 of them. Don't Dread Threads 1 Don't Dread Threads 2 Don't Dread Threads 3 Summary of what was covered in first 1.5: Avoid Functional Decomposition First of all, they discourage using Functional Decomposition. Functional decomposition is just ...


22

Ok at first glance there are some things you should try out. At first you should try to reduce your collision checks, you can do this by using some kind of spatial structure like a quadtree. This will allow you to reduce the second foreach count, as you will only query entities close the first one. Regarding your threading: Try not to create a thread every ...


19

If anything, it's the opposite - the whole thing runs on one thread and it's now hitting the point where that is becoming the blocking factor (last time I checked!) The reason it's fast is that there's no fancy graphics. It's deceptive, but the main thing that slows stuff down is drawing things (think upwards of two thirds of a frame in AAA titles). Since ...


17

Do not create threads per resource/object but per section of your program logic. For example: Thread to update units and projectiles - logic thread Thread for rendering the screen - GUI thread Thread for network (eg. multiplayer) - IO thread The advantage of this is that your GUI (eg. buttons) does not necessarily get stuck if your logic is slow. User can ...


17

When you load an scene with SceneManager.LoadSceneAsync() there are actually two things happening: The gameObjects of the scene are loaded into memory. Then the whole scene is enabled. All Awake() and Start() callbacks will be called for the objects in the scene. The second step, enabling the scene, is what actually freezes unity, because unity is running ...


15

You propose running each separate "system" in parallel. The problem with this is that you will have to lock every single piece of shared state. CLARITY EDIT: When you have two parallel operations using all of the same data, lock contention and synchronization is going to slow things down so that you're not gaining many benefits from the parallelization. ...


14

If your game is going to be remotely hardware intensive then you need threads to cope with all modern hardware; future CPUs coming out in the next year or two are starting to make 4 cores the minimum and up to 16 cores common for enthusiast/performance markets. If you're doing any multi-threading at all, definitely do a task-oriented architecture as any ...


13

Rule number one of multithreading: Don't even think about it, unless you really need to use multiple CPU cores for performance reasons*. Multithreading opens up a whole can of worms of obscure and impossible to reproduce bugs: Race conditions! Because you have no control over the thread scheduling of the OS, you have no control over the order in which ...


11

You talk about "multithreading difficulties" but what difficulties are you actually talking about? In a way you're citing a phantom problem which may not even exist. The real challenge is one you make for yourself - if you are absolutely determined to get every last drop of power out of a piece of hardware, that does involve using the hardware to best effect,...


11

Fork-Join You don't need separate copies of components. Just use a fork-join model, which is (extremely poorly) mentioned in that article from Intel. In an ECS, you effectively have a loop something like: while in game: for each system: for each component in system: update component Change this to something like: while in game: for each ...


10

To your broader problem, consider trying to find ways to reduce inter-thread communication as much as possible. It's better to avoid synchronisation issues altogether, if you can. This can be achieved by double buffering your data, introducing a single-update latency but greatly easing the task of working with shared data. As an aside, have you considered ...


10

Without looking at your code, the only thing I can suggest is to make your graph coarser. So I would plan the route in 2 steps: given desired route: If you find the route (from the o to the x) using the full graph (with 1 graph node per tile in this case) it would be more expensive than it needs to be. Consider the following (more sparse) set of graph ...


10

I don't know how DF is coded but the amount of AIs doesn't really impress me because what people often oversee it that AI doesn't need precision. It's perfectly viable to do most stuff only every few seconds. It's also viable to use imprecise calculations. Imperfection saves a lot performance. You can run the decision making routine of 100 units every 100 ms,...


10

As always, it depends. Audio is a very complex topic, and the details can be vastly different from API to API, and from system to system. Introduction to audio processing Note: for all the examples below, we will be considering linear PCM, at 44100Hz (samples per second), with 16-bit samples, and two channels (stereo). This is a very common configuration. ...


10

Honestly, the first thing you should do is switch to a better algorithm. Parallelizing your simulation can, even in the best possible case, speed it up only by a factor equal to the number of CPUs × cores per CPU × threads per core available on your system — i.e. somewhere between 4 to 16 for a modern PC. (Moving your code to the GPU can ...


10

You're right on track with using the context only from a single thread. You can only use an OpenGL context from one thread at a time, but you can do everything else in another thread. The simplest way to take advantage would be to do all the loading as you normally would, but send some kind of "event" back to your main thread to actually call the OpenGL ...


9

In a word, synchronization. If you have some data (your world) which you're reading from one thread (the rendering thread), and writing to in another thread (the logic thread), it is possible that your data will be read in an inconsistent state (for example, half the world has been updated, but not the other half). To maintain consistency, you will probably ...


9

Games will not benefit that much by having 4 cores instead of two. Here's why. Basic Game Engine: 1 Thread The problem with graphics API like DirectX and OpenGL is that it must be runned on one thread, and one thread only. So a basic game engine will run all of the logic and render logic into a single thread. These engines will often use a time delta to ...


9

A game with a constant active window refresh will mostly be ran in full-screen mode and be the only (big) program of the machine managed by the OS. So it is totally acceptable to use 100% of CPU, because nothing else should need it. However, that doesn't means of course you have to always use 100% whatever your game state. Most game loops use a sleep method ...


Only top voted, non community-wiki answers of a minimum length are eligible