What is wrong with the game performance ???? Need help!!!

[saclet]

Because I still can play BF 3 at Ultra setting without any freeze or lag, only this game is acting weird so far.

It's not acting weird. When you're playing BF3 your cpu is not doing much at all - almost all of the game is off-loaded to your graphics card because the game is little more than polygons, collisions and physics. PA is far more CPU intensive [and complex] than BF3 because caculating the needs, paths, actions and interactions of all your prisoners _every frame_ is very expensive in terms of CPU cycles (stuff not handled by your graphics card). In fact, i'd be surprised if this isn't [currently] an exponential operation (in algorithm terms O(n^2)) every frame. This means if you have 10 prisoners there are ~100 calculations* per frame, but if there are 100 prisoners there are 10,000 calculations per frame.

In your instance you have 340 occupants (prisoners + staff + guards). That's 115,600 calculations per frame. Remembering ~30 frames per second is 'playable', then you have nearly 3.5 million calculations per second just to move your prisoners around the screen. Take that, BF3!





* 'operations' is probably a better term to use in place of calculations.


edit: It's clear your main problem is too many people in your prison. The first thing I'd do is fire half of your staff, at the minimum. 100 guards for 150 prisoners is pointless when 20-30 would do the same job. Similarly with your other staff. There's no real need for more than 10 workers, two janitors, two gardeners and your offices. That's ~20 non-guard staff total.

Shove these new figures into the calculations above and you now have 140 prisoners + 30 guards (still over-kill) + 20 staff = 190 occupants. That's now 36,100 calculations per frame. Therefore your frame rate should improve by more than 300% ( (115600/36100) * 100) without adversely affecting your prison. *fingers crossed*

You made very good point . It seem like this alpha similar to Guild Wars 2 beta when it was using CPU instead of GPU which made me feel like I'm playing game on some low end laptop. I just hope at the final release, PA will be like GW 2 when finally it will use GPU more than CPU , and we need a playable game, enjoyable, not the game make us feel like we are torture ourselves and that's my point for all of this. Talking about number of guards and staff, it sound like playing starcraft suppose prisoners are zerglings and guards as marines so in order to do as you said I will need a lot of doctors in order to keep my guards from raging prisoners who are ready to rape them.

[paktsardines]

Let me know how you go when you reduce the number of staff in your prison. It is likely your framerate will increase by considerably more than 300%. Will be interested to hear.

[shovat]

My guess is if you upgraded to 16GB of ram performance would increase. However, I have 16GB of ram and once I cross the ~90 prisoner threshold there is a noticeable decrease in performance. Mostly in the fact that it takes a while for some sprites to do what they intend to do, as an example 1 in game hour for a prisoner to go from intending to push a laundry cart to actually pushing it, Workers standing around not doing anything, and prisoners taking a seat on a bench while mopping because the mopping job took to long to finish so they sat down while mopping. Which of course causes an error which does not fix itself until session change (work to free time) or I take apart the bench.

I'm afraid there is no cure atm as far as I know.

edit: running windows 8 because I'm to lazy to install windows 7, accidentally deleted the line >.<

Version 6.2.9200 Build 9200
OS Manufacturer Microsoft Corporation
System Name BILLY
System Manufacturer Gigabyte Technology Co., Ltd.
System Model GA-78LMT-USB3
System Type x64-based PC
System SKU
Processor AMD FX(tm)-8120 Eight-Core Processor, 3100 Mhz, 4 Core(s), 8 Logical Processor(s)
BIOS Version/Date Award Software International, Inc. F2, 8/10/2012
SMBIOS Version 2.4
Time Zone Eastern Daylight Time
Installed Physical Memory (RAM) 16.0 GB
Total Physical Memory 16.0 GB
Available Physical Memory 14.3 GB
Total Virtual Memory 18.2 GB
Available Virtual Memory 16.0 GB

My specs for comparison.

I don't think increase amount of ram will help because right now I'm playing my saved file which has medium map with a very large prison covers all corners of the map, there are a big riot and fires at the same time, people are being burned alive (including 5 family visitors) it's very weird that fires kill everyone except prisoners, guards and doctors. But right now this game only use 448 MB Ram.

