Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Unfortunately, the developer is aware of this and won't optimise the game for moderate or bigger colonies. It would be nice to see a few optimisation passes for those of us who play colonies that aren't tiny, but it's never going to happen.
The thing is, using multiple CPU cores (usually called "multi threading") is a fairly difficult programming task. The main problems are splitting up things to be done into tasks where task B doesn't depend on task A being complete, and avoiding bugs due to timing issues because you can't predict when each task will finish.
It's a perennial problem for game developers, and one that small studios like Ludeon always struggle with.
I've had little trouble running a similar sized colony, but my CPU has beefy arms like Trogdor. Your answers are either intentionally limit yourself to colonies your computer can handle, or getting a faster computer. I wouldn't count on Rimworld becoming much more efficient any time soon.
as gussmed stated, it isn't an easy task to "optimise" this game in such a big way.
i am 100% sure that the developers would love to "optimize" it, but the biggest optimisation they could do would most likly requiere a complete rewrite of the games code, i'm not talking about 1%-5%, i mean somewhat between 50% and 100%.
here again, i bring the example of Aurora 4X, the dev had to rewrite the whole game in C# for some big improvements, which might be possible early in development or for hobby projects, but nothing you want to do on a finished product years in working
But what's done is done, and all we can do is play at 10FPS and hope to dog the game doesn't crash during the 45 minute wait timer for a decently kitted raid to finish loading into the map.
1) # of colonists -- all the social interactions they do, adds to the cpu usage
2) # of animals - animals interactions with each other and colonists also add to the usage, as well as keeping a family tree of all these animals
3) Hauling -- calculating the hauling for many colonists and hauling animals, adds to the usage
My guess is that your slow down is due to all these social interactions or hauling calculations.
For example, if you started a new colony with all the same mods, you would not have the slow down.
Ditto animal interactions. Those are cheap. "Keeping a family tree" requires no CPU usage at all, it's a static piece of information only updated on a birth. It's not even much data storage, since it's at most a few dozen bytes per relationship.
You may have noticed animals only look for short distances unless they're hauling or returning home or a similar task. That's to keep the pathfinding cost down. The pathfinding cost is proportionate to the area they search. So if they look in a 20 x 20 area, that's 400 tiles. If they look in a 40 x 40 area, that's 1600 tiles. Check an entire 250 x 250 map, and it's 62,500 tiles.
Look up Dijkstra's Algorithm if you want an explanation of what's involved.
It's not like it was some arbitrary decision and that the issue is that they just decided so. Like gussmed already said, it's a huge task to take on and most small developers don't have what it takes to do it. You can't just decide to be able to do something.
You have to know:
* How difficult the task is computing terms. There's an upper limit to how far you can optimize something, because the task itself is just very expensive. Large maps and lots of moving, decision making entities are examples of things that increase the size of the task.
I'd give long odds that Rimworld raids ARE optimized, in the sense that there's a single pathfinding task for the entire group, rather than individual pathfinding tasks for 50+ moving raiders.
* What language it's written in. It's much more difficult to produce fast code in an interpreted language like Java. If you want speed, you want an optimizing compiler, which means a language like C or C++. Rimworld's written in C#, which I gather doesn't support the same level of optimization, since it's a cross-platform language which requires a just-in-time compiler. That slows it down considerably compared to something compiled directly to machine code.
* Where the time is going. Typically 5% of the code is eating 90% of the CPU cycles. Optimize just that portion of the code, and for most purposes the game is now optimized, because the rest of the non-optimized code just doesn't run very often.
If you make a program in the beginning with that mindset you can pull this off. But if you did come up with it later, you have a problem.
and you can't even garantue that it will work if you do it from the beginning. splitting pathfinding without waiting for the task to be finished first might lead to unexpected behavior (like 2 pawns trying to eat the same meal, working at the same workbench and so on) even if it doesn't lead to instability, seeing 2 pawns suddenly move to a deep drill at the edge of the map just to see the second pawn recalculating and move to the deep drill on the other side of the map would be even more frustating.
only because you #can# split tasks doesn't mean you #should#.
and if you wait for üathfindingtask 1 to finish befor task 2 to start, there would be no point in splitting the task at all (it would only add more workload without gaining any performance)
To be fair, most management games usually lets the player throw in a good amount of pawns into a game. I'm sure a good amount of people expect the same for this title as well.
Multicore or not, the game could be further optimized.
It's written in Unity. Until fairly recently, Unity had precisely two threads (UI and background). You could *technically* use more, but no Unity functions were threadsafe, and so you'd have to have written your own duplicates that are, or just have avoided anything Unity specific entirely. IIRC, Unity was this way until Unity 2017, and Rimworld was started before that edition went public.
What this means, so far as optimizing for multicore processing is that unless Ludeon wants to risk *everything* breaking by upgrading to a more recent version of Unity, and then rewrite nearly 100% of their code, it's not going to happen. Ever.
Additionally, since their code is written for a version of Unity that only had two threads, it is almost certain that much of their code is actually dependent on sequential execution. When you deal with multithreaded code, it's utterly asynchronous. You have to account for that. Rimworld was written before that was necessary in Unity.
TL;DR: Rimworld is written in an older version of Unity that didn't have full multithreading. I can just about 100% guarantee that it will never be optimized for multicore.