Optimisation - a dirty little secret?

[Muggins]

Optimisation seems like one of the few areas that the devs are reluctant to talk about and I'm honestly not sure why. Maybe because it's not a tangible and quantifiable objective, or maybe it's because it's not achievable considering the core mechanics of the game?! But why not have an open conversation about it regardless? I've seen many people asking about it here on the forums and also during the live streams but it gets glossed over. 

For me the game is unplayable after a certain point so I've had to shelve it for the time being, but obviously I'm curious about the future.

I love this game and I love Klei so please don't take this as an attack.

[sixsevensix]

I think they may be getting in the essential game mechanics before focusing too much on optimizing the game. If you are going to be constantly adding new material that may break your old optimization, it doesn't make sense to spend too much time on fixing something you are going to break in the next upgrade. Major optimization will most likely be in their later in development. Right now it is best (in my eyes anyways) to focus on getting all the major planned features in, optimizing each one some as they are implemented. Then as a whole crackdown and optimize all the features in the final stages. If anything we would have to make a decision:

Do we want the devs to keep adding new content each month, or delay new upgrades and spend more time optimizing? Instead of every 4 weeks for an upgrade, it would be 8 or 12. That would most likely be the trade off. For me, I'll take a slightly buggy game with consistently new content.

[t0panka]

+1 to this

@sixsevensix yeah updates are nice BUT lets take Oil update. It is "late game" stuff and since "late game" lags like crazy we can't even play it properly. So they now release another update lets say something with lava. When you get to lava your game will be already unplayable so there is no point of updating if we cant even play it properly right?

Anyway i am little bit worried that the base game is already badly optimised. Shouldn't this be figured out before they start adding more and more features? 

[sixsevensix]

@t0panka

But remember they may spend all this time optimizing core mechanics so the game can be played now. What happens when they go to add the next feature on the list? Many of the mechanics they have added with each update are integrated into most other systems. Just the new room system alone most likely had to be integrated into the system of how a tile is defined. They have to weigh the cost and benefit of optimizing now versus the chance that all that optimization may be out the window the next time they add something.

[t0panka]

Well i don't know how all this works and Klei knows best but i would really like some word about this from them because i didnt find anything on forums

Lets say the game is 50% optimised which is really bad as we all know. Can they in the end make the other 50%? I don't think so :/ They can make it 20% better or so but its is HUGE difference IMO not to be taken seriously

Cycle 100 starts to lag like crazy but we want cycle 1000 right? I just hope they think about late game players not just day 1 people like DST :/

[Muggins]

2 hours ago, t0panka said:

Well i don't know how all this works and Klei knows best but i would really like some word about this from them because i didnt find anything on forums

Lets say the game is 50% optimised which is really bad as we all know. Can they in the end make the other 50%? I don't think so :/ They can make it 20% better or so but its is HUGE difference IMO not to be taken seriously

Cycle 100 starts to lag like crazy but we want cycle 1000 right? I just hope they think about late game players not just day 1 people like DST :/

This is exactly my point. Regardless of when or if they will or can optimise the game, a bit of transparency about it would be very much appreciated. 

[Erasmus Crowley]

9 minutes ago, six_demon_bag said:

This is exactly my point. Regardless of when or if they will or can optimise the game, a bit of transparency about it would be very much appreciated. 

Game devs, especially at small studios, are constantly operating at the edge of what they are capable of achieving. It's hard to even get a game to work the way you want it to. However, as you build the game, you usually make it as efficient as you possibly can in the hope that it will run well when you're done.

The devs almost certainly don't have a list of things they could do to make the game run better, because if they knew something like that would help, they would have implemented that as they were creating those features in the first place. It's not that they're avoiding doing "optimization things" because they want to make new things, it's more that they're can't check things off the optimiazation list, because that list doesn't exist.

Optimization is hard, because you don't know what you are looking for, and there may not be any way to actually make it better. You just have to stare at profilers, trace code, walk through with a debugger, hoping for a EUREKA! moment where you can simplify an equation, or replace a bad data structure, or something that will have a noticeable impact.

If a dev said, "I'm going to take this week to work on optimization", there is the very real chance that at the end of the week, the game will be exactly the same, you'll just have a much more frustrated and bored dev.

In a way, a game is always 100% optimized, because there is no way to know (unless a dev knowingly made a bad choice during early feature prototyping), if there is anything to do that would be better.