RAM is the cheapest and most effective way to improve overall computer performance period dot end of story. It will always help because it gives your computer a bigger brain to think with, until the power goes out then it remembers nothing.

RAM is cheap, it's true. But what is the point of "bigger brain" if you will never use it? Since almost every games are 32 bit so technically they can't use more than 4GB Ram. Like a year ago someone posted a mod which made Skyrim can use more than 4 GB, when it was using no more than 2GB, then after installing the mod, Skyrim always crash every time it use more than 2.5 GB of ram. However buying good Ram with good speed will help a lot, but my Ram is 8 GB (2x 4GB) with 2100 mhz, so I don't really need to care about that section atm. Because I still can play BF 3 at Ultra setting without any freeze or lag, only this game is acting weird so far.

Yeah sorry I should of been more elegant in my reasoning like mr packetofsardines. He covered the bases rather well on why this game has lag issues, the problems you'll run in to for lagging will be significantly (making an assumption) different than when you play BF 3. Your graphics card probably doesn't even cycle it's fan much with PA at least it doesn't for me. Its the CPU fan that starts going nuts. That and with online games some calculations can be (are) sluffed off to servers taking even more load off your CPU. If you've ever played dwarf fortress or know someone who has you'll know that even in a low graphics (ascii art) game if you add enough calculations (independent AI like this game) your computer performance hits bottom. Luckily it isn't all doom and gloom and I see no reason why they shouldn't be able to smooth out gameplay eventually, but as you said it is in Alpha and alphas are going to alpha up on the rug every once in a while.

[paktsardines]

That and with online games some calculations can be (are) sluffed off to servers taking even more load off your CPU

If you're referring to Simcity here, that proved to be a total lie, used to justify their always-online DRM.

[saclet]

Let me know how you go when you reduce the number of staff in your prison. It is likely your framerate will increase by considerably more than 300%. Will be interested to hear.

There is a problem which I don't understand, my old save game (which I was playing when I created this thread) has very larger prison which cover almost a medium map. I got 140 prisoners, 100 guards and about ~120 other staffs. It had horrible fps and I couldn't play it like I said before, but now at small map my prison is still large ~ 75% of the old one and I got around 200 prisoners and the rest is same but the fps is always above 10 which is playable. You said that this game use CPU for calculation but right now it doesn't make sense at all. I think this game is using CPU for both calculating, AI and especially graphic also, so I think it similar to Guild War beta when it used CPU for both jobs which made its fps horrible. So if the next alpha can separate graphic, animation for GPU and calculating, AI for CPU will make the game a lot better.

[paktsardines]

Bigger maps mean longer paths. I suspect calculating a longer path involves more cpu than a short one. This means performance will drop off more quickly on larger maps than smaller maps because occupants need to calculate longer paths.

I suspect also that there is a per-square operation being performed somehwhere, meaning the more squares a map has (ie larger map), the longer it takes to complete the operation. Not sure what it is exactly, but performance slows on a large map even when there are no occupants.

[shovat]

That and with online games some calculations can be (are) sluffed off to servers taking even more load off your CPU

If you're referring to Simcity here, that proved to be a total lie, used to justify their always-online DRM.

Nah I'm talking about proper on-line games. The ones with less hackers do the movement/hit detection on their end. I does mean latency issues = goatfucked but hey.

[shovat]

Bigger maps mean longer paths. I suspect calculating a longer path involves more cpu than a short one. This means performance will drop off more quickly on larger maps than smaller maps because occupants need to calculate longer paths.

I suspect also that there is a per-square operation being performed somehwhere, meaning the more squares a map has (ie larger map), the longer it takes to complete the operation. Not sure what it is exactly, but performance slows on a large map even when there are no occupants.

Yeah, I just stopped a medium map because lag issues were mistreating my poor little sprites. Took three days to build a new cell block when it used to take six or so hour, the laundry service was breaking down because duty allocation took hours, and people were starving even though there is food because apparently 30 minutes of walking and an hour an a half standing around looking at the food they desperately wanted to eat was the cool thing to do.

There is room for improvement in the AI

[hogan388]

The issue seems to be related to the game not utilising multiple cpu cores. Im getting serious lag and only one of my cores is being used (my has quad core) hopefully 64bit can be added in the future however for some reason alot of games don't utilise the possibilities of using multiple cores.

