this game requires more optimization in performance....still in Alpha 12 game gets laggy when you increase your colony....the game freezes for 1 second then unfreezes and does that each 2,3 seconds that pass...its really annoying
maybe add a option to turn off animations....for example when butchering blood animation turns off and all other crafting, when building or repairing with that repair torch animation, or chat bubbles, or snow falling down animation, ect....I don't know if that would increase the performance but its just a suggestion
I don't know what else but generally create a option in options to decrease something in quality to increase performance
i doubt it has anything to do with animations
the trouble comes from bad CPU perfomance. the game is only multithread in a few areas (so have i been told)
well, it should be 100% multithread and 64bit for optimal perfomance.
when my colony grows big, it becomes basically unplayable. it's not GPU lag, it's CPU lag and the funny thing is, the game freezes and my CPU is not even at 20% (all cores) and the GPU is around 5%
this becomes specially obvious when a raid lands or a manhunter pack comes (right now 300+ wargs)
a while ago i had the zombie apocalypse mod and there is where i noticed that this must be related to amount of objects on screen. not graphic wise, but the calculation of every object.
i had a crapload of dead zombies, loot and skeletons on a huge map. even with a relateive small colony it became unplayable until i got rid of all those -not animated- objects with the help of a lot of molotovs
its just bad that a low system requirement game laggs this bad on better PC's
this issue needs to be dealt with as a main objective for future alphas instead of going for new features and leaving this issue behind
if Raiders won't kill you in time or any other event in game then you will be forced to delete your good going world because of the frustration of lagg
agreed
Keep in mind that mods can add a significant amount of stress, especially mods that aren't optimized particularly well (autoequip comes to mind).
mods that just add new items/things without custom interactions are generally ok, but mods that add new mechanics/interactions can be extremely ineficient if poorly designed. Your description of a lag every 2 seconds feels to me like a normal tick (once every 250 frames I believe) doing way too much work, and/or not being spread out over frames. E.g. all pawns/things try to get a list of all current objects (they should keep track of their own lists, and do a one-time pre-selection) at once (they should do it spread out over frames so you don't get huge stutters).
If you find your game grind to a halt, take a look at the amount of mods you have installed. That said, the game isn't really meant to go into dozens (or even hundreds in some extreme cases) of colonists - and it will eventually grind to a halt on its own.
I am talking about vanilla with no mods it laggs the same as having mods and I have 12 colonist not 100+
I also tried lowering jobs so each colonist does the minimum jobs creating too much idle colonist problem and work not getting done in time...but it still gets laggy even with job decease seems like its a little help but not very much of difference at all...maybe it has no difference hard to tell really
This problem is with vanilla not just mods, since early Alpha 2 till now....I don't understand why don't they fix this problem first instead of adding new features
To be fair, I think it runs fairly well.
Certainly, things could be improved - multicore being the obvious elephant in the room, but contrary to what some people suggest, thats harder than it sounds, since you get all kinds of synchronizing issues when things happen at the same time.
Considering this is pretty much a one-man project, I personally would rather see more content. Optimization can come later. In the mean time, have you tried playing on smaller maps?
yes I played on smaller maps same thing happen when you go late in the game...I usually play on default or smaller maps
it does run very well at start to some point....until your colony becomes larger....this issue is a problem for people who are experienced at the game and usually last long building up a bigger colony
I don't agree with you on that optimization can come later....this is a big issue because this is the reason I delete my good colonies...because of lagg...as this game is going up with Alpha's its coming closer to final release....and game should be optimized to not create problems like this
this problem was from first Alpha releases till now...that is a long time....it limits me to be able to survive long with my colony and I think optimization should be the first thing to do here
the 1 second lag every 2-5 seconds happened to me once, i had a colony of 60 or some colonist and a bunch of animals. but after some investigation i found one of my colonist stuck in a 1x1 hole in a wall. when i release him the problem went away. maybe you have a stuck colonist as well
Quote from: Ganimedes on December 11, 2015, 09:25:58 AM
the 1 second lag every 2-5 seconds happened to me once, i had a colony of 60 or some colonist and a bunch of animals. but after some investigation i found one of my colonist stuck in a 1x1 hole in a wall. when i release him the problem went away. maybe you have a stuck colonist as well
i had the same problem and solution once.
but the game could really use some better perfomance. and contrary to what people might think, in c# it's not so hard to recode from single thread to multithread. just needs a lot of manhours.
Quote from: Ganimedes on December 11, 2015, 09:25:58 AM
the 1 second lag every 2-5 seconds happened to me once, i had a colony of 60 or some colonist and a bunch of animals. but after some investigation i found one of my colonist stuck in a 1x1 hole in a wall. when i release him the problem went away. maybe you have a stuck colonist as well
I don't have a stuck colonist...and I don't think that is the problem of lagg
But since rimworld is built with unity, multithreading is a major task.
As for the lag, late game, it is caused by more pawns, which includes all colonists, all animals on the map. The power grid calculations also help to cause the lag.
Another cause of lag is the workgiver, and the 10 jobs in ten ticks error, which nemesisN is describing with the pause every few seconds.
Quote from: TLHeart on December 11, 2015, 06:50:41 PM
But since rimworld is built with unity, multithreading is a major task.
i might be wrong, but i read a long while ago that rimworld is coded with c# and using the unity engine. the engine does nothing and affects not the multithreading. single/multithreading depends on the coding language, not the engine.
@nemesis; something similar can happen with animals that are stuck.
@zandadoum; you are correct in that it's coded in C# and uses Unity, but your conclusion is wrong. Large chunks of the core gameplay are implemented through Unity, as the whole point of Unity is to make coding a game easier by providing the 'scaffolding' for games. As to how easy it is to implement multi-core in Unity I can't say, but the fact that so many of these types of games are single core should already tell you that it's not as simple as changing a few settings around.
For me, past 25 colonists I can see a stutter on the screen every few seconds. very annoying.
Quote from: Fluffy (l2032) on December 10, 2015, 06:06:06 PM
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.
Quote
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.
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
Yea that's why it's an alpha.
Quote from: Alistaire on December 12, 2015, 06:19:40 PM
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
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.
Quote from: NemesisN on December 12, 2015, 06:38:20 PM
Quote from: Alistaire on December 12, 2015, 06:19:40 PM
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.
Quote from: TLHeart on December 13, 2015, 12:44:26 AM
Quote from: NemesisN on December 12, 2015, 06:38:20 PM
Quote from: Alistaire on December 12, 2015, 06:19:40 PM
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+
Quote from: zandadoum on December 13, 2015, 06:46:26 AM
Quote from: TLHeart on December 13, 2015, 12:44:26 AM
Quote from: NemesisN on December 12, 2015, 06:38:20 PM
Quote from: Alistaire on December 12, 2015, 06:19:40 PM
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
Quote from: Fluffy (l2032) on December 12, 2015, 08:07:23 PM
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.
Quote
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.
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
Quote from: Grax on December 13, 2015, 09:24:27 AM
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.
Quote from: Grax on December 13, 2015, 09:24:27 AM
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.
Quote from: Fluffy (l2032) on December 14, 2015, 03:56:00 AMIf 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.
Quote from: zandadoum on December 14, 2015, 12:32:45 PM
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.
Quote from: zandadoum on December 14, 2015, 12:32:45 PM
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.
Quote from: zandadoum on December 14, 2015, 12:32:45 PM
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.
Quote from: zandadoum on December 14, 2015, 12:32:45 PM
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.
Quote from: Fluffy (l2032) on December 14, 2015, 01:11:15 PM
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.
Quote
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"?
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.
Quote
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.
Quote from: Ectoplasm on December 15, 2015, 07:12:11 AM
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.
I didn't know about that post, but I already limit work types a lot. Didn't think of it for performance, but to run the colony with smooth specialised working.
So in my case, I was already doing that and still have problems.
Problems that only appear when massive enemy groups are on screen.
ONE THING: one day the game was extremely laggy and I mistakenly unrdrafted all my colonists that were waiting for a big raid to come closer. The moment I did that, the performance improved a bit. But not much. And they all died ofc xD
Quote from: zandadoum on December 15, 2015, 08:21:39 AM
Quote from: Ectoplasm on December 15, 2015, 07:12:11 AM
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.
I didn't know about that post, but I already limit work types a lot. Didn't think of it for performance, but to run the colony with smooth specialised working.
So in my case, I was already doing that and still have problems.
Problems that only appear when massive enemy groups are on screen.
ONE THING: one day the game was extremely laggy and I mistakenly unrdrafted all my colonists that were waiting for a big raid to come closer. The moment I did that, the performance improved a bit. But not much. And they all died ofc xD
Exceeding the limits of the game, and still expect great performance. 300+raiders... yes the performance will suffer, do to all the path equations, target assignments. The game has NEVER been programmed to handle that, and I highly doubt it ever will.
It is being developed with UNITY... not intended for large games, but for small portable games. Games people play for a few hours, and put down. Unity has to be programmed to the lowest common denominator of all the platforms it supports. Therefore multi threading is not possible.
The initial concept was that you would survive, build the ship and leave. That evolved, but the engine will NEVER support the late game with large colonies. The engine is not designed to support 500 ai pawns that need total control and freedom of the entire play space.
Tynan is an idea person, not a programmer. He uses UNITY for that reason. Unity does much of the integration for him.
All of the debug hooks, and code is still in the game. All of that slows performance, and is removed from games once it reaches final release. Until then it is great to have all of those in the game, to help with balance, bugs, logic errors.
If the developers module was removed from the game right now, performance would improve greatly. But testing and debugging and modding would become long slow processes.
Quote from: Fluffy (l2032) on December 14, 2015, 03:56:00 AM
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.
I meant that no one will deny multithreading perfomance (4 cores versus 1) while posessing the ability to use it.
All these arguments like "need to be parallel in order" are just evasions for unskilled. ;-)
Quote
If you want to play an optimized final version of the game, wait for the release. It's your choice.
The game will be morally and physically outdated to the time of release which will be within 5-6 (or maybe even more) years from now.
But i'm somewhat sure that there won't be a full release at all.
Quote from: NemesisN on December 10, 2015, 02:43:27 PM
I am talking about vanilla with no mods it laggs the same as having mods and I have 12 colonist not 100+
12 colonists and the game lags? Are you playing on a potato? ;)
400x400 map. 20 colonists, half a dozen hauling pets. Only had noticably lower (below 30 fps?) performance when I fully zoomed out, set the game to triple speed and had the entire colony plus 150 chickens roaming about on screen. This with a budget price dual core 4-year-old cpu. :o
If anything I am pleased with the stability and performance of a game still in alpha with dev and debug tools. :o
But then again, I do not sit inside a mountain for 5 years building an insane level of wealth and then getting 500+ tribal raids. ;)
Quote from: Britnoth on December 17, 2015, 11:03:41 AM
Quote from: NemesisN on December 10, 2015, 02:43:27 PM
I am talking about vanilla with no mods it laggs the same as having mods and I have 12 colonist not 100+
12 colonists and the game lags? Are you playing on a potato? ;)
400x400 map. 20 colonists, half a dozen hauling pets. Only had noticably lower (below 30 fps?) performance when I fully zoomed out, set the game to triple speed and had the entire colony plus 150 chickens roaming about on screen. This with a budget price dual core 4-year-old cpu. :o
If anything I am pleased with the stability and performance of a game still in alpha with dev and debug tools. :o
But then again, I do not sit inside a mountain for 5 years building an insane level of wealth and then getting 500+ tribal raids. ;)
I'm positive it's not a potato he's playing on.
Because
I am playing on a 8(!!!) years old lapotato, that was fairly average even back then, yet the game runs fine for me, considering.
Even with 18 colonists, ~120 raiders worth of wealth, 150 hare, a few dozens (about 30 I think) of boars, and a dozen muffalos, on a medium sized map (300something IIRC), ~40 mods.
Sure, it can no longer handle triple speed without lagging, but can still handle double speed fairly well, and regular speed perfectly.
I have no idea what he's playing on if a potato can handle it.
Quote from: Britnoth on December 17, 2015, 11:03:41 AM
Quote from: NemesisN on December 10, 2015, 02:43:27 PM
I am talking about vanilla with no mods it laggs the same as having mods and I have 12 colonist not 100+
12 colonists and the game lags? Are you playing on a potato? ;)
400x400 map. 20 colonists, half a dozen hauling pets. Only had noticably lower (below 30 fps?) performance when I fully zoomed out, set the game to triple speed and had the entire colony plus 150 chickens roaming about on screen. This with a budget price dual core 4-year-old cpu. :o
If anything I am pleased with the stability and performance of a game still in alpha with dev and debug tools. :o
But then again, I do not sit inside a mountain for 5 years building an insane level of wealth and then getting 500+ tribal raids. ;)
I am not playing on a potato....PC has Quad Core, my laptop has Intel Dual Core the performance is the same on both....number of colonist are not the only one that effect lagg....my colony base takes half of the map....lot of chunks, lot of dead bodies and weapons on the ground, lot of storage, large raids
also did you read the conversation here...this game does not use the potential of your PC it limits itself on CPU usage....so no matter what PC you have it will run the same....1 core, 4 cores, 8 cores it will run the same because the game does not use your PC potential
Not entirely true, it utilizes one core - if that core is faster, the game will run faster. CPU advances have mostly come in power consumption and increasing the number of cores over the last few years, so yeah - older hardware is going to run just as fast, or in some cases faster as a new quadcore.
@Zandadoum; ok, fair enough. I still don't agree with your assessment that the core is rotten, but if one was to accept that, you make a valid point.
@Grax; I'm sorry, but you clearly have no idea what you're talking about. Multithreading is by no means a magic button that makes everything faster. You're always limited by how much of you program is actually doable in parallel, and across how many threads you can usefully split up the workload. This is a non-trivial task, especially in games, where a lot of systems are linked to each other. It's not like you can just split the game in 2 (or 4, 8, whatever), and run a part on each core.
@TLHeart; Not entirely true, Unity itself does not support multithreading (it's not threadsafe, at least v4 - which RW uses isn't), but C# can obviously do multithreading. Cities Skylines is build in Unity, and does do multithreading quite well. The difference ofcourse is that they had a couple of people working full-time on just the engine - whereas Tynan has to do it all alone (more or less).
So yeah, performance could potentially be better. But it's not likely to happen, because this is not that kind of game. It's meant to be a small colony simulator, creating stories. It's not a Sim City in space. Again, I'm quite happy with the game as it is - I like playing it, and I like it even more as a modding canvas (granted, this is the first game I ever modded). Yes, it's alpha/early access/whatever you want to call it, so the usual advice applies: buy it only for what it is now, not for what you - or the developper! - expect it to be in the future.
Quote from: Fluffy (l2032) on December 17, 2015, 06:27:46 PM
@TLHeart; Not entirely true, Unity itself does not support multithreading (it's not threadsafe, at least v4 - which RW uses isn't), but C# can obviously do multithreading. Cities Skylines is build in Unity, and does do multithreading quite well. The difference ofcourse is that they had a couple of people working full-time on just the engine - whereas Tynan has to do it all alone (more or less).
So yeah, performance could potentially be better. But it's not likely to happen, because this is not that kind of game. It's meant to be a small colony simulator, creating stories. It's not a Sim City in space. Again, I'm quite happy with the game as it is - I like playing it, and I like it even more as a modding canvas (granted, this is the first game I ever modded). Yes, it's alpha/early access/whatever you want to call it, so the usual advice applies: buy it only for what it is now, not for what you - or the developper! - expect it to be in the future.
As I have stated earlier, Tynan is not a programmer, but an idea person, and used Unity because of the ease of creating his idea. Just reading his double negative code says he is not a programmer.
And at present time the entire rimworld is being run within the shell developers debug program, which has a large overhead.
Unity based games will NEVER take full advantage of a pc, it can't, as it has to work on the iphone, tablet, portable game systems also.
is it possible to move the game code so its not Unity ?
or will this game stay in Unity as final product and there is no possible way to change it ?
Quote from: NemesisN on December 17, 2015, 07:41:19 PM
is it possible to move the game code so its not Unity ?
or will this game stay in Unity as final product and there is no possible way to change it ?
That's basically a full rewrite of the game. Unlikely, at best.
if this is how the final product will be then the game is not worth 30$
I would price it at 12$ because it limits you with progress
Some may say 30$ is nothing but in my country 1$ is double the price of my currency which this game costs 60 of my currency and that is a lot for a small game....you expect FIFA, Battlefield, GTA for that kind of money even tho todays games are overpriced for what they are actually worth
Yeah the game is fun but this performance issue is really frustrating
I agree regional pricing should probably be a thing (altho I generally get annoyed by it, being in western europe we usually pay through the nose).
As for enjoying the game, have you tried upping the difficulty level so getting such a large colony is more of a struggle?
Quote from: Fluffy (l2032) on December 18, 2015, 06:43:52 AM
I agree regional pricing should probably be a thing (altho I generally get annoyed by it, being in western europe we usually pay through the nose).
As for enjoying the game, have you tried upping the difficulty level so getting such a large colony is more of a struggle?
my default plays are Rough and Challenge, sometimes I went extreme (rarely)....but the problem with this Raids get seriously large....I do manage to survive long enough on those difficulties sometimes depending on some luck but Raids are big laggy problem
Quote from: Fluffy (l2032) on December 17, 2015, 06:27:46 PM
@Grax; I'm sorry, but you clearly have no idea what you're talking about. Multithreading is by no means a magic button that makes everything faster. You're always limited by how much of you program is actually doable in parallel, and across how many threads you can usefully split up the workload. This is a non-trivial task, especially in games, where a lot of systems are linked to each other. It's not like you can just split the game in 2 (or 4, 8, whatever), and run a part on each core.
Let's say the problem in other words.
I just want a game that run without any lags on any stage of gaming.
And it seems to me there are not many ways to resolve this problem:
1. The simplest way - to simplify all that math complexity eating gigahertz. Not the right way. Limited future scalability.
2. Optimize the code to reduce the excessiveness of all the math operations. Time-consuming but resultative, as i saw it once in Dwarf Fortress example. It's still onecore but pathfinding problems were somewhen rewrited and optimized in previous version and i remember the giant leap in speed from 20fps to somewhat 40 and then to 45-50fps with consequent patches. Maybe using GPU for floating points for example. But it maybe not even possible. And have limited scalability.
3. Optimize the code to use more threads than one. Hard, time-consuming, but almost unlimited scalability in future.
And i'll say it again:
I just want a game that run without any lags on any stage of gaming.
This is not a dwarf fortress game. The owner is here for the money. Fair enough. This game core source code will never be touched by anyone outside of Ludeon studios after the release. Most see that there should at least be enough respect for more help obtained on getting performance fixed. Peoples ego should not be mixed with teamwork and cooperation. In other words, more skilled workers should be brought up to Ludeon studios expectations and invited. Move the progress of the game, quicker before boredom kicks in. No one wants to lose.
I did not want to edit my post. I wanted to be honest and brash. Very thankful for this simulation game.
Many thanks to all the testers and the creators. Thanks.
So from what I've read this is all the fault of unity engine. It would be a GIGANTIC setback to port the game to another engine as MUCH new coding and recoding would have to be done. At this point its a gamble. You can have a PC that costs 3 grand and runs top games perfectly but not this game. Its all in the hands of the developers at this point. My vote goes to performance over content as mods are a thing.
generally, making games better for newer computers is the right way long term. but i dont have that kind of money and also like old school games. so if you ask me, i am perfectly fine with how the game is right now. if anybody has the money and space at home to buy a 3k computer, that person can also buy an old computer for 200 bucks with a very good single core processor, which that player will use for old school games, just like people have been using 5 kinds of game boys, 4 playstations, 3 xbox', dreamcasts, ataris, nintendos and so on and so forth.
(personally, i only ever had an old playstation 2 that i got used and old used computers, but i know plenty of people that had many differnent consoles. and before you even ask, yes, even kids, adults and women. it's not just the stereotypical young adult white nerds in their mother's basement)