Hopefully that illustrates that there is nothing to be transparent about, because no one knows what needs to be done, and no one knows if they'll ever find anything that might help.

[Muggins]

3 minutes ago, Erasmus Crowley said:

In a way, a game is always 100% optimized, because there is no way to know (unless a dev knowingly made a bad choice during early feature prototyping), if there is anything to do that would be better.

This makes complete sense and it's something I was considering although optimistically I was, and still am, hoping that coding was like doing a rough draft first and then going back over it to focus on each part more vigorously. 

If what you say is the case then it makes sense that the devs believe the best option is to not talk about it at all. However, I would still appreciate some communication on the matter if only to satisfy my curiosity.

[Le0n1des]

28 minutes ago, Erasmus Crowley said:

Optimization is hard, because you don't know what you are looking for, and there may not be any way to actually make it better. You just have to stare at profilers, trace code, walk through with a debugger, hoping for a EUREKA! moment where you can simplify an equation, or replace a bad data structure, or something that will have a noticeable impact.

Well, yes and no... Once you recognize the bottlenecks (in case of ONI - my guess is actions scheduling, path mapping, gas movement simulation) and see if there is some inefficient algorithm taking place - optimisation is quite feasible.

[Erasmus Crowley]

14 minutes ago, Le0n1des said:

Well, yes and no... Once you recognize the bottlenecks (in case of ONI - my guess is actions scheduling, path mapping, gas movement simulation) and see if there is some inefficient algorithm taking place - optimisation is quite feasible.

You can make informed guesses about where optimizations might be possible, sure.

Still, you never really know what is actually creating a bottleneck until you spend some time with the profiler, otherwise you're just guessing and you'll almost certainly guess wrong.

For example, while playing the game, you might see that the storage boxes are causing lag issues, but on investigation you discover that the true source of the problem is that it's triggering excessive updates of the material amount text in the materials list of the GUI and the cause of the lag is due to the text redrawing. You could add some update limiter and value cacheing to the text control and the problem vanishes, because the problem was never the storage boxes, it was the text control the whole time, but the problem only manifested in combination with the storage boxes.

That's all I was saying, optimization by it's nature is unpredictable. It's impossible for devs to make any predictions about it with anything resembling accuracy.

[WanderingKid]

28 minutes ago, six_demon_bag said:

This makes complete sense and it's something I was considering although optimistically I was, and still am, hoping that coding was like doing a rough draft first and then going back over it to focus on each part more vigorously. 

Being a SQL Developer, we're constantly watching for algorithms that are taking too long or when a complaint comes in that 'Something takes too long'.  Too long of course being variable depending on the user.

Sure, sometimes we can find alternate methods to improve older code with new techniques, or find code written by a newbie that was just bad according to known optimizations simply because they're new and either forgot or didn't think about it.  However, a lot of times what we end up doing is writing it up as COB... Cost of Doing Business.  Noone experienced writes crap code to prototype because you never, ever, ever get to go back and look at it again unless it's crashing the system.  And Klei is experienced, so I doubt that's the issue.

Now, it IS possible once you're done prototyping you realize you've set up the core threads or data tables or indexing or what not sideways to what you really ended up with at the end, so you rework it then, when you're done end to end and you can work backwards from the final goal looking for the slowdown (well, really you cut it in half and work up or down, but you get the idea).  Unfortunately, though, it's not like a term paper or something where you can simply clean up sections.  The closer you get to the root coding or structures, the more likely you end up blowing up a section of the system downstream that you weren't even aware of, nevermind know how you broke it... so you make sure it's as clean as possible right out of the gate.

[Muggins]

@WanderingKid

Thanks for explaining that. So in the case of not being able to optimise ONI any further, in your experience would it be possible to have a setting for a varying degree of complexity if some people would be happy to have less realistic simulations, or would this be like re-coding everything for each "realism" setting?