[shovat]

The issue seems to be related to the game not utilising multiple cpu cores. Im getting serious lag and only one of my cores is being used (my has quad core) hopefully 64bit can be added in the future however for some reason a lot of games don't utilise the possibilities of using multiple cores.

Any programmer out there that can give insight in to why this is?

Does it add complexity to the program that programmers prefer to avoid? Is it laziness? Or is there an industry standard that is taught that doesn't include programs that use multiple cores? Or is it something else entirely?

[Great Magical Hat]

Does it add complexity to the program that programmers prefer to avoid?

That's it. It adds a LOT of complexity. And I really mean A LOT.

Edit:

Let me try and explain how it does that. Basically, only a single process can run on a single core at a time (this is technically untrue, but I'll fix it before I'm done). Each process has its own memory and when a process is running on a processor (core) that processor (core) has access to certain information of that process, such as what the memory the process has access to is, which has to be updated whenever a process is "swapped out" for another. The operating systems swaps processes at its own leisure and this is something you - as a programmer - have absolutely zero control over.

However, to make things like working on multiple cores possible, there's a thing called a thread. Basically, it's a mini-process that has everything that a process has except for its own memory. It shares its memory with other threads. In fact, we need to update the terminology from the previous paragraph to reflect the existence of threads. Each process has a number of threads, which are defined by things like where in the code they are and their stack (the exact purpose of which is not relevant). Each process then has an assigned area of the memory, which is shared by all of its threads. Threads are actualy the things that are swapped in and out, but you still have no control over it. Threads can run simultaneously on different cores, but what makes this so hard is the shared memory.

Normally (which is without multiple threads in a process) you don't have to worry at all about being swapped in and out. You only have your internal state and things like user input are built on systems that don't care about this. When writing a multi-threaded application, you have to take care of the memory very carefully. Basically, any other thread can get an operation at almost any moment during your code. Let me give a very basic example of what could you wrong.

Let's say that I have a process with two threads. There is a number of tasks for them to complete, which are all completely separate from one another. I have two threads doing these tasks. I want to keep track of how many tasks have been completed. I use the following code (this is really simple so even if you can't program, you'll be able to follow it

while (anyTasksLeft()) // as long as there are any tasks left
{
... do a task ...

tasksDone++; // increase the number of tasks we consider done by 1
}

Actually, the only part of I'm interested in is the "tasksDone++" part. While not read as such normally when programming, for this explanation I'll have to boil it down to its essence, which is: 1. Read the value from the memory we named tasksDone 2. Add one to that value 3. Store that value in the memory we named tasksDone. Or:

1. Read tasksDone
2. Add one
3. Write tasksDone

Now let's see what might happen if you have more than one thread (and remember: you have no control over when exactly a process is going to be swapped in or out). We have processes P and Q, and this is one scenario that might happen:

P1. Read tasksDone {2}
Q1. Read tasksDone {2}
Q2. Add one {3}
Q3. Write tasksDone {3}
P2. Add one {3}
P3. Write tasksDone {3}

We started with 2 tasks done, then two tasks were finished and tasksDone is now only 3! Even more serious problems might occur if we look up a couple of lines. You might consider the situation in which both threads see that there's one task left, but by the time the slower thread actually wants to a task, the other process has already done it.

There are tricks around this problem, that smartly let different thread handle the same memory in a smart way. For example, here one might imagine each thread keeping a separate counter of how many tasks that thread has completed, and the (third) thread that outputs how many tasks have been completed, reads all those counters and adds their values up. It gets you a "sort of accurate" result at all times. However, these tricks are mostly of academic interest and the solution of the real world is to use locks. Basically, the first thread to request a lock gets it, and the next thread to request the same lock has to wait until the lock is released before it can get the lock and continue.

Because of this waiting that is involved with locks, you want to minimize the usage of locks. As such, the general idea is to split the memory into separate parts, one for each thread and a shared part. The idea is that each thread may freely access its own memory but has to lock whatever it wants to access from the shared part and it may never touch the memory of another thread. However, these rules aren't enforced at all (and in fact, there might be a good reason why you're not sticking to them). As such, the programmer has to make these divisions himself and properly request locks when accessing the shared memory. In both of those tasks it is extremely easy make a mistake and moreover, there's nothing to tell you when you made a mistake, as it will often just ran as if everything had gone right *most of the time*.

