Better performance

[Grax]

Considering this is pretty much a one-man project,

This isn't the excuse.
If you can't do things better yourself - let others do it.

I personally would rather see more content. Optimization can come later. In the mean time, have you tried playing on smaller maps?

More content means more interaction details and more detailed interaction. This won't speed all the things up.
Without optimization game become unplayable before you reach the middle of progress.

There are many projects (games and software) that made some profit off the alpha versions that are full of features but barely usable being non-optimized for extensive use - and abandoned when author(s) get bored of it. So user (buyer) stuck with bought bugged alpha.

I have an i4770 and this game really annoys lagging with only 16-18% processor usage (somewhat 75% of a SINGLE core!).
This game is HIGHLY and easily moddable so author don't have an urgent need to expanse the content, as it can be done by almost any semi-pro-user, but no one can optimize the game engine as the sources are closed (and even being open they'll be complicated for others to introspect).

So as for me - i won't buy a game that i can't pleasurably play from start to finish.

[NemesisN]

this game is priced at 30$ and its not worth that much because of this performance issue that they keep skipping with each Alpha...what is the point of having a good PC then if the game refuses to use your PC potential to the fullest

[Alistaire]

Yea that's why it's an alpha.

[NemesisN]

Yea that's why it's an alpha.

Alpha is an excuse for everything apparently

its been in Alpha how long almost 2 years now ? Still this problem is not dealt with
also the price is 30$ which is a lot, at least to expect for that price is the game to run fine

[Fluffy (l2032)]

I'm not going to argue price points - to me it's worth it, but then I have a well paid job and love these style of games. Your situation may vary, and it's a discussion with neither merit nor end.

Similarly, whether you like it or not - the dev team is basically two people. I quite like the level of interaction with developers that that allows, and am willing to sacrifice a little on expectations. Adding people to a working team is often a bad idea - they have to be brought up to speed, which usually takes a big chunk of time from other developers.

Going back to performance. Multithreading is a two-sided coin; the performance boost of splitting intensive tasks over multiple cores is offset by the increased complexity that brings with it.

In a single threaded process, everything happens in turn. This means that if any given task takes a long time, all other tasks need to wait for it to complete. When multithreading, each process can continue regardless of the other. Great! However, the problem comes when both processes are trying to change the same data at the same time and create some kind of bug, which will inevitably happen at some point. These bugs can be extremely difficult to track (since stuff no longer happens in order!). The standard solution is to 'lock' resources currently being worked on, so that processes can not access them at the same time. This is a bit of a hassle, and also creates a new bottleneck - processes now again have to wait for eachother. A game is also different from other applications in that you need things to happen in the same order; when a pawn wants to go somewhere - he needs to know where to go. If you or a pawn interact with the world, you expect the world - and everything in it - to respond appropriately. This implies that each thread is still dependant on the other, they need to be synchronized. The trick then, is to identify which resources need to be locked, and how to distribute the workload so that each process is kept busy on different tasks, maximizing the performance potential, but not running ahead of the others.

This is a complicated, and probably largely trial and error, process that would have to be repeated and/or adjusted for each new feature that is implemented, significantly slowing down development. Another problem more inherent to the game is how you can even split the workload. Typically, you'd want each process to handle a specific area of your code - or a particularly time intensive task. For example, in procedural open world games you would put the task of 'discovering'/creating a new chunk of the world in a separate thread, in a 3d game you might split graphics from logic, or if you have a particularly good climate/temperature system, you might give that it's own thread. RimWorld does none of these things, I'm willing to bet that 95% of the workload in mid-late game comes from pathfinding and locating pawns and things. But there are loads of small pathfinding tasks spread over many pawns, and occurring erratically. Creating a single 'pathfinding' thread just moves the problem to that thread. Creating a thread for each pathfinding task creates a lot of overhead in creating/destroying threads - probably more than it takes to just do the task in the main thread. Splitting pawn pathfinding over multiple threads creates a whole bunch of complications in keeping things thread-safe, and how would you load balance the threads?

TLDR:
multithreading can be a boon, but would significantly slow down development. I'd be much happier if this happens at the end of the development, when the game is feature stable.

P.S. While I stand by the above points, I do wonder if refactoring pathfinding tasks into a queue, and having one or more worker threads work on this queue might be viable. The obvious problem would be that routes may change between the point where the path is requested and the pathfinder doing its magic, which could potentially create problems. Also, it'd mean that pawns have to wait their turn when pathfinding - possibly standing idle while their request is being processed. At some point the workers wouldn't be able to keep up anymore either, so additional checks would need to be made to ensure the game doesn't get too far ahead of itself. Finally, I have no idea of the amount of overhead that such a setup would bring would weigh up to the performance gained - it may not even be worth it.

[TLHeart]

Yea that's why it's an alpha.

Alpha is an excuse for everything apparently

its been in Alpha how long almost 2 years now ? Still this problem is not dealt with
also the price is 30$ which is a lot, at least to expect for that price is the game to run fine