eg. Temperature/gases etc are calculated every 4 clicks instead of every click, or temperature looks at an average of all materials in a container instead of each individual one. (clearly I have no idea what I'm talkng about.)

[WanderingKid]

8 minutes ago, six_demon_bag said:

Thanks for explaining that. So in the case of not being able to optimise ONI any further, in your experience would it be possible to have a setting for a varying degree of complexity if some people would be happy to have less realistic simulations, or would this be like re-coding everything for each "realism" setting?

In honesty, I'm not sure.  In theory, your idea would be a modification of the timers being called in the game loop, the overall function that's called to call all the underlying components at certain intervals.  It would depend on the depth of adjustment to the simulation and other factors. 

I have not decompiled the code to the game in any way, so I have absolutely no idea the complexity depth of such a request. My expertise lies in data structures not app code, though I have a passing familiarity with it from my background and self training to better work with the front end devs.  It could be simply changing the timer, it could be rewriting the core table of a snowflake warehouse.  I simply don't know.

[Octyabr]

Spoiler

Rules of Optimization:
Rule 1: Don’t do it.
Rule 2: (for experts only) Don’t do it yet. [That is, not until you have a perfectly clear and unoptimized solution.]

I've put emphasis on "perfectly clear" because the way two major elements of the game are managed: Heat and gas flow. Sure, the current algorithms do what they should (up to a point), but are not the solution to those problems. (specially when radiation is totally missing)

As I see it, there is no point of optimizing what would/will be replaced.

[GrindThisGame]

It would be nice if they used more than 1 cpu core. It's probably going to be a lot of work to make it use all cores or be multi-threaded. Maybe best to work on that after the core game mechanics are set though. Splitting all dupe related calculations over all the cores (or threads) might be one way to do it. If they were able to split the map into smaller chunks that could be allocated to threads that may also help. I'm guessing it's not an easy problem to solve though.

[sixsevensix]

1 hour ago, Octyabr said:

  Reveal hidden contents

Rules of Optimization:
Rule 1: Don’t do it.
Rule 2: (for experts only) Don’t do it yet. [That is, not until you have a perfectly clear and unoptimized solution.]

I've put emphasis on "perfectly clear" because the way two major elements of the game are managed: Heat and gas flow. Sure, the current algorithms do what they should (up to a point), but are not the solution to those problems. (specially when radiation is totally missing)

As I see it, there is no point of optimizing what would/will be replaced.

This was the point I was trying to make earlier in the thread. Optimization is something you will most likely be undoing if you are constantly adding new features. Unless you are a god at software architecture and have optimizations built into your design schematic you are going to constantly be changing and tweaking with each iteration until you have a final version that can be fully polished. 

[The Plum Gate]

Well, they're taking 6 weeks to do something. I'm hoping they improve the debugger ui. Maybe make some changes to how RWG is laid out ( in the sense of folders ) ..there could be some changes made here that improve the ability of worldmakers to create some unique worlds without imposing too much on the world maker.

[Coolthulhu]

9 hours ago, Erasmus Crowley said:

In a way, a game is always 100% optimized, because there is no way to know (unless a dev knowingly made a bad choice during early feature prototyping), if there is anything to do that would be better.

I disagree about this part. Simplifying the code, because optimization would be too much work for little gain, is the most common way of creating new software. First get it to work, then get it to work fast.

Take pathfinding for example. There are many well known and documented methods to optimize pathfinding that would speed up the calculations here, possibly by an order of magnitude. I'd still expect the game to use plain A*, because pathfinding for ~10 entities is no big deal performance-wise, unless the map was huge.

The current biggest sources of lag are most likely: temperature calculations, germ calculations (pretty similar to temperature, but less extensive), and the memory leak.  But there most certainly are tons of little tweaks all over the place that no one does simply because they have more important things to worry about.

[Botaxalim]

From my observation, ONI surely not using all my proccessor, alt tab from game is fast, like internet browser did. I hope they update/modify the core engine in their game to utilize proccesor more, i aware the game eat more ram than cpu or gpu. Anyone know what engine they use?same like DST or unity....

[The Plum Gate]

59 minutes ago, Botaxalim said:

From my observation, ONI surely not using all my proccessor, alt tab from game is fast, like internet browser did. I hope they update/modify the core engine in their game to utilize proccesor more, i aware the game eat more ram than cpu or gpu. Anyone know what engine they use?same like DST or unity....

It's Unity.

I Think the problem with lag has to do with the stepped simulation - they could probably break-step and get more done without as much hitching - do some aspect at interval, some other other aspect after that

I think all the buildings' quirky animations are great, but people spam buildings...I, for one, wouldn't mind having an option to turn animations off and leave indicators on for things like batteries... There's not much in the way of graphical options just yet though.