That most of the time stems from the fact that you have no control over the swapping in and out. (You only have to worry about swapping as long as there is only a single core, when there are more than one, it's also just about other core happening to do something at an unpredictable moment, but the issue remains the same.) Whether something goes wrong depends the relative timing of the threads, which again depends on the circumstances at a very small level you have no influence over. You generally can't even monitor these circumstances or even say in which order the threads got which operations executed. This also makes it extremely hard to fix bugs caused by multithreading, as you can just not reproduce them.

I hope that was maybe remotely understandable and yes, it's still really simplified.

[saclet]

Does it add complexity to the program that programmers prefer to avoid?

That's it. It adds a LOT of complexity. And I really mean A LOT.

Edit:

Let me try and explain how it does that. Basically, only a single process can run on a single core at a time (this is technically untrue, but I'll fix it before I'm done). Each process has its own memory and when a process is running on a processor (core) that processor (core) has access to certain information of that process, such as what the memory the process has access to is, which has to be updated whenever a process is "swapped out" for another. The operating systems swaps processes at its own leisure and this is something you - as a programmer - have absolutely zero control over.

However, to make things like working on multiple cores possible, there's a thing called a thread. Basically, it's a mini-process that has everything that a process has except for its own memory. It shares its memory with other threads. In fact, we need to update the terminology from the previous paragraph to reflect the existence of threads. Each process has a number of threads, which are defined by things like where in the code they are and their stack (the exact purpose of which is not relevant). Each process then has an assigned area of the memory, which is shared by all of its threads. Threads are actualy the things that are swapped in and out, but you still have no control over it. Threads can run simultaneously on different cores, but what makes this so hard is the shared memory.

Normally (which is without multiple threads in a process) you don't have to worry at all about being swapped in and out. You only have your internal state and things like user input are built on systems that don't care about this. When writing a multi-threaded application, you have to take care of the memory very carefully. Basically, any other thread can get an operation at almost any moment during your code. Let me give a very basic example of what could you wrong.

Let's say that I have a process with two threads. There is a number of tasks for them to complete, which are all completely separate from one another. I have two threads doing these tasks. I want to keep track of how many tasks have been completed. I use the following code (this is really simple so even if you can't program, you'll be able to follow it

while (anyTasksLeft()) // as long as there are any tasks left
{
... do a task ...

tasksDone++; // increase the number of tasks we consider done by 1
}

Actually, the only part of I'm interested in is the "tasksDone++" part. While not read as such normally when programming, for this explanation I'll have to boil it down to its essence, which is: 1. Read the value from the memory we named tasksDone 2. Add one to that value 3. Store that value in the memory we named tasksDone. Or:

1. Read tasksDone
2. Add one
3. Write tasksDone

Now let's see what might happen if you have more than one thread (and remember: you have no control over when exactly a process is going to be swapped in or out). We have processes P and Q, and this is one scenario that might happen:

P1. Read tasksDone {2}
Q1. Read tasksDone {2}
Q2. Add one {3}
Q3. Write tasksDone {3}
P2. Add one {3}
P3. Write tasksDone {3}

We started with 2 tasks done, then two tasks were finished and tasksDone is now only 3! Even more serious problems might occur if we look up a couple of lines. You might consider the situation in which both threads see that there's one task left, but by the time the slower thread actually wants to a task, the other process has already done it.

There are tricks around this problem, that smartly let different thread handle the same memory in a smart way. For example, here one might imagine each thread keeping a separate counter of how many tasks that thread has completed, and the (third) thread that outputs how many tasks have been completed, reads all those counters and adds their values up. It gets you a "sort of accurate" result at all times. However, these tricks are mostly of academic interest and the solution of the real world is to use locks. Basically, the first thread to request a lock gets it, and the next thread to request the same lock has to wait until the lock is released before it can get the lock and continue.

Because of this waiting that is involved with locks, you want to minimize the usage of locks. As such, the general idea is to split the memory into separate parts, one for each thread and a shared part. The idea is that each thread may freely access its own memory but has to lock whatever it wants to access from the shared part and it may never touch the memory of another thread. However, these rules aren't enforced at all (and in fact, there might be a good reason why you're not sticking to them). As such, the programmer has to make these divisions himself and properly request locks when accessing the shared memory. In both of those tasks it is extremely easy make a mistake and moreover, there's nothing to tell you when you made a mistake, as it will often just ran as if everything had gone right *most of the time*.

