Jump to content

Recommended Posts

So, I have been playing this game for quite a while, so I have a decent idea about what impacts the game lag... But... Than I realized that I never actually tested some of my assumptions... If you are not interested in the experiments, feel free to skip to the end of the thread - the "takeaway section"

For the start of the chain of the experiments... I prepared an almost empty map for myself.
 

Spoiler

deletedmap.thumb.PNG.41c1e5e6895f46ea8194e59ddb9077c4.PNG


Than, for the first set of experiments. I made sure to turn this into a box with insulation tiles as the walls and filled the entire box with equally spread oxygen... My hope is that it will minimize any calculation for gas movement and heat exchange, so they do not interfere with the actual experiments.
 

Spoiler

insulation.thumb.PNG.e39e5fbad2b2d9309f58f02fb9f16703.PNG


Experiment 1.0:
Test: filling the entire map with ladders to maximize the possible amount of routes. But do not give duplicants access to those ladders.
Expected result: game will work without lag, because the game does not actually get to calculate those paths.
Result: No lags were observed.
 

Spoiler

Experiment1.0.thumb.PNG.8f596e1421634408681a87cbfdbf1552.PNG


Experiment 1.1: make dupes mine something, but do not allow the access to ladders yet.
Expected result: game will work without lag.
Result: no lag observed.
 

Spoiler

Experiment.1.1.thumb.PNG.b52af57abc70427ec024b1a4db9b490d.PNG


Experiment 1.2: Make a mining task that will give access to the ladders.
Expected result: game will explode.
Result: game almost explodes as soon as they mine a path to the ladders. There is major lag and even moving camera around in pause mode is hard.
 

Spoiler

Experiment.1.2.thumb.PNG.6f9d2bbccb6101a24ded72f2a38a30b9.PNG


Experiment 1.3: have an access to the ladders through a closed door.
Expected result: lag will be gone.
Result: lag was gone as soon as I hit lock button on the doors. You can only imagine what kind of relief it was when you can move your camera again.
* actually, I did not even hit the lock button in quick build mode. Most of lag was gone before the doors were actually locked by a dupes which is unexpected. Though, the game staggered quite a bit while the dupe was walking to the door to lock it, but way less than when the door was on other mode.
Opening the door introduces lags as expected.
**not giving a way out through the auto door works the same as just locking it... Clicking allow button on the permission to move right makes game lag harder and harder with each dupe allowed and less when a dupe is removed from permissions.
 

Spoiler

Experiment.1.3.thumb.PNG.699668cd21b73c7905436ad749dbd0ef.PNG
5d6483d49a777_Experiment1.3.1.thumb.PNG.875675705f9dc65762ee13dcf3d87ee7.PNG


Experiment 1.4: Lock dupes inside the minibox and add a few flying critters into the open space.
Expected result: game will lag.
Result: Suprisingly, the game only froze for a few second when unpaused, but did not lag afterwards.
* adding many times more critters. I managed to achieve very minor lag of the game... Though. I observed another thing. At the start of the cycle and sometimes in the middle of it, the game would freeze... The number of critters would make the freeze longer. Thats 400 pufts in the open and it just causes period freezes for 5-10 seconds once or twice during a cycle. Getting rid from all the pufts, gets rid from any freezes.
** putting 400 pufts inside the confined space makes the game run smooth, though, I there was still a loading freeze at the start of the cycle. Closing and opening the door does not seem to have an impact on the game.

I find it very interesting that the game calculates something for critters at the start of the cycle, but putting critters inside a closed room does not seem to ease those calculations.

Spoiler

Experiment.1.4.thumb.PNG.c6e8ac6f570c4177b7ed320444bd66be.PNG
5d6488cb2b896_Experiment1.4.1.thumb.PNG.932aa63f57d6bf1c6c9f99dfd1555bdf.PNG
5d648fdc9e942_Experiment1.4.2.thumb.PNG.4d471ea5d3523358a0c8f4148e6ac38f.PNG


Accidental Experiment 1.5 :D Trying to save and restart this map.
Result: game took quite a long time to load and when it loaded, you could not play for about a minute as it kept on loading.

--------------------------------
---------Takeaway----------
--------------------------------
Mostly, with this experiment, I have confirmed what I already knew. To cause less lag in your game:
1. Give your duplicants as little options in their paths as possible.
Here is what will cause you lag more:
 

Spoiler

bad1.thumb.PNG.11da101f51f88cd0781ceb03cf31f7ea.PNG


If your base ever looks like that, make sure to fix it. Just having access to more options causes more lag. Also, on the side note. Every single time I added fire pole to my base, my base would start lagging, I do not even need to test for it.

Here is what should cause less lag:
 

Spoiler

good1.PNG.f65dda836fe65f04913ccf9104a6711c.PNG


