Tips for improving game running speed

[David]

Tips for improving game running speed
When you are viewing the firm detail window or the Information Center, the game does not have to update the city view underneath the information window every frame. (You will notice that the cars are not moving.) So always open an information window if possible. This could save a lot of graphic processing time especially when the city is packed with buildings.

Among the various types of screens on the Information Center, some will require more computer processing power to display than the others. The Farmer's Guide is the one that requires the least amount of processing power. So if you want the game time to pass without needing to have any interaction with the UI, you could just open Farmer's Guide (hotkey: F2) and the game time will advance much faster.

For more information concerning game performance, please see this related post: viewtopic.php?f=14&t=7198

[ncmagus]

I did notice the game is only using one core on the CPU. Those days, CPU improve the number of core instead of the speed of a specific core. I think you could get a lot more performance late-game if you found a way to implement multi-threading (If each opponent is running as a task, it might be possible to dispatch tasks to different thread without to much work)

[David]

I did notice the game is only using one core on the CPU. Those days, CPU improve the number of core instead of the speed of a specific core. I think you could get a lot more performance late-game if you found a way to implement multi-threading (If each opponent is running as a task, it might be possible to dispatch tasks to different thread without to much work)

How would you suggest to resolve the problem that one opponent depends on other opponents' data to make decisions and having all opponents making changes to the game data in parallel will potentially corrupt each other's data?

[mdemircan2]

güzel bir soru...

[ncmagus]

Of course, without knowing exactly how the game works, i can only assume things. So let's assume you compute several different solution and give each of them a score, and then you pick the best one.
In such a situation, i believe you could dispatch to several thread the processing part for every opponent. Then, when all solution have been found, one thread will gather all of those and will then choose the best solution which can be applied.

Let's say you have 3 opponents, and you generate a list of 5 possible outcome for each of them. You can either use 3 threads (one per opponent) or 5 threads (one by "type of outcome", let's say "evaluate building a farm").

Then, on the final thread, you look at the opponent 1, and choose the best solution for him. then the thread moves on to the next opponent and choose the best solution that is still possible, and so on.
Of course, once you processed the first opponent, there might be new solution for the second opponent, but that's how life works : You take decision based on incomplete data. If the opponent want to buy that specific building and it was bought by the previous opponent, then you move to the next best solution.
You could also "try to readjust" the solution: the first opponent bought the terrain you were hoping to buy, maybe there's one nearby that is "good enough".

To avoid having a bias toward the first opponent (he always have the first choice), you could process them (on the final thread) in different order every time.

I hope what i'm trying to say is understandable.

Also, you mention opening a guide might improve speed because you don't have to handle thing behind the guide window. Maybe that's the type of optimisation that could be pushed to a different thread ? (one to process the UI and the other to process opponent's decision)

Or maybe take a shortcut : if drawing the little moving cars take too much processing power, having an option to have less cars shown could be interesting for people with lower cpu. In the game development world, people seem to use a lot of tricks to minimize processing time here and there. Maybe you could find some nice tricks in the "game programming gems" book series (or other similar book)

I know ! it's easy to say something, it's harder to execute it

[qzd1989]

支持 @ncmagus

如果不改进游戏速度,基本也就只能玩几小时,然后就会因为游戏速度过慢而没法继续下去

这是一个单机游戏,你们也没有计划将它改成网络游戏,所以有没有人修改游戏数据并不是那么重要.

如果不改进游戏速度,再多的新功能新玩法上来,也没法尽兴体验到~

it's a big problem.

[David]

支持 @ncmagus

如果不改进游戏速度,基本也就只能玩几小时,然后就会因为游戏速度过慢而没法继续下去

这是一个单机游戏,你们也没有计划将它改成网络游戏,所以有没有人修改游戏数据并不是那么重要.

如果不改进游戏速度,再多的新功能新玩法上来,也没法尽兴体验到~

it's a big problem.

You may send us your save game file that you think has the slowdown problem and we will check it for you.

[David]

Of course, without knowing exactly how the game works, i can only assume things. So let's assume you compute several different solution and give each of them a score, and then you pick the best one.
In such a situation, i believe you could dispatch to several thread the processing part for every opponent. Then, when all solution have been found, one thread will gather all of those and will then choose the best solution which can be applied.

Let's say you have 3 opponents, and you generate a list of 5 possible outcome for each of them. You can either use 3 threads (one per opponent) or 5 threads (one by "type of outcome", let's say "evaluate building a farm").

