The game future and FPS

[TehPlayer14]

So have you wondered if this game will run well in the future?

Well my guess is it won't because of one simple reason:

It doesn't utilize multiple cpu cores (Which would really increase fps if not double and ALSO PLAYABLE BIGGER SIZED MAPS)

Not to mention its important to utilize it early because it would require less code rewrite

To summary my post:

ONI is too heavy of a game to be run only one cpu core to run smoothly without lag spikes

So what's your opinion on FPS in the future of ONI?

[saltyteabag]

They've definitely made some improvements in FPS over the last couple months, but I've noticed the same thing.  It will only utilize one core (at least on my computer), which seems like like a poor design choice.

[Hanro50]

On 10/02/2018 at 11:17 PM, TehPlayer14 said:

So have you wondered if this game will run well in the future?

Well my guess is it won't because of one simple reason:

It doesn't utilize multiple cpu cores (Which would really increase fps if not double and ALSO PLAYABLE BIGGER SIZED MAPS)

Not to mention its important to utilize it early because it would require less code rewrite

To summary my post:

ONI is too heavy of a game to be run only one cpu core to run smoothly without lag spikes

So what's your opinion on FPS in the future of ONI?

My guess is they're first implementing a few new systems and as those systems develope they'll move some of them over to another thread 

 

Jet a again my knowledge of multi threading in unity is limited

[Oozinator]

On 11.2.2018 at 7:04 PM, saltyteabag said:

They've definitely made some improvements in FPS..

One noticeable "+FPS fix" was shrinking the map.

[Maciej75]

On 10.02.2018 at 10:17 PM, TehPlayer14 said:

It doesn't utilize multiple cpu cores

I once had 33% on 4 core CPU. Which means one core for ONI (25%) plus 8% Windows / background apps.

Things like physical simulations should, theoretically, be calculated efficiently by GPU - especially that I do not expect ONI to put heavy load on graphics. But this would be revolutionary change to game requiring new kind of devs and importing external libraries, so I do not expect this.

[Kabrute]

perhaps if someones were to offer them free external reference libraries that were easily integrated they would at the least put in a credit tag line

[TehPlayer14]

35 minutes ago, Maciej75 said:

I once had 33% on 4 core CPU. Which means one core for ONI (25%) plus 8% Windows / background apps.

Things like physical simulations should, theoretically, be calculated efficiently by GPU - especially that I do not expect ONI to put heavy load on graphics. But this would be revolutionary change to game requiring new kind of devs and importing external libraries, so I do not expect this.

Remember not everyone has gtx750ti's also GPU prices went up drastically also GPU acceleration never was a polished, also devs would need to code separate CUDA block for NVIDIA users and OPENCL for AMD (OPENCL is better with amd in terms of performance compared to Nvidia's OPENCL)

[2ki]

Multi-threading is hard to implement, requires lots of work, can possibly bring errors and we (end users) will most likely not notice the work but will notice the flaws. Also this game is still technically on alpha, different mechanics are still being implemented and there are changes in the core structure of the game, multi-threading usually is implemented when the game reaches beta (all the core game is done and the only thing that is lacking is polish/libraries/etc). Multi-threading (and 64bit for that matter) implementation doesn't mean that the game will run faster or anything, only means that it can access more resources, however after that you HAVE to again optimize the game to run using multi-threading, and (as the cherry on top) it usually causes loss of game stability that is VERY hard to figure why (can be physical/compatibility errors in your hardware for example).

Also you should know that except AAA companies, games rarely require or use multi-threading (notable exceptions of this rule are management games that have TONS of moving parts like Factorio) and those that have implemented it can show all the trouble they went through to do it.

[TehPlayer14]

3 hours ago, 2ki said:

Multi-threading is hard to implement, requires lots of work, can possibly bring errors and we (end users) will most likely not notice the work but will notice the flaws. Also this game is still technically on alpha, different mechanics are still being implemented and there are changes in the core structure of the game, multi-threading usually is implemented when the game reaches beta (all the core game is done and the only thing that is lacking is polish/libraries/etc). Multi-threading (and 64bit for that matter) implementation doesn't mean that the game will run faster or anything, only means that it can access more resources, however after that you HAVE to again optimize the game to run using multi-threading, and (as the cherry on top) it usually causes loss of game stability that is VERY hard to figure why (can be physical/compatibility errors in your hardware for example).