2. As a continuation of point 1, block your duplicants access to areas that they have no business visiting.
3. As continuations of point 2, confine your duplicants to their personal workspace. Only let miners have access outside your base. Make farmers sleep next to farms and make them never be able to leave the farms. Make ranchers sleep with the critters... Etc.
4. Use automation to lock down areas which duplicant will not visit during the specific time of day... For example:
 

Spoiler

Breaktime.thumb.PNG.1f83d4dc85fc194f54a5e52121758e30.PNG

They have no business inside their bedrooms, mess halls, toilets, rec rooms, washrooms, etc during the time of day that is not a break time. So, use automatic to lock those away and open at specific time of day... This design uses 2 doors, one is open/closed by automation, the other is an one way door, to make sure that dupes do not consider going out after they went in and vice versa... (also, this a reason why narcoleptic sucks, they can easily fall asleep during the time you close/open the doors and be stuck where you do not want them to be.)


I plan to do more lag tests, but I would like to hear what other people know and tried.


 

Link to comment
Share on other sites

3 hours ago, metallichydra said:

Oxygen not included is the only game I know where players actually try to minimize lag themselves.

 

its as if lag is part of the game.

go to dwarf fortress forums. FPS death is the real killer of fortresses.

Link to comment
Share on other sites

It's very clear that pathing is a gigantic CPU drain. A-star pathing may be efficient, but using it a thousand times a second on a colossal spiraling maze map isn't. Knowing this, it's clear that zoning your dupes to restricted areas will do wonders for FPS.

Link to comment
Share on other sites

15 minutes ago, Aelfled said:

There is no magic wand to miraculously make this faster, blaming Klei is silly.

This is now a launched title, and one that has had the majority of these same lag issues for over 2 years.

A lot of these issues have never been addressed despite being openly acknowledged (and sometimes laughed about) on their dev streams.

There comes a point where the blame needs to rest somewhere, and although i'm a lover of Klei and their content, i'm not a fan of the lack of attention put into making the game an enjoyable experience to actually....well, play.

No need for white knighting here, it's best we discuss these things openly, and let's face it; we all know the status of the game in it's current form - infuriatingly piss-poor performance late game.

Link to comment
Share on other sites

12 minutes ago, Lifegrow said:

This is now a launched title, and one that has had the majority of these same lag issues for over 2 years.

A lot of these issues have never been addressed despite being openly acknowledged (and sometimes laughed about) on their dev streams.

There comes a point where the blame needs to rest somewhere, and although i'm a lover of Klei and their content, i'm not a fan of the lack of attention put into making the game an enjoyable experience to actually....well, play.

No need for white knighting here, it's best we discuss these things openly, and let's face it; we all know the status of the game in it's current form - infuriatingly piss-poor performance late game.

Every time a tile is dug, every time many buildings are con/destructed, every time a door is locked or unlocked, all current plans by dupes will need to be recalculated to see if they will still work. Equally, so do all sweep orders, just so that they can have a white or red icon. A* is the most efficient way of doing these calculations but it is still not quick for large networks, especially if you are calculating it lots of times because you will have terrible cache locality between dupes at opposite edges of the map.

 

The only real way to speed up such things is to shrink the map size even more than it already has been, or the player set things up so that A* doesn't need to examine lots of incorrect paths.

Link to comment
Share on other sites

Quote

A* is the most efficient way of doing these calculations 

A* is an efficient general purpose algorithm. Using a general purpose O(bd) algorithm thousands of times on a large data set is still not efficient. Chop a big problem into much smaller problems. Once a solution is found, there's no need to solve it over and over again. Take the answer, large or small, and recycle it as many times as possible.

Link to comment
Share on other sites

14 hours ago, DarkMoge said:

**not giving a way out through the auto door works the same as just locking it... Clicking allow button on the permission to move right makes game lag harder and harder with each dupe allowed and less when a dupe is removed from permissions.

 

2 hours ago, bobucles said:

A* is an efficient general purpose algorithm. Using a general purpose O(bd) algorithm thousands of times on a large data set is still not efficient. Chop a big problem into much smaller problems. Once a solution is found, there's no need to solve it over and over again. Take the answer, large or small, and recycle it as many times as possible.

Given all the dupes in the experiment were starting from the 'same' location and presumably had no actual available tasks (or very similar tasks in similar locations), the lag should not be increasing basically linearly with each dupe given access to the greater map.

Saving (and updating as the map changes) heavily re-used paths and using them for the core transit should allow significant reductions in lag.  It's not a trivial amount of development effort of course, but it would seem it's necessary at this stage.

Link to comment
Share on other sites

In developers defense, I want to say that its easy to ask someone to solve a problem when you actually do not know what the problem is. There are probably things that can be optimized without changing their behavior... But there might be things that are hard to optimize without changing how they function. As someone who is familiar with programming, my tests gave some understanding about how the game actually functions for dupes. And well, with my image of how it actually functions, it does not look easy to optimize without changing the underlining principles of how it functions. Changing the way it functions would lead to whole new load of bugs which would require a lot of time to find and fix. I do not think that from a developer standpoint, it would be a good decision to try and change the algorithms and introduce a load of unknown bugs after the game release...