The game does run fine, for the limits set. You are warned that larger maps will cause performance issues.

Mods will ALWAYS slow down a game, with added processing needed. Unity is NOT a multithread platform, but is aimed at portable platforms for games.

Ison spent many months on refactoring the code, along with the new UI.  That was his main job, to improve performance. None of that refactoring have we got to play with, as it is all part of the next release.

Highest overhead on any game like this is the path finding.

[zandadoum]

Yea that's why it's an alpha.

Alpha is an excuse for everything apparently

its been in Alpha how long almost 2 years now ? Still this problem is not dealt with
also the price is 30$ which is a lot, at least to expect for that price is the game to run fine

The game does run fine, for the limits set. You are warned that larger maps will cause performance issues.

Mods will ALWAYS slow down a game, with added processing needed. Unity is NOT a multithread platform, but is aimed at portable platforms for games.

Ison spent many months on refactoring the code, along with the new UI.  That was his main job, to improve performance. None of that refactoring have we got to play with, as it is all part of the next release.

Highest overhead on any game like this is the path finding.

small map, no mods. UBER LAG when colony reaches certain wealth and manhunter packs are 300+, mech raids are 50+ and pirate raids are 80+

[NemesisN]

Yea that's why it's an alpha.

Alpha is an excuse for everything apparently

its been in Alpha how long almost 2 years now ? Still this problem is not dealt with
also the price is 30$ which is a lot, at least to expect for that price is the game to run fine

The game does run fine, for the limits set. You are warned that larger maps will cause performance issues.

Mods will ALWAYS slow down a game, with added processing needed. Unity is NOT a multithread platform, but is aimed at portable platforms for games.

Ison spent many months on refactoring the code, along with the new UI.  That was his main job, to improve performance. None of that refactoring have we got to play with, as it is all part of the next release.

Highest overhead on any game like this is the path finding.

small map, no mods. UBER LAG when colony reaches certain wealth and manhunter packs are 300+, mech raids are 50+ and pirate raids are 80+

same thing, default or small map (I never play on large maps), vanilla no mods, once you go late in game the game starts to lagg

this game is in Alpha for 2 years that is how long we are waiting for performance fix.....I hope its next release but it can be just another Alpha with added new features and same performance like past few Alpha where I hoped performance would be the main fix

[Grax]

TLDR:
multithreading can be a boon, but would significantly slow down development. I'd be much happier if this happens at the end of the development, when the game is feature stable.
\\\

You've got a Stockholm syndrome.
I just want a game that won't lag on the top available hardware.

up to the performance gained - it may not even be worth it.

Oh, don't you mind the perfomance using all 4 cores can be equal or less than a non-threaded unoptimized singlecore?
I think maybe then it's time to hire a professional programmer, who have the skill to do the work.

[NemesisN]

I agree with Grax.....new features and things in game can wait and are not that important compare to the performance....I mean what is the point if you have a limited gameplay.....what is the point of new features if the game laggs and makes you delete your own world out of frustration...what is the point of spending money on a good PC to keep up with the new games if the game does not even use your PC potential at all

[Fluffy (l2032)]

You've got a Stockholm syndrome.
I just want a game that won't lag on the top available hardware.

Actually, no, you're being held hostage by the belief that you need the best available hardware and the best possible graphics/performance to enjoy a game. I'm running the game on outdated hardware, and it runs above my expectations.

Oh, don't you mind the perfomance using all 4 cores can be equal or less than a non-threaded unoptimized singlecore?
I think maybe then it's time to hire a professional programmer, who have the skill to do the work.

I'm not sure what you're trying to say, but I'll answer to what I think you meant.

a) multithreading is not magic. It's not always better to split a task over multiple cores, and it's not always a guaranteed speed up. A task, or set of tasks, need to actually be parallel in order for multithreading to work efficiently. Parallel in this context means that the tasks can run independently of eachother, for most of the task. You cannot just run pawns 1-5 on core 1, and pawns 6-10 on core 2 - they need to be able to communicate with eachother, and threads communicating with eachother is 1) a huge slowdown, 2) a massive potential source of bugs and 3) quite tricky to code.
b) I'm not affiliated to ludeon in any way, so my opinions in no way reflect on RimWorld, it's developers, or the quality of the code. Tynan is an established and well-known game designer, who's great at what he does. I want him to do what he's good at, which is making a great game - not worry about a multithreading mess, or premature optimization.

Finally, you've bought into an alpha version of the game. There was never any confusion, it's clearly labelled as such. Alpha means the game is not feature complete, concepts and mechanics may change rapidly and drastically - and crucially, it's probably not optimized. Optimization in this stage is just a huge waste of time. The next alpha, the mechanics you've spent optimizing for weeks may be removed, or completely changed, and you're back to square one as far as optimization goes.