Also you should know that except AAA companies, games rarely require or use multi-threading (notable exceptions of this rule are management games that have TONS of moving parts like Factorio) and those that have implemented it can show all the trouble they went through to do it.

Multi-threading isn't hard to implement now, the game is in alpha yes but it should be done as early as possible to not have to rewrite whole code to queue code to different cpu cores

Quote

Multi-threading (and 64bit for that matter) implementation doesn't mean that the game will run faster or anything, only means that it can access more resources, however after that you HAVE to again optimize the game to run using multi-threading, and (as the cherry on top) it usually causes loss of game stability that is VERY hard to figure why (can be physical/compatibility errors in your hardware for example).

I've to bust you on this one pretty much if you have limited amount of resources there's a limit on how much you can optimize to a point where its a compromise how the game works (Like now ONI is sometimes not able to track some stuff anymore for example when dupe holds something it teleports and gets de-attached from him which is a optimization thing, It's very visible when the game is choking on low CPU power available)

For another example of poor performance but an optimized engine that's limited to 1 core is Source by VALVE (Mainly TF2 excluding CSGO[CSGO runs on 2 cores])

Yet Another example is now Minecraft the vanilla version with 1 core only it really struggles when trying to keep up with fps compared to Minecraft's Bedrock engine which is available on windows 10 or console versions of the game that use more than 1 cpu core (And they can pull of really high fps or stunning render distance which java edition couldn't just do because of 1 core)

64bit was a must because ONI would crash out of memory

The game stabillity isn't a issue look at modern titles that utilize multiple cores in API or even games (Doom vulkan) (Dying Light DIRECTX 11 multicore optimized) and even more

Games other than AAA titles do have multicore usage Minecraft Bedrock edition for example CSGO and other titles that I can't recall but I"M 100% old games from around 2006 utilized 2 cores no joke here

[Arash70]

I'd like to see CUDA optimizations, that would help most of the pc/laptop users.

[CobraA1]

I'm sure they'll look at their options when looking at optimizing their code. Also since we don't have access to the code itself, we can only guess as to how easy or difficult it is to divide up into more threads.

16 hours ago, TehPlayer14 said:

Multi-threading isn't hard to implement now

Multithreading comes with fun stuff like deadlocks, resource starvation, indeterminacy, etc. The problem with multithreading isn't spinning up new threads - that's the easy part. The hard part is figuring out how to change your code to support multiple threads without breaking anything.

[PhailRaptor]

The thing about multi-core processors is that not everyone has them.  Attempting to make a game run both ways (single-core and multi-core) at the same time requires a lot of redundancy, as well as some detection before hand to know which version to use/run on a given system.

I absolutely agree with you, though, that game designers need to start raising the "hardware floor" of their games.  We've reached a level of sophistication where ensuring everything can run on a toaster is like racing with a 3 legged horse.

22 hours ago, Oozinator said:

One noticeable "+FPS fix" was shrinking the map.

I would argue that this is not a fix.

[Kabrute]

used to think that was why there were options in the menus for some of the optional but more resource heavy bonus graphics.  Being able to turn off something like plant animations might be what someone needs to play the game.  Leaving these up to the end user, 4k or toaster, is one reason I loved modded FO4. On the map size issue I happen to agree but thankful it is easy to adjust in yaml, plain txt

[Oozinator]

2 minutes ago, PhailRaptor said:

I would argue that this is not a fix.

^^

[Saturnus]

12 minutes ago, PhailRaptor said:

I would argue that this is not a fix.

It would be a fix... if it was optional.

[clickrush]

TLDR; There are some misconeptions about programming in this thread. My suggestion is that people kind of give the programmers in ONI a break.

Performance Optimisation in General

Is the hardest part of programming period. The majority of programmers are not experts at this and have a few tricks up their sleeve that they are using regularly, but when you dig into problems that are less common you quickly start reading white papers that are full of hard math. People who are good at this typically work on stuff that is either a few abstraction layers lower (in this case it would be drivers or game engines and not the application on top of that), or deal with large scale systems and a ton of networking. We know that Klei has a bunch of smart people working on their games but we also know they aren't a big company, so my guess is that a programmer there often has multiple roles to fill than just programming algorithms and optimising the game itself.