Then, on the final thread, you look at the opponent 1, and choose the best solution for him. then the thread moves on to the next opponent and choose the best solution that is still possible, and so on.
Of course, once you processed the first opponent, there might be new solution for the second opponent, but that's how life works : You take decision based on incomplete data. If the opponent want to buy that specific building and it was bought by the previous opponent, then you move to the next best solution.
You could also "try to readjust" the solution: the first opponent bought the terrain you were hoping to buy, maybe there's one nearby that is "good enough".

To avoid having a bias toward the first opponent (he always have the first choice), you could process them (on the final thread) in different order every time.

I hope what i'm trying to say is understandable.

Also, you mention opening a guide might improve speed because you don't have to handle thing behind the guide window. Maybe that's the type of optimisation that could be pushed to a different thread ? (one to process the UI and the other to process opponent's decision)

Or maybe take a shortcut : if drawing the little moving cars take too much processing power, having an option to have less cars shown could be interesting for people with lower cpu. In the game development world, people seem to use a lot of tricks to minimize processing time here and there. Maybe you could find some nice tricks in the "game programming gems" book series (or other similar book)

I know ! it's easy to say something, it's harder to execute it

I was reading a blog article from the developer of the widely popular game Banished and found him writing something about parallel processing. Thought I would post it here for your reference:

"While a lot of other current engines are running entity updates in parallel, I’m not choosing this route. Threading updates where multiple entities depend on each other is hard. Really hard. The goal is not to use any locks or thread synchronization. This requires really breaking up updates into small chunks, limited or no direct access to other entity data, sending messages to other entities, and waiting for responses. This makes designing the code hard, makes it hard to debug, and hard to modify later if you forget whats going on."

Full article: (Go to the topic "Performance" )
http://www.shiningrocksoftware.com/

[brdxman]

@David Totally agree with point about multiple thread coding, its tough to get right and to get actual improvements in performance...

[Neckername]

Multithreading in games, to be pulled off correctly needs to be implemented from the start of engine development. Post development updates can only go so far before drastically affecting compatibility with existing products and code. Thus also impacting the gain of performance and in some cases, reducing performance. This is not to say it cannot be done; It has in many newer games. But at the cost of significant engine complexity. This can be reduced by compartmentalizing the functions of the engine and layering their importance correctly in terms of resource usage distribution.

If you look at engines like Unreal Engine 4 that have source code. You can get a good view of the above comments in action. You can then split things up into multiple threads such as a game thread, render thread, AI thread, etc. Then on each thread you prioritize the individual compartments of engine interactions for each thread. For example, your game thread may have poll inputs, animation, and physics data. Then your render thread may have postFX, forward passes, object/sprite culling, and readying structures for view. Your AI thread may have game data pulls, input updates, input processing, output comparison, etc.

Next is where the engine actually gets complicated. The engine then pulls all of this into a Synchronization layer. The massive difference this layer makes versus rengular single thread or dual thread games is that it can delegate incoming data to multiple "worker" threads that run in parallel with the threads I mentioned above. Then the layer uses specific instruction sets within the engine to dictate synchronization and worker characteristics. Then there is usually thread flow control that runs and controls things above the synchronization instruciton sets.

Most engines implement this in one way or another from the ground up or via updates. The part that is complicated about the Sync layer is that API calls can only be made from one thread. So prioritizing with no error is a must to maintain the expected gains that come from implementing multithreading effectively.