Warning: I will try to keep this post as short as possible, but it might be a wall. It's mainly composed of wishes and dreams.
Practical wishes:
1) Have CO warm up to the idea of at least measuring community response about how they would feel if a future game expansion raised the baseline system requirements.
2) Have code move from run-of-the-mill CPU multithreading to OpenCL.
Immersion wishes:
1) Have interior mapping improve the looks of buildings, creating an illusion of space behind the windows, doubling up as an indicator of CIM presence in the building, like a diegetic UI.
Grander wishes:
1) Have the game implement LoS - Level of Simulation - so that simulation parts can run in a "close" or "far" mode. This would be used around to interact with other cities in a region, for example.
2) Have specific - not all - highway entrances/exits delimit the city's boundaries. beyond that, everything simulated is "far". whatever is on this side is "close". These are the key entrypoints through which resources will be shared between the "close" city and the "far" cities, according to the rates stated in the LoS log.
3) Have LoS be used to the game advantage not only on very large scenarios, but also on very small ones. Case in point: Have a whole amusement park expansion.
4) Have multiplayer implemented by syncing the "far" city states continuously across machines.
Practical wishes:
1) Have CO warm up to the idea of at least measuring community response about how they would feel if a future game expansion raised the baseline system requirements.
If this is mostly acceptable, raising the bar may give extra headroom to implement more stuff, ranging from content to more complex algorithms.
There is a lot of stuff we would love to have, and repeatedly the problem seems to be "we don't want to change the base requirements".
There is a lot of stuff we would love to have, and repeatedly the problem seems to be "we don't want to change the base requirements".
City simulation has a lot of "embarassingly parallel" problems which may be solved in a much more efficient manner using OpenCL.
OpenCL code can run on the CPU as well as the GPU, both integrated and dedicated processors can benefit from it. The game could have settings to force it to run on the CPU, GPU, both or autodetect.
This could give the game a much needed headroom for future expansions.
And especially throwing traffic AI under this bus could be especially helpful to have more cars around and/or free up CPU resources, and/or implement the much asked for improved AI.
I bet the community would wholeheartedly embrace a beta release - or several - to gather telemetry data for CO to at least explore the performance implications. Even if it's an opt-in on Steam, I for one would jump on it just to give you some data.
OpenCL exists on Windows, Mac and Linux, so it might just be possible.
OpenCL code can run on the CPU as well as the GPU, both integrated and dedicated processors can benefit from it. The game could have settings to force it to run on the CPU, GPU, both or autodetect.
This could give the game a much needed headroom for future expansions.
And especially throwing traffic AI under this bus could be especially helpful to have more cars around and/or free up CPU resources, and/or implement the much asked for improved AI.
I bet the community would wholeheartedly embrace a beta release - or several - to gather telemetry data for CO to at least explore the performance implications. Even if it's an opt-in on Steam, I for one would jump on it just to give you some data.
OpenCL exists on Windows, Mac and Linux, so it might just be possible.
Immersion wishes:
1) Have interior mapping improve the looks of buildings, creating an illusion of space behind the windows, doubling up as an indicator of CIM presence in the building, like a diegetic UI.
Interior mapping can be thought of an extreme form of parallax, making a flat texture seem to have negative space i.e. towards the interior of the mesh. The "room texture" would have the size of the wall, the "window" would be like a hole through which the "room texture" is visible.
There would be "lights on" and "lights off", "window open" and "window closed" variations. These textures can be reused by all/most buildings, to conserve memory. Like sharing the same visual through all residential buildings, another set to all commercial, and so on.
Lights would go on and off, and windows open and close according to CIM presence. This data is already used to create the popup blob to display the building state, the hooks can be reused.
There would be "lights on" and "lights off", "window open" and "window closed" variations. These textures can be reused by all/most buildings, to conserve memory. Like sharing the same visual through all residential buildings, another set to all commercial, and so on.
Lights would go on and off, and windows open and close according to CIM presence. This data is already used to create the popup blob to display the building state, the hooks can be reused.
Grander wishes:
1) Have the game implement LoS - Level of Simulation - so that simulation parts can run in a "close" or "far" mode. This would be used around to interact with other cities in a region, for example.
The first step would be to create a looped city log for a meaningful number of days of city activity. This log would be essentially a simplified model - a history of the city. When we are "far" from the city, its activity would be read from this log.
This would require saving core information about each CIM traveling outward, like education and where is he working at.
Individual, persistent job positions being filled by people which live in other cities would be registered in the log as well, as they will be referenced when the other city simulation runs.
It is core to the concept that a Los log is only updated when a city is run in "near" mode, never in "far" mode.
To simplify the simulation and make it viable, a worker from abroad would not age, since the "far" city simulation is not running to update the log.
Accidents should be cheated a bit. If a worker from abroad is killed, he would go dormant for some time, then be allowed back in the simulation, because the "far" log cannot be changed by a different city.
If desired, these accidents can be logged with a timestamp. When the "far" city is run "near" after some time that cim suffers an accident when working abroad and dies. If the "near" simulation kills him first with another accident, then the event either switches to another cim working abroad or whiffs off silently.
This would require saving core information about each CIM traveling outward, like education and where is he working at.
Individual, persistent job positions being filled by people which live in other cities would be registered in the log as well, as they will be referenced when the other city simulation runs.
It is core to the concept that a Los log is only updated when a city is run in "near" mode, never in "far" mode.
To simplify the simulation and make it viable, a worker from abroad would not age, since the "far" city simulation is not running to update the log.
Accidents should be cheated a bit. If a worker from abroad is killed, he would go dormant for some time, then be allowed back in the simulation, because the "far" log cannot be changed by a different city.
If desired, these accidents can be logged with a timestamp. When the "far" city is run "near" after some time that cim suffers an accident when working abroad and dies. If the "near" simulation kills him first with another accident, then the event either switches to another cim working abroad or whiffs off silently.
2) Have specific - not all - highway entrances/exits delimit the city's boundaries. beyond that, everything simulated is "far". whatever is on this side is "close". These are the key entrypoints through which resources will be shared between the "close" city and the "far" cities, according to the rates stated in the LoS log.
This has to be carefully planned, but an intelligent implementation may make it possible to have two (or more) cities side by side, and have this delimitation move dynamically as the game progresses.
Currently the game has a large region, and CIMs come from "infinittely far".
There would be invisible buildings to represent the "infinitely far" resources: residential, industry, commercial, offices, including production of goods like wood, food etc.
As the LoS log is created/updated, the city would also have an invisible representation of what it has.
At each highway connection on the city limits, there would be a set of invisible buildings. The rate of traffic to and from on each entry would be logged.
When this city is "far", it would be represented by its own set of data and invisible CIM/resource providers.
Other cities in the region will be able to consume from this cities, instead of relying only in the "infinity" providers.
Balance changes would reduce the "infinity providers" effectiveness, so that regional play becomes advantageous.
Currently the game has a large region, and CIMs come from "infinittely far".
There would be invisible buildings to represent the "infinitely far" resources: residential, industry, commercial, offices, including production of goods like wood, food etc.
As the LoS log is created/updated, the city would also have an invisible representation of what it has.
At each highway connection on the city limits, there would be a set of invisible buildings. The rate of traffic to and from on each entry would be logged.
When this city is "far", it would be represented by its own set of data and invisible CIM/resource providers.
Other cities in the region will be able to consume from this cities, instead of relying only in the "infinity" providers.
Balance changes would reduce the "infinity providers" effectiveness, so that regional play becomes advantageous.
3) Have LoS be used to the game advantage not only on very large scenarios, but also on very small ones. Case in point: Have a whole amusement park expansion.
Inside the amusement park, there would be a whole "near" simulation. The city where it resides in would be in "far simulation" while the player is managing the amusement park. When the player moves ouside of the amusement park, to the city, the city becomes "near" and the park becomes "far" simulation.
4) Have multiplayer implemented by syncing the "far" city states continuously across machines.
Cities change slowly, the full city state does not need to be synced. It can be synced one log day at a time, gradually, in a atomic manner so that all far states are synced all the time.
This would allow players to play the game in two machines across teh planet (or the universe) and the LoS logs gradually sync, making the "far" city evolve dynamically as both friends play their "near" cities at the same time.
This would allow players to play the game in two machines across teh planet (or the universe) and the LoS logs gradually sync, making the "far" city evolve dynamically as both friends play their "near" cities at the same time.
Last edited:
- 3
- 3
E or IPT would not be possible.
.png){kind=avatar}