In the end, participating in an early access game is a trade-off. You may run into bugs, the game may be poorly optimized. But you also get an early view and a voice in how the game moves forward. For an alpha, RimWorld plays great, with no game-breaking bugs that I am aware of. Tynan is very active (when he's not on break) on the forums, and seems to take criticism and suggestions to heart. Overall, I am very pleased with my purchase. If you want to play an optimized final version of the game, wait for the release. It's your choice.

[zandadoum]

If you want to play an optimized final version of the game, wait for the release. It's your choice.

if people asking for higher priority on "better perfomance" than on "new features" is dismissed by Tynan like you dismissed them in this post, then I highly doubt the final version will be any more stable or better performing than the current alpha.

it is NOW that there is still time to improve perfomance. by whatever means. pick your poison: multithreading. recoding gazillion of lines in c#, switching to a better/different engine... all that needs to be done NOW... not when the game is in open beta 1 month before launch.


oh and i don't know what "old hardware" you have, but i have a i7 920 with 12gb ram, hybrid hdd/sdd and a nvidia 660gtx and the game comes to an halt when i get 300 manhunter, 50 mechs or 80 raiders or whatever. on a small map, no mods. and the biggest problem: CPU isn't even at 20%

i like to keep building instead making the ship... and i ALWAYS end up abandoning a colony for perfomance issues, never because it got destroyed.

like i mentioned in other post. a easy fix for this kind of laggy behaviour would be sending fewer, stronger enemies, instead of just multiplying the number like it is now. how few and how strong? don't worry about that, Tynan would certainly balance that out.

[Fluffy (l2032)]

if people asking for higher priority on "better perfomance" than on "new features" is dismissed by Tynan like you dismissed them in this post, then I highly doubt the final version will be any more stable or better performing than the current alpha.

Again, I have no affiliation with ludeon, nor do I speak for Tynan. Stop extrapolating his opinion from mine.

it is NOW that there is still time to improve perfomance. by whatever means. pick your poison: multithreading. recoding gazillion of lines in c#, switching to a better/different engine... all that needs to be done NOW... not when the game is in open beta 1 month before launch.

I tried to explain this twice now. The time for optimization is when the game is feature-complete. Optimization before that is wasted time and effort.

oh and i don't know what "old hardware" you have, but i have a i7 920 with 12gb ram, hybrid hdd/sdd and a nvidia 660gtx and the game comes to an halt when i get 300 manhunter, 50 mechs or 80 raiders or whatever. on a small map, no mods. and the biggest problem: CPU isn't even at 20%

i like to keep building instead making the ship... and i ALWAYS end up abandoning a colony for perfomance issues, never because it got destroyed.

Play a harder difficulty. You're playing the game in a way it's not meant to be played. Most other games will set arbitrary limits, RW does not. That gives you freedom, which is good - but also consequences.

like i mentioned in other post. a easy fix for this kind of laggy behaviour would be sending fewer, stronger enemies, instead of just multiplying the number like it is now. how few and how strong? don't worry about that, Tynan would certainly balance that out.

Now that is actually a good suggestion, and I agree with you there. Smarter AI would be great too, but a lot harder.

[zandadoum]

I tried to explain this twice now. The time for optimization is when the game is feature-complete. Optimization before that is wasted time and effort.

as a programmer myself, i can assure you that improvements like multithreading or changing engine (unlikely, i know) has to be NOW... not when there is double the code to adapt.
later on, TWEAKS need to be done, when all features are in the game, i agree...
but it's the very CORE that is rotten and that has to be fixed BEFORE adding more shit to the equation.

Play a harder difficulty. You're playing the game in a way it's not meant to be played. Most other games will set arbitrary limits, RW does not. That gives you freedom, which is good - but also consequences.

i only play randy random extreme. there ain't a harder difficulty. also: where does it say "how the game is ment to be played"?

[Ectoplasm]

You guys need to limit the number of work types each colonist does, this will massively improve performance. Tynan commented on this on one of the early alphas and is still applicable today.

Best things you can do:
-Fewer work types ticked. Untick as many as you can. Best case is each colonist has exactly one work type.
-Fewer bills active to be done - especially if there aren't ingredients for them. You don't want colonists repeatedly scanning for corpses to cremate when there aren't any. If nobody can do the bill, suspend it.
-Fewer locked doors and inaccessible areas.

https://www.reddit.com/r/RimWorld/comments/2ta0ly/late_game_lag/

When my colonies get large, I can instantly notice (big) Improvements in game performance by limiting the work types each colonist can do. Think of this; you have say 20 colonists, colonist 1 'thinks' can i fight any fires? Nope! Any doctoring to be done? Nope! Am I sick? Nope? Any switches to flick? Nope! Prisoners need looking after? Nope! Can I cook anything? Yes!.... You get the idea.. You have your 20 or more colonists each constantly going through this process looking for work to do, and on big colonies that just creates bottlenecks and the lag starts.

Is this an ideal solution? Not really, but it works 100% for sure.