That most of the time stems from the fact that you have no control over the swapping in and out. (You only have to worry about swapping as long as there is only a single core, when there are more than one, it's also just about other core happening to do something at an unpredictable moment, but the issue remains the same.) Whether something goes wrong depends the relative timing of the threads, which again depends on the circumstances at a very small level you have no influence over. You generally can't even monitor these circumstances or even say in which order the threads got which operations executed. This also makes it extremely hard to fix bugs caused by multithreading, as you can just not reproduce them.

I hope that was maybe remotely understandable and yes, it's still really simplified.

I'm not programmer, I don't really understand what you said But do I have anyway to make the game run better by myself ? Or I should wait for the next alpha release ?

[sausje]

Honestly, i have the feeling that the current engine is bottlenecking rather then our CPU's.

Seems kinda stupid that a single thread on my 2600k wouldn't be able to calculate such tiny amounts of code.
Plus since the performance drops for virtually every CPU out there, i can almost say with 99.9% guaranty that the engine is limiting (or the code used for the calculations) the amount of AI that can be handled at the same moment.

[paktsardines]

I'm not programmer, I don't really understand what you said

Here's a very basic analogy:

Let's say your task is to read a book, and let's say it takes you 10 days to read your book. At the end of ten days you will have a good understanding of the plot, characters, themes and whatever. This is similar to sequential, single core processing.

Now Peter comes along and says "I can't believe you spent ten days reading a book. I read it in only one day, you suck!".

"How did you you manage that?" you ask.

"I hired nine other people to read the book and we read it in 1/10th the time - it's called parallelism and it's all the rage."

"So, you can tell me what happens to Mary in chapter 4?" you ask.

"Sure. Give me a moment. I read chapter one and Mary wasn't mentioned in that. Give me a moment while I find everyone who read about Mary and get their summaries. Then I'll go and talk to Joe, who read chapter 4, and then I'll have your answer."


If you consider each person in this instance as a 'core', then this is similar to multiple-core processing. Sure it takes 1/10th the time to read the book, but it doesn't take 1/10th the time to get your answers.


Now consider that peter knew in advance that he was only ever going to be asked about Mary. Peter could have told his other threads to discard any sections of the book that don't mention Mary. This would have significantly reduced the work involved, and is siimilar to optimizing for multi-core. Each task has to be specifically optimised for multi-core though, otherwise performance can end up _slower_ than on single core.

[saclet]

I'm not programmer, I don't really understand what you said

Here's a very basic analogy:

Let's say your task is to read a book, and let's say it takes you 10 days to read your book. At the end of ten days you will have a good understanding of the plot, characters, themes and whatever. This is similar to sequential, single core processing.

Now Peter comes along and says "I can't believe you spent ten days reading a book. I read it in only one day, you suck!".

"How did you you manage that?" you ask.

"I hired nine other people to read the book and we read it in 1/10th the time - it's called parallelism and it's all the rage."

"So, you can tell me what happens to Mary in chapter 4?" you ask.

"Sure. Give me a moment. I read chapter one and Mary wasn't mentioned in that. Give me a moment while I find everyone who read about Mary and get their summaries. Then I'll go and talk to Joe, who read chapter 4, and then I'll have your answer."


If you consider each person in this instance as a 'core', then this is similar to multiple-core processing. Sure it takes 1/10th the time to read the book, but it doesn't take 1/10th the time to get your answers.


Now consider that peter knew in advance that he was only ever going to be asked about Mary. Peter could have told his other threads to discard any sections of the book that don't mention Mary. This would have significantly reduced the work involved, and is siimilar to optimizing for multi-core. Each task has to be specifically optimised for multi-core though, otherwise performance can end up _slower_ than on single core.

What the heck? lol, no I confused about how he described the tasks with codes and then I thought we can do something to boost up the game by ourselves.