Also optimisation is not always but often a tradeoff. For example you can optimise towards CPU usage by shifting complexity to memory usage and vice versa. But in the PC world every system is different, so one user might be experiencing a performance gain while the other one experiences a performance loss.

Concurrency & Multithreading

Multithreading (using multiple CPUs) is often getting tossed around as this generally applicable solution that magically makes everything more performant. Some in this thread even claim that it is somehow easy.

In fact programming concurrently is one of the hardest things people do in programming, because it not only heavily touches into performance but is also much more error prone than sequential code and forces you to use patterns and structures that dominate your whole code base, the more you use it.

There are modern languages which tackle this problem more elegantly such as Go or Clojure, but the big OO languages (C++, C#, Java) also introduced solutions and patterns to deal with concurrency. Still with all that help you dive into a whole new set of problems that are not only hard(er) to solve but also slow down your iteration speed, when developing software that isn't figured out from a technical design perspective. Many things might change, removed or added in the future, so going hard on optimisation and concurrency might not be the most feasable way to develop ONI.

The bottom line here is that concurrency comes with a large complexity (code) tradeoff, that you might or might not be able to deal with given your schedule.

APIs, Libraries and Unity

You also need to consider the environment the programmers work in. More often than not the libraries and APIs people use are not built with concurrency in mind. Another problem is that some APIs are optimised for programmer time and not for computation and I assume that Unity is an engine, that wants to cater towards small teams, so a lot of their solutions are cookie cutter and already on a high abstraction level.

I read somewhere that ONI is built on Unity. I haven't personally done a ton of stuff with Unity but just a quick google search already reveals that the engine itself doesn't have a thread safe API. Then on top of that I assume that Klei uses Unity based libraries that also aren't. So even though it is technically possible to have concurrent calculations there (since it has a C# API) you kind of have to restrict them in a way so they don't access these libraries and Unity itself directly but still have optimisation value. This can restrict what you can do and what you can't, especially if we are dealing with closed source code bases that you cannot patch to meet your individual requirements.

[TehPlayer14]

1 hour ago, clickrush said:

TLDR; There are some misconeptions about programming in this thread. My suggestion is that people kind of give the programmers in ONI a break.

Performance Optimisation in General

Is the hardest part of programming period. The majority of programmers are not experts at this and have a few tricks up their sleeve that they are using regularly, but when you dig into problems that are less common you quickly start reading white papers that are full of hard math. People who are good at this typically work on stuff that is either a few abstraction layers lower (in this case it would be drivers or game engines and not the application on top of that), or deal with large scale systems and a ton of networking. We know that Klei has a bunch of smart people working on their games but we also know they aren't a big company, so my guess is that a programmer there often has multiple roles to fill than just programming algorithms and optimising the game itself.

Also optimisation is not always but often a tradeoff. For example you can optimise towards CPU usage by shifting complexity to memory usage and vice versa. But in the PC world every system is different, so one user might be experiencing a performance gain while the other one experiences a performance loss.

Concurrency & Multithreading

Multithreading (using multiple CPUs) is often getting tossed around as this generally applicable solution that magically makes everything more performant. Some in this thread even claim that it is somehow easy.

In fact programming concurrently is one of the hardest things people do in programming, because it not only heavily touches into performance but is also much more error prone than sequential code and forces you to use patterns and structures that dominate your whole code base, the more you use it.

There are modern languages which tackle this problem more elegantly such as Go or Clojure, but the big OO languages (C++, C#, Java) also introduced solutions and patterns to deal with concurrency. Still with all that help you dive into a whole new set of problems that are not only hard(er) to solve but also slow down your iteration speed, when developing software that isn't figured out from a technical design perspective. Many things might change, removed or added in the future, so going hard on optimisation and concurrency might not be the most feasable way to develop ONI.

The bottom line here is that concurrency comes with a large complexity (code) tradeoff, that you might or might not be able to deal with given your schedule.

APIs, Libraries and Unity

You also need to consider the environment the programmers work in. More often than not the libraries and APIs people use are not built with concurrency in mind. Another problem is that some APIs are optimised for programmer time and not for computation and I assume that Unity is an engine, that wants to cater towards small teams, so a lot of their solutions are cookie cutter and already on a high abstraction level.

I read somewhere that ONI is built on Unity. I haven't personally done a ton of stuff with Unity but just a quick google search already reveals that the engine itself doesn't have a thread safe API. Then on top of that I assume that Klei uses Unity based libraries that also aren't. So even though it is technically possible to have concurrent calculations there (since it has a C# API) you kind of have to restrict them in a way so they don't access these libraries and Unity itself directly but still have optimisation value. This can restrict what you can do and what you can't, especially if we are dealing with closed source code bases that you cannot patch to meet your individual requirements.

Yeah pretty much however ClickRush, but there's one thing that just a mega progress block for ONI that's called a physical limit on raw per core clock speed (Because if there will be more content will mean more cpu power required) and through the last years the clock rate of cpu's didn't increase much if at all however core count on the other had went up significantly and I wouldn't like a situation of games/devs that tell you, You need stronger cpu (Either game poorly optimized or written) than gaming one that's just ugh what I'm going to buy the most expensive enthusiast CPU just to get that 1 extra GHz with other useless cores or overclock it with liquid hydrogen cooling? [Also not to mention fast forwarding is a pain with 19 dupes and a medium colony]

Also well optimized game will work under minimal requirements (Dying Light is good example but its an AAA game)

That's worrying...

But yeah devs should take their time and probably instead of making new content rethink the amount of needed resources for ONI to run smoothly on gaming rig

[Moggles]

Would it be too much to ask if the game could not hitch completely for a second when writing the save file at the start of a cycle. I don't understand why it appears to block the main thread completely.

I have had the same issue with Don't Starve at the start of a day on four different systems over many years. I even see it on streams and have grown accustomed to seeing the game freeze.

Surely this annoys other people.

[QuQuasar]

Thank you clickrush. As the developer/programmer of a simulation game myself (obligatory plug: http://www.speciesgame.com/) I concur with everything you said.
         
I've tried multithreading games. It isn't easy, and it sure as heck isn't something you do while you're still adding core functionality. 
         
That's not to say Klei shouldn't be considering it. I do hope they're building the game's architecture in a way that will make multi-threading easier in the future. But actually multi-threading an early access game? Especially one like ONI, where every system interlocks with every other system?
         
Urgh, no. If you think ONI has bugs now, wait till you see what happens when debugging it involves working out not just when a thing happened in a sequence that's called dozens of times a second, but on which thread it happened and when it could have happened in relation to everything happening concurrently dozens of times a second.
         
Premature optimization is the root of all evil. Don't ask Klei to implement one of the most difficult and side-effect prone forms of optimization out there before they're even finished all the core systems.

[CobraA1]

15 hours ago, TehPlayer14 said:

Yeah pretty much however ClickRush, but there's one thing that just a mega progress block for ONI that's called a physical limit on raw per core clock speed (Because if there will be more content will mean more cpu power required) and through the last years the clock rate of cpu's didn't increase much if at all however core count on the other had went up significantly and I wouldn't like a situation of games/devs that tell you, You need stronger cpu (Either game poorly optimized or written) than gaming one that's just ugh what I'm going to buy the most expensive enthusiast CPU just to get that 1 extra GHz with other useless cores or overclock it with liquid hydrogen cooling? [Also not to mention fast forwarding is a pain with 19 dupes and a medium colony]

Also well optimized game will work under minimal requirements (Dying Light is good example but its an AAA game)

That's worrying...

But yeah devs should take their time and probably instead of making new content rethink the amount of needed resources for ONI to run smoothly on gaming rig

There is likely to be plenty of optimization room even on a single core. They'll get it figured out eventually, I am sure. No, you probably won't need a crazy overclocked system to run the game.

Also - are you running the game at the normal max speed, or are you using the debug trick? Using the debug trick is definitely not going to run nice; the game isn't really designed to run at that speed to begin with.

4 hours ago, Moggles said:

Would it be too much to ask if the game could not hitch completely for a second when writing the save file at the start of a cycle. I don't understand why it appears to block the main thread completely.

Nope! That's a fixable problem. Interestingly enough, the solution is likely to be to put the code that saves the game into a separate thread.

[FutureJohny]

As developper myself I believe going overboard with optimization too early can be harmfull to the game. My main Oil Update base seems to get few frames every major update and I am OK with this. As long as the updates do not needlesly slow the game they are doing their job right. Of couse if they do major change to the physics calculation, then some frames might be lost. 

I have issues though with the start/end time ratio.

Save time is actually quite fast and for largest bases takes mere seconds.

I partially understand loading time, even if it seems a bit long compared to save time. It at least seems proportional to the explored area, item on the map, etc.

What I do not understand though is game shutdown time. (exiting from game to OS) It does not even save the game, but it just does something for nearly a minute.

I just gave up on it and just kill the game with task manager once I save.

Are you also experiencing this long shutdown time?

[PhailRaptor]

1 hour ago, FutureJohny said:

Are you also experiencing this long shutdown time?

I mean, yes, but that's not exactly unusual.  Everything from Civ Series to Empire at War to Starcraft does that for me.

[Master Miner]

On 14.2.2018 at 12:18 PM, clickrush said:

TLDR; There are some misconeptions about programming in this thread. My suggestion is that people kind of give the programmers in ONI a break.

I agree with most of what you've written above, I agree to give the programmers "a break" - but, in this aspect, not to software developers nor managers / project leaders.

Quality of developed software depends greatly upon planning, and multi-threading approach and performance is something that needs to be planned in advance and implemented according to the plan. Quality of planning depends heavily on knowledge and even more on experience. It is a bad idea to first implement and test everything in single thread and then start to think about multi-threading.

Typically, managers will make some pressure and programmers will rush to code without proper planning. This approach is viable if there is lack of experience (can't plan if you don't know how), but one does that to gather experience and make prototypes and proof of concepts for critical components and aspects (performance is one of them). Not with expectation to get quality software. Software development can start after such cycle.

ONI is a game that simply calls for multi-threading. There is so much running concurrently and largely independently. Path-finding algorithms and scheduling algorithms are school examples for use of multi-threading - "divide and conquer". Calculations regarding each pipe system or electrical circuit is independent of each other and can be done in parallel, then growth of plants, gasses, fluids, etc.

When debugging, one can always restrict the game to single thread / serialize execution and compare the results with multi-threaded runs.

2D game with 256x384 squares uses over 7 GiB RAM and 100% of one core, takes ages to load and is barely playable on an above-average contemporary desktop PC (16 GiB RAM, 4x4GHz CPU, fast SSD, dedicated graphics card)?
C'mon....

And yes, when you finish playing, save the game and click on "Quit to desktop" and "OK" you either have to kill its process or you can go for a drink before you can use the computer again...

That's just not what I would expect.

[TehPlayer14]

Yeah the Quit to desktop/menu is kinda annoying especially when modding or messing around, perhaps I need workaround for that

[2ki]

On 2/13/2018 at 12:33 PM, TehPlayer14 said:

Multi-threading isn't hard to implement now, the game is in alpha yes but it should be done as early as possible to not have to rewrite whole code to queue code to different cpu cores

64bit was a must because ONI would crash out of memory

The game stabillity isn't a issue look at modern titles that utilize multiple cores in API or even games (Doom vulkan) (Dying Light DIRECTX 11 multicore optimized) and even more

The difficulty to implement multi-threading can be argued (haven't touched in the last 3/4 years) however is not easy nor is something it can be done in a few weeks with a small team. I do agree that the sooner it is done the better (the new code won't have to be changed/optimized) however is not easy to do that if the are still adding or fixing content.

64bit IS necesary for most games today (ONI and other management games even more), they need to track tons of stuff and they need the extra resources.

I do agree with TehPlayer14 that multi-threading is needed and Master Miner is right about planning, however, as of right now Klei seems to be focusing on releasing the new content and balancing the game itself, if they were to suddenly implement multi threading they would need at least 1 update time to make the changes (i'm guessing more) and stop the regular update releases.

Also I don't have an incredible computer (i5 3.5gz and 4x4 gb ram) and never had issues (well having to wait 2/3 minutes to create a 512x512 map) however i never exceeded turn 200 nor made uber bases so maybe that's why.