Jump to content
         

humus

Member
  • Content Count

    4
  • Joined

  • Last Visited

Community Reputation

0 Clean Slate

About humus

  • Rank
    Freshman
  1. Uh Wut?! That's not how programming works. I actually posed this question to friends whom are embedded software engineers, and they said that no, quadrupling the size would not quadruple the resource requirements. Would an increase in simulation size increase the required resources? Yes, but not to that level. Given how many corners the simulation itself cuts, I wouldn't be surprised if quadrupling the simulation size would only require 1.5 times the current amount of resources. why not make the "CLOUD" help simulation process ? ah right, the "cloud" dont work that way Either way, I think GlassBox as city simulation is broken if it failed to scale. with that kind of limitation, a fate has been sealed
  2. Discussion about City Tile Size

    It's likely a bit of both. With pathfinding over long distances, it becomes an issue of combinatorial optimization: the difficulty and complexity of these computations increase exponentially as the number of choices, possibilities, and variables branch out further and further... essentially the classic "traveling salesman problem." These problems are what are known as NP-Hard problems and is a type of computation that traditional computing hardware struggles with. It essentially needs to brute-force and calculate every possibility in order to compare them and find the most optimal solution. For an example of how this exponential increase in difficulty would translate into the game, for graph of x2, where x is the area of the city lot and y is number of calculable possibilities: Where x = 5, y = 25. Doubling the map area, x, making x = 10 returns y = 100... a 4x increase in complexity. Tripling the map area, making x = 14, returns y = 225... a 45x increase in complexity. So just by doubling the map size, it would increase computational complexity by up to four times... just for pathfinding alone. The most effective means of solving these sort of NP-hard, combinatorial optimization computations is currently a quantum computer taking advantage of Grover's algorithm, which can give a quadratic speedup over typical computational brute-force search calculation methods. (But that won't help you very much unless you're Google, NASA, or Lockheed Martin and have access to a D-Wave 2 computer.) Most likely, Maxis isn't using typical brute-force means to solve the NP-Hard pathfinding solutions simply due to the computational load it requirement. Instead, they've probably developed a much more rudimentary pathfinding system with more simple rules and calculations, resulting in far lower CPU usage... but at the same time also being far less efficient in its pathfinding decisions (as you've undoubtedly seen firsthand). But doubling the map size will still create exponentially greater pathing variations and would certainly make the Glassbox pathfinding systems, as it stands, even less effective... not to mention that doubling the map size would also lead to nearly doubling the number of agents requiring pathfinding. Most pathfinding we see in games is only being used for a handful of NPCs at a time. The more effective pathfinding system, the higher the CPU demands. So in order to run this pathfinding for several hundred of game agents, simultaneously, it requires "dumbing down," of sorts, in order to make the load manageable. TL;DR: My point is that effective pathfinding is not that simple to implement, especially on the scale that is required within SimCity due to the sheer number of agents. Doubling the map size will have a much bigger impact on the game's computational requirements than one might suspect. The issue is of limitations both with the GlassBox engine and with CPU load. The GlassBox engine likely would struggle with larger maps; Improving the GlassBox engine to work more efficiently on larger maps would require more clock cycles. Note: So as not to misinterpret my intent, I am not defending EA/Maxis here, and I'm all for larger map sizes... I merely just want to make it clear that the issue is more complex than it may appear. Personally, I'm not going to get my hopes up. Isnt That what Maxis pro claimed Cloud computing will be used for ? The always on Requirement they give on sim city 2013 ? If they say, always on was for help our pc load by taking agents calculation to EA server. The larger map size were not so much of a problem Then oh, btw is that feature even exist ? frow what i feel. the always on Internet connection were not used for cloud computing, only save, leaderboard, region stuff like commute seems random also all the agents stuff were calculated by local machine. and either way the cloud computing they imagine for never actualy helped lighten PC load. Either way, The always connect features not only they failed to utilize optimumly. become a constraint rather than advantage
  3. Experiments, Tips, and Confirmations

    If all cities in same ingame years (12) , maybe it will sync up well it just presumption though. Great works work in mysterius ways it seems
  4. Experiments, Tips, and Confirmations

    Uhm, I found out that Region Data, especialy handling great works were synced using each city year, as guidelines. rather than real time what I found were tried in sandbox. cities A. founded great works, and supply it with ressource which finished at year 8 - may I open cities B, which still year 3, the Great works were not there, Fast forward and The Great works appear at year 8 around april. Still need multiple confirmation though, but seems Great works data synched with In-Cities year, rather than realtime So for every cities on region have working great works, they should at least have passed the in game time when the great works is finished.
×