What surprises me is that critters actually create a large loading time at the start of the cycle regardless of their environment which makes me believe that they actually can be optimized. But I am having a hard time imagining what does it need to calculate that actually matters for each critter at that time.

Link to comment
Share on other sites

4 hours ago, Aelfled said:

There is no magic wand to miraculously make this faster, blaming Klei is silly.

- Instead of running the pathfinding routine 600 times per second, run it once per second.

- Instead of checking to see if the current destination is blocked 600 times per second, only check the next step.  Check the full path once every 2 or 3 seconds.

- Instead of looking for the best all possible paths to the destination, stop looking after 3 or 4 paths are found.

- Instead of reprioritizing a fill list tasks with pathfinding for every dupe 600 times per second, do once every 5 seconds.

There are many, many....paths... to optimization.

 

Link to comment
Share on other sites

1 hour ago, withers said:

- Instead of looking for the best all possible paths to the destination, stop looking after 3 or 4 paths are found.

Perhaps you know something I don't, and if so feel free to correct me. 

It is a very popular belief that ONI is using A* for it's pathfinding. If that is true, then the pathfinding will pick the "best" path that it is capable of on the first attempt each and every time that it runs. Also, it will always pick the same path given the same graph and start & end positions.

This is possible because the devs give each node on the graph a weight value that indicates it's relative speed of crossing that node, and using that weight value as well as direction to the target as heuristics when choosing which nodes to investigate. Poor navigation choices such as going in the wrong direction, or moving over slow terrain are completely ignored until the algorithm is forced to investigate them because it ran out of good choices. Completing a path to your target instantly ends all calculation because the path that gets completed first is always the one with the lowest possible 'score', and is therefore the most optimal path given the current weights on nodes in the graph.

The exception to that is that sometimes you can find optimizations to a path by running two passes. The first pass goes from the start to the end, and the second pass goes from the end to the start. This can correct some of the mistakes that A* can make navigating around complicated obstacles.

There is no point to running A* with more than two passes per update, and even that might be overkill if you don't really care about quirky navigation.

Any algorithm that actually calculates all possible paths and compares them to each other would be waaaaay too slow to be viable for use in a game with a graph the size of ONIs. Even one single navigating entity would cripple your performance. It would be orders of magnitude worse than A*.

Link to comment
Share on other sites

1 hour ago, withers said:

- Instead of running the pathfinding routine 600 times per second, run it once per second.

- Instead of checking to see if the current destination is blocked 600 times per second, only check the next step.  Check the full path once every 2 or 3 seconds.

- Instead of looking for the best all possible paths to the destination, stop looking after 3 or 4 paths are found.

- Instead of reprioritizing a fill list tasks with pathfinding for every dupe 600 times per second, do once every 5 seconds.

There are many, many....paths... to optimization.

My tests lead me to believe that the game does not even run those check on time basis. It seems to run a loop for every dupe that gets executed when your processor is free from other tasks. Which should be already better than any time based setups. The way to optimize it is to make some sort of mapping that saves some data about the state of the map and use the saved data to ease the calculations... Which is a difficult task, because it means almost inventing an ai that can deal with multiple different maps and make best marking solution for them... Considering that every map is different and players make poor design choices, the task is quite complicated. Also, it seems like oni already does it. So, optimizing the process becomes even more difficult.

Link to comment
Share on other sites

I am at cycle 395, Im over depathing every location to 1 route, disabled jet suits, optimized my hatch nursery to reduce my necessary hatch count to the minimum for the 36 dupes I feed. FPS was increased just a very little bit. I am going to sweep everything (partially done but going slow in this lag) and dump the stuff in a locked room maybe that will help a little.

Late game lag is terrible. Having 30-40 dupes, having the map explored should not be an issue for a game that encourages all that.

Link to comment
Share on other sites

1 minute ago, MorsDux said:

I am at cycle 395, Im over depathing every location to 1 route, disabled jet suits, optimized my hatch nursery to reduce my necessary hatch count to the minimum for the 36 dupes I feed. FPS was increased just a very little bit. I am going to sweep everything (partially done but going slow in this lag) and dump the stuff in a locked room maybe that will help a little.

Late game lag is terrible. Having 30-40 dupes, having the map explored should not be an issue for a game that encourages all that.

I am currently doing part 2 of the experiments, and I think I found even bigger culprit for lags than pathfinding, stay tuned :D

Link to comment
Share on other sites

Just now, MorsDux said:

I will refresh this page every 5 seconds!

Gonna take a few hours to finish.

7 minutes ago, MorsDux said:

I will refresh this page every 5 seconds!

Also, you could give me more ideas about what to test for performance tests by sharing your laggy save file after you fix all the routing issues.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...