1. Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Why are SimCitys cities so small? Because EA didn't make it for multicore CPU's

Discussion in 'Games' started by 1ceTr0n, Feb 11, 2013.

  1. ...PACMAN...

    ...PACMAN...

    Joined:
    Nov 22, 2012
    Messages:
    316 (0.45/day)
    Thanks Received:
    109
    It's 2013, why opt for single threaded when you can get so much more from a multi-threaded engine :shadedshu

    If everything can run fine on a single core lets all just go back to semprons shall we? No, I didn't think so.
     
  2. WhiteLotus

    WhiteLotus

    Joined:
    Jul 30, 2007
    Messages:
    6,550 (2.48/day)
    Thanks Received:
    857
    Blame the developer. And it has yet to be proven that it is going to be an issue.
     
  3. ...PACMAN...

    ...PACMAN...

    Joined:
    Nov 22, 2012
    Messages:
    316 (0.45/day)
    Thanks Received:
    109
    I am. Regardless of any possible issues, it's just sheer laziness. End Of.

    You can get more out of modern hardware, hell some older games have even been updated along the way to encompass the benefits that multi-threading brings. Valve games and Wow to name just two examples off the top of my head.

    It's precisely this "laissez faire" attitude that allows these developers to get away with shoddy work. It's in THEIR hands, not ours.
     
  4. WhiteLotus

    WhiteLotus

    Joined:
    Jul 30, 2007
    Messages:
    6,550 (2.48/day)
    Thanks Received:
    857
    It's SimCity. Did you really expect it to be a masterpiece?
     
  5. ...PACMAN...

    ...PACMAN...

    Joined:
    Nov 22, 2012
    Messages:
    316 (0.45/day)
    Thanks Received:
    109
    Actually, if they put time and thought into the game, the right resources and utilized modern hardware. Yes, it could be. Any game could be when done right, just look at minecraft?
     
  6. newtekie1

    newtekie1 Semi-Retired Folder

    Joined:
    Nov 22, 2005
    Messages:
    20,040 (6.15/day)
    Thanks Received:
    6,102
    You keep saying they could get so much more from a multi-threaded engine, but the fact is they couldn't. The engine is graphically limited, not CPU limited, so the added development cost to make the engine multi-threaded would be wasted.


    Minecraft is single threaded...:rolleyes:
     
    Crunching for Team TPU 50 Million points folded for TPU
  7. FordGT90Concept

    FordGT90Concept "I go fast!1!11!1!"

    Joined:
    Oct 13, 2008
    Messages:
    13,798 (6.26/day)
    Thanks Received:
    3,680
    Location:
    IA, USA
    Minecraft is very poorly executed (pathetic frame rates for how little there is to render), mostly runs on a single thread, and is CPU dependent when windowed.
     
    THE_EGG and ...PACMAN... say thanks.
    Crunching for Team TPU
  8. de.das.dude

    de.das.dude Pro Indian Modder

    Joined:
    Jun 13, 2010
    Messages:
    7,812 (4.90/day)
    Thanks Received:
    2,076
    so EA is in ties with intel, and they too are hellbent on destroying AMD


    EA sucks anyways, their stuff is consumer vomit.
     
  9. Jizzler

    Jizzler

    Joined:
    Aug 10, 2007
    Messages:
    3,434 (1.30/day)
    Thanks Received:
    641
    Location:
    Geneva, FL, USA
    EA did alright with SC4, but's that largely because Maxis was one of their slow-to-absorb divisions (like being thrown into a sarlacc). There was just enough of that Maxis spirit left in 2001-2003 to make a decent enough sequel. Today, they're just another soulless code factory under the control of Evil Ambition. SC5 is clear evidence of this, being more of an upgrade to Farmville than a true sequel advancing the series.
     
  10. ...PACMAN...

    ...PACMAN...

    Joined:
    Nov 22, 2012
    Messages:
    316 (0.45/day)
    Thanks Received:
    109
    Ha HA :laugh: That shows me :D

    It's amazing what you can do with a single thread lol Although Ford says it runs poorly so surely that backups the point .... :confused:
     
    Last edited: Feb 12, 2013
  11. FordGT90Concept

    FordGT90Concept "I go fast!1!11!1!"

    Joined:
    Oct 13, 2008
    Messages:
    13,798 (6.26/day)
    Thanks Received:
    3,680
    Location:
    IA, USA
    This thread isn't about Minecraft but, case in point: just standing still with my system (in the specs), the FPS is 50-93 and ~45 while moving. Using water to harvest about 500 worth of a crop will drop it to 19 FPS. My server, which has dual Xeon E5310 quad core processors and a HD 5570 gets 20-30 FPS standing still and ~20 FPS moving (constant dips into the single digits). With BOINC running 100% on both systems, the FPS drops by about half.
     
    Last edited: Feb 12, 2013
    Crunching for Team TPU
  12. SaltyFish

    SaltyFish

    Joined:
    Jun 6, 2012
    Messages:
    339 (0.39/day)
    Thanks Received:
    87
    I can see why the devs went for the two-core approach; quad-cores became mainstream not too long ago and they're trying to broaden their potential target market (people who will run the game on their 2008 Core 2 Duo systems). It's understandable, so I'm not too upset about that. I'd more worried about general crappy programing. The Sims 3 has a notorious issue involving the lack of a frame rate limit despite the game engine not being able to render more than 30 FPS. This meant GPUs needlessly thrashing to render the game at 120+ FPS despite the fact that most frames would be identical. Thank the gods there was a mod for that. Great way to kill a GPU though. :shadedshu



    I think the other reason for making SimCity 2013 smaller was to keep it from being too complex. SimCity 4 was great and all, but the devs (Will Wright himself included) were worried that SimCity 4 had begun to become too complex and that it was alienating potential newcomers. I guess the whole interconnecting cities thing was a bit too much.

    We all know the result of that was SimCity Societies. It went too much in the other direction. The game would've been alright if it didn't have to live up to the SimCity name and wasn't marred by programing inefficiencies that made it more demanding than Crysis.
     
  13. Bo$$

    Bo$$ Lab Extraordinaire

    Joined:
    May 7, 2009
    Messages:
    5,317 (2.66/day)
    Thanks Received:
    868
    Location:
    London, UK
    I played the beta, it intrigued me, i've never played SimCity. only city builder i've played was Caesar III. From my experience it was quite pleasurable and seemed easy to get into. I must say it was an oversight to leave it single threaded but to make it highly paralleled would have made it perform worse on some other configurations. I think they didn't really know their target market and TBH it looks pretty good, those who want to play it, buckle up, for the rest just stick to the old versions and be happy
     
  14. FordGT90Concept

    FordGT90Concept "I go fast!1!11!1!"

    Joined:
    Oct 13, 2008
    Messages:
    13,798 (6.26/day)
    Thanks Received:
    3,680
    Location:
    IA, USA
    No, it was the micromanagement required to balance the budget. You'd have to adjust range of service buildings as well as their budget to match the requirements of the facility (e.g. make schools only be funded enough to handle all the kids).

    SimCity 4 was substantially harder to turn a profit than any of the previous games. It really didn't add much (except U Drive) to the SimCity 3000 formula.


    SimCity Societies was the SimVille idea expanded--a merger of SimCity and The Sims (Will Wright always wanted to do that). SimCity 5 is the spiritual successor to SimCity Societies but going back to the original SimCity formula where you zone and demand builds as opposed to building most buildings yourself.

    SimCity Societies wasn't demanding at all on hardware.
     
    Crunching for Team TPU
  15. hellrazor

    hellrazor

    Joined:
    Feb 18, 2010
    Messages:
    1,579 (0.92/day)
    Thanks Received:
    319
    Oh hardly, with clever use of arrays and thread-local storage the game would never have to touch a mutex.

    And before Ford tries to jump on me, consider this:
    Code:
    for (uint64_t i = currentthreadid; i < whateverarraycount; i += numberofthreads){
        dosomething(whateverarray[i]);}
     
    Last edited: Feb 13, 2013
  16. FordGT90Concept

    FordGT90Concept "I go fast!1!11!1!"

    Joined:
    Oct 13, 2008
    Messages:
    13,798 (6.26/day)
    Thanks Received:
    3,680
    Location:
    IA, USA
  17. hellrazor

    hellrazor

    Joined:
    Feb 18, 2010
    Messages:
    1,579 (0.92/day)
    Thanks Received:
    319
    Except that no two threads would ever touch the same object in whateverarray (maybe I should put that in somewhere, I'll go edit it).
     
  18. FordGT90Concept

    FordGT90Concept "I go fast!1!11!1!"

    Joined:
    Oct 13, 2008
    Messages:
    13,798 (6.26/day)
    Thanks Received:
    3,680
    Location:
    IA, USA
    If "whateverarray" was your entities, you basically just bottlenecked the entire game whenever a single entity requires a big update.

    The array itself is liable to create cross-thread reference issues (two threads try to modify the same element simutaneously and the application implodes).

    Additionally, to be synchronized, "dosomething" needs to check a global state and update it notifying all other related threads that is busy or ready. Even when doing synchronized, it's only as fast as the slowest thread.
     
    Crunching for Team TPU
  19. hellrazor

    hellrazor

    Joined:
    Feb 18, 2010
    Messages:
    1,579 (0.92/day)
    Thanks Received:
    319
    Yes, slowest thread and weakest link and all that, but having a single thread do everything and the big update on the one entity would never be faster.

    And if you'd look at my code snippet you'd know that no two threads would ever touch the same object in the array. currentthreadid is the sequence that the thread is created in (0, 1, 2, 3, etc.), as long as no thread's currentthreadid is above numberofthreads they will never touch.

    And, yes, if it needs to check or mess with a global, then sure, you might need a mutex, but there are even ways around that.
     
    Last edited: Feb 13, 2013
  20. FordGT90Concept

    FordGT90Concept "I go fast!1!11!1!"

    Joined:
    Oct 13, 2008
    Messages:
    13,798 (6.26/day)
    Thanks Received:
    3,680
    Location:
    IA, USA
    At the end of the day, all x86 processors are procedural and that's its greatest weakness. Specific things have to be done in a specific order in order for the next task to be completed. Your example completely lacks context and only multithreads one task. Dozens of tasks have to be completed every game tick and many of them can't be completed until something else is completed first.

    In your example, the primary weakness is "whateverarray." It needs to be populated and/or updated and that is happening in the main thread before any multithreading relative to it even begins. Preparing to multithread can take more time than the actual mulithtreaded task.


    Case in point, updating the "agents" are likely to be the biggest burden on the CPU. It can't be multithreaded the way you described because agents interact with each other. For example, agent a driving in a car behind agent b can't move ahead of agent b until agent b updates. When you have a hundred cars in a traffic jam, you have to update them in order from the first car which is looking for a way out of the jam to the last car that can't do anything this tick except notify the user that there's a problem. You can't update the last car until you know all cars in front of it aren't moving. No amount of multithreading is going to fix that.

    I'm sure the game thread is idle most of the time except when dealing with user inputs so the simulating of the agents are going to be a bulk of the processing load and there's no reason to separate it.
     
    Last edited: Feb 13, 2013
    Crunching for Team TPU
  21. hellrazor

    hellrazor

    Joined:
    Feb 18, 2010
    Messages:
    1,579 (0.92/day)
    Thanks Received:
    319
    So put in stages, have all the threads work on an array of whatevers and then wait for them all to be done and then work on array of whateverelses.

    Are you telling me that they aren't already in an array? How are they stored, as global or local variables?

    Doing it sequentially is not better, you still have to figure out which agents are going to exit the road soonest (in order to have a decent sequential chain that will leave space for the ones behind it), except that you can account for agents that are about to exit 4 or 6 or 8 roads instead of one at a time. At worst (at intersections where you have a choice, probably) you will have to wait for at least the one choice you want to open up, but even then if your chain-building part is decent enough you'll never have to worry about that either.

    Or you could just not seperate it.
     
  22. lyndonguitar

    lyndonguitar I play games

    Joined:
    Apr 1, 2010
    Messages:
    1,634 (0.98/day)
    Thanks Received:
    338
    Location:
    Philippines
    It may not be a big performance issue, but we could sure use more and maximize the performance, as almost everyone have multicore cpus now.

    For small-normal sized cities it will be smooth, but c'mon its a sandbox game, a City Building game! the hardware should be the bottleneck not the software. :shadedshu
     
  23. Aquinus

    Aquinus Resident Wat-man

    Joined:
    Jan 28, 2012
    Messages:
    6,467 (6.46/day)
    Thanks Received:
    2,189
    Location:
    Concord, NH
    You make it sounds like everything can run in parallel and that there are no interdependence between threads. If two things depend on one thing, then a mutex and locking would very much be necessary. I suspect a lot of things are shared and that programming this to be multi-threaded might not result in the benefits you're looking for.

    I'm saying that we don't know how they're stored and you can't make the assumptions you're making right now about the code, even more so when it's something that's closed source. It very well could be harder to implement multi-threading than you think. In fact it probably is.

    It's faster depending on the set of data, but I think at this point you're spewing out bulls**t unless your a Maxis developer. In the case you are, I can blame you for potentially poor design decisions and if you aren't, I can blame you for talking about something you know nothing about.

    I'm sure that the developers at EA didn't introduce more multi-threading (if you read that twitter post, it DOES NOT say that it isn't multi-threaded, it only says the sim and game-loop aren't, which means audio and rendering could be). So I would stop guessing and get your panties out of a bunch because anyone who isn't a Maxis developer isn't going to know for sure. Also unless performance was an issue, i wouldn't make a task multi-threaded unless I really benefited from it. We don't know if it will be a bottleneck so its a poor decision to just instantly assume that it will because you don't know what is happening with the game while it was in development.
     
    Last edited: Feb 13, 2013
    FordGT90Concept says thanks.
  24. Mr McC

    Mr McC

    Joined:
    Apr 12, 2010
    Messages:
    1,248 (0.75/day)
    Thanks Received:
    323
    I beg to differ:

    http://www.gog.com/gamecard/constructor
     
    FordGT90Concept says thanks.
  25. Jizzler

    Jizzler

    Joined:
    Aug 10, 2007
    Messages:
    3,434 (1.30/day)
    Thanks Received:
    641
    Location:
    Geneva, FL, USA
    Oh, I know. Like my first post touched upon, they could make a game that scales (both in the technical and gameplay sense), but there's not enough Simcity diehards to make it worth it. Besides, if they put out a game as deep as the previous ones where cities are built over weeks and sometimes months, then other EA titles aren't getting bought. So there's financial incentive to nerf Simcity.
     

Currently Active Users Viewing This Thread: 1 (0 members and 1 guest)

Share This Page