Massive Groups

[Ember]

wasn't sure if i should post this here or general

so I love playing on the largest map size available and i have not had many issues with them, however, massive groups seem to cause a large FPS drops when they do their path finding all at once, is there any way to limit the max number of groups appearing on the map?

this is the largest group yet to appear on my map totaling 236 with Randy as the AI

this group caused my game to freeze for about a minute
cpu usage at that time is about 26% and memory usage is about 34% so it has nothing to do with my computer itself

[Coenmcj]

Everyone encounters the same problem.

I'm assuming your computer is a quad core, so 26% (1 Percent going to other programs) Is about the maximum you could possibly use anyhow, Rimworld is not a multi-threaded program to my understanding. so computers with multiple cores cannot utilize those additional cores. (What is the reasoning behind that?..)

[Ember]

yup quad core, with 8 logical processors
is there any plan to support multi core computers in the future?

also, any way to limit the size of these groups?
I wouldn't be surprised if they just kept on getting bigger

[Coenmcj]

They do, until you leave, or die, they just keep coming.

As far as Ludeon's stance on Multi-threading goes, I would just have to ask Tynan about it.

[Tynan]

Yeah, there are some endgame scaling issues. Serious ones. I'll have to work to address it.

[Xerberus86]

well, would be nice to have multi-thread support to at least some degree, with the amount of great mods we have for rimworld the problem should only get worse :/.

[StorymasterQ]

Hm, multi-threading sounds like quite an effort for an Alpha stage game, though.

I agree that it's getting pretty bad, but I'm just not sure it's the best thing to do in this stage. Perhaps for the first Beta? Or maybe starting the double digit Alphas?

[Tynan]

Why do you care if it is multithreaded or not? How would you even know the difference between that and straight-up optimization? I guess I'm always just confused when people talk about multithreading like it's a feature. All it is is one of many possible ways to make the game run faster.

Just FYI, the game is quite horribly unoptimized in a lot of areas. For example, we could reduce draw call counts 10 times using generated sprite sheets instead of keeping every texture separately. We have tons of simple improvements to make before doing something as extreme as trying to multithread the game.

Honestly I doubt multithreading will ever be necessary to make a 2D game like this run smooth as butter on any reasonable machine.

[Coenmcj]

Well, While optimization can make a process less resource intensive and execute faster, Multithreading allows for the process to be split into subtasks that are completed simultaneously, allowing for faster execution and a lower workload on the Central Processing Unit. If the main thread decides to freeze on a lengthy task, the task is delegated to a worker thread while the rest of the system is left open to user input and other tasks.

Why do you care if it is multithreaded or not? How would you even know the difference between that and straight-up optimization? I guess I'm always just confused when people talk about multithreading like it's a feature. All it is is one of many possible ways to make the game run faster.

Just FYI, the game is quite horribly unoptimized in a lot of areas. For example, we could reduce draw call counts 10 times using generated sprite sheets instead of keeping every texture separately. We have tons of simple improvements to make before doing something as extreme as trying to multithread the game.

Honestly I doubt multithreading will ever be necessary to make a 2D game like this run smooth as butter on any reasonable machine.

That is fair enough, Optimization should always be taken over something so drastic, however most machines have multiple cores, so it seems strange not to want to maximise efficiency. But that is just my opinion and it is your game after all.

Edit : Think of it like your team, while you can always get better, is it not easier to split up the work amongst your team?

[Xerberus86]

Why do you care if it is multithreaded or not? How would you even know the difference between that and straight-up optimization? I guess I'm always just confused when people talk about multithreading like it's a feature. All it is is one of many possible ways to make the game run faster.

Just FYI, the game is quite horribly unoptimized in a lot of areas. For example, we could reduce draw call counts 10 times using generated sprite sheets instead of keeping every texture separately. We have tons of simple improvements to make before doing something as extreme as trying to multithread the game.

Honestly I doubt multithreading will ever be necessary to make a 2D game like this run smooth as butter on any reasonable machine.

ah ok, i am not a programmer and i thought dedicating several things like AI pathfinding, storyteller, combat calculation and such to different corse would be benificial but again, not a programmer. thanks for clarification .

[RemingtonRyder]

Using multiple cores to divide up the work sounds great in theory.  Multiple threads don't always confer an advantage though.  For example, take the example of pathfinding.  If you just split that up across two cores, you can have pawns trying to pathfind to the same spot, because the spot was reserved twice in different threads.  Oops.

An example of what you could do without too much hassle:

Divide the pathfinding into two stages - the first simply returns a series of binary matrices indicating for example 1) Is the terrain passable, yes or no 2) Does the tile provide high cover, yes or no 3) Are there any bashable doors, yes or no.

Then the second stage examines the matrices and suggests possible courses of action for that pawn to take - move to a place with high cover, bash in a door, or flank an enemy pawn.

Thing is, to actually get any benefit from dividing this into two stages, the work required has to exceed a certain threshold.  Otherwise you can just do stage 1 and stage 2 on one thread.

[Ruin]

Why do you care if it is multithreaded or not? How would you even know the difference between that and straight-up optimization? I guess I'm always just confused when people talk about multithreading like it's a feature. All it is is one of many possible ways to make the game run faster.

Just FYI, the game is quite horribly unoptimized in a lot of areas. For example, we could reduce draw call counts 10 times using generated sprite sheets instead of keeping every texture separately. We have tons of simple improvements to make before doing something as extreme as trying to multithread the game.

Honestly I doubt multithreading will ever be necessary to make a 2D game like this run smooth as butter on any reasonable machine.

I would assume because, if the problem is a good candidate for parallel decomposition (a big "if" in some cases), it will always run faster on 4/6/8 cores than on 1 core.  This impacts issues like maximum game or raid size on a given set of hardware.  Optimization is great and has far more potential that parallelization if the task is a good candidate for optimization.  But, an optimized and parallel solution is the best solution in many cases.  Game developers tend to focus shy away from parallel processing like the plague (I assume because algorithm parallelization can be *really* hard ... did my graduate work in it so, I can pretty much state this as fact).  And, not all problems are good candidates for parallelization.  And, not all users have highly parallel machines.  But, sometimes gains are easy.  For example, say that path computation is the big issue when a bunch of pawns appear on the map.  If you could create a parallel path computation thread, suddenly it becomes much less of an issue on big rigs.

Of course, you could also just optimize the algorithm by orders of magnitude if you find a chunk of stupid code.  And, once it is fast enough that us slow humans don't see any lag, what is the point of optimizing further (unless you want ever increasing complexity in terms of map size, number of pawns and such).