About fluctuations in gameplay speed

Discussion in 'Backers Lounge (Read-only)' started by ashua666, March 28, 2013.

?

What's your opinion of the TA family's slowdown?

  1. It's better than framerate issues

    9 vote(s)
    40.9%
  2. I don't care either way

    2 vote(s)
    9.1%
  3. Please, please don't let the game slow itself down.

    8 vote(s)
    36.4%
  4. I'd rather have framerate issues

    1 vote(s)
    4.5%
  5. I'm happy with a compromise

    2 vote(s)
    9.1%
  1. ashua666

    ashua666 New Member

    Messages:
    22
    Likes Received:
    0
    I'd just like to say that I've always been a massive fan of the TA family of games but one issue in my opinion has plagued them from the very first. That is involuntary scaling of game speed.

    To clarify, I don't mind the idea of gamespeed being sped up or down but as we know in long matches the game speed started to reduce, particularly when the AI was involved. The problem at least in my point of view is that nothing in either TA or Supreme Commander's default interface (I know you can use a command line to find it out) told you what the speed the game is actually running at.

    After aw hile, this subtle slowdown can become incredibly frustrating. I know that you guys know what you're doing. I only bring this up because it was a flaw of the original Total Annihilation that managed to trasnlate into Supreme Commander. Personally, I'd rather have some amount of framerate drop or lag issues when dealing with hundreds of units on screen than have the game slowly crawl to a standstill.

    I should say that I don't mind the idea of the game recommending you slow the game speed down, so long as it doesn't force the decision on you. Also, just so I'm not pointing out a problem without offering a solution, one idea I had of how this issue could be solved is that for every percentage reduction in game speed, increase build times by an appropriate amount. That way at least while individual units might move slower, the game itself doesn't slow to a crawl. I know that's not a perfect solution but it would be a compromise solution after all.

    I am aware about the idea of server-side hosting of units and I have paid attention to what's been stated around the issue so I know this will be a much more efficient game than any of its predecessors. I just wanted to raise this one particular thing as something I hope can be avoided as it's a flaw that at least personally impacted my enjoyment of the game.

    As ever, thank you for any responses and your opinions.
  2. magicide1

    magicide1 Member

    Messages:
    45
    Likes Received:
    0
    There is nothing they can do about the slow down. When the game slows to a crawl it's because your hardware can't keep up with the calculations required for the game to run at standard speed.

    In TA for example you would see game speed and another number in brackets. The number in brackets is what speed the game is actually running at if I recall correctly. The graphics weren't especially taxing even in a large battle. Sup Com was exactly the same.

    So the short of it is the game speed you choose is the max speed you want the simulation to work at. If there is too much going on to maintain that speed it's going to slow down and there is nothing you can do other than get better hardware. They can't artificially make the game go faster unless you want to go to simpler physics and unit interactions.

    As to the idea of changing build times so that units continue to be produced quickly when the game slows, that's a very bad thing. The simulation is already overloaded for your hardware and you are adding additional things it needs to calculate at an increasing rate relative to the gameplay duration. Your only reasonable option is better hardware or smaller games.
  3. KNight

    KNight Post Master General

    Messages:
    7,681
    Likes Received:
    3,268
    One of the other major contributors to Slowdowns is the AI.

    I run a pretty nice system, and I can play FA for an hour at least before I notice any slowdown at all even when I have multiple AIs.

    Using Sorian's AI mod and his Cheating AI Options Add-on can let you tweak the AI settings so you can use fewer AIs, which helps with the slowdown as well.

    But for PA, this won't be much of an issue because all the important Sim Calculations are handled on a Server, so long as the host has a powerful enough PC the experience should be pretty smooth.

    Mike
  4. yogurt312

    yogurt312 New Member

    Messages:
    565
    Likes Received:
    2
    when playing online at least, the server will be determining the game speed so you wont have one person playing with a potato making everyone play at 1 second a minute.

    Thats not going to help in skirmish where you are the server but its some consolation and online play is where its most necessary.
  5. bobucles

    bobucles Post Master General

    Messages:
    3,388
    Likes Received:
    558
    It's more a case of the calculations being unable to keep up with the hardware. Multi core design has been around for nearly 10 years now, and NO ONE seems to have caught on yet. Tons of games come out even today with code that is incapable of using the most basic of modern CPUs.

    Making use of TODAY'S hardware is one of the primary goals of PA. If you can't blue screen your PC, then you aren't pushing the game hard enough. :lol:
  6. bmb

    bmb Well-Known Member

    Messages:
    1,497
    Likes Received:
    219
    Supcom was one of the first major games released to be optimized for quad core. So I don't know where you are going with that.
  7. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    Sup Com only had 2-3 main threads. The entire sim was only 1 thread, meaning 1 core (and 1 bottleneck), so it was hardly "optimized". However, multi-core programming for games is a vastly different beast to desktop apps, and bobucles is right in that we are only now starting to catch up in our gaming software to what the hardware is capable of.
  8. ashua666

    ashua666 New Member

    Messages:
    22
    Likes Received:
    0
    That may be true but the slowdown problem is not present in many other RTS games
    I am only highlighting a problem in the hope that coding will be better in the game that TA/SC
  9. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    Name an RTS that comes close to the scale and scope of TA (when it was released, it's not a problem now) or Sup Com?
  10. AusSkiller

    AusSkiller Member

    Messages:
    218
    Likes Received:
    0
    Since they are not using a synchronous simulation then all they have to do is also not use fixed time steps for the simulation and there will never be any slow down of the game speed, however doing that can make physics calculations inconsistent and lead to a lot of dependencies between the server and client but IMO for a game like PA that would be perfectly acceptable and it's unlikely that anyone would even really notice, of course if it's really at the limit of the hardware then the game will also be a lot more jerky looking.


    There are a LOT of issues with trying to take advantage of multi-core CPUs, primarily that much of a game's processing needs to be handled in a very specific order to work correctly and if it needs to be done in order then it cannot be done on multiple cores simultaneously. For instance you cannot render the frame until you have figured out what units needs to be rendered and where, and you can't figure out what units need to render until the units have been updated for the frame, and you can't update units for the frame until you have updated the flow fields, and you can't update the flow fields until the input that could affect how flow fields are created/updated has been processed and so on across a whole variety of things.

    There are also a lot of overheads with using multiple cores, you need to have code that keeps track of all the threads and balances the loads on them to be able to maximize efficiency, for certain operations that modify data shared between the threads you need to use locks or atomic operations that stop all other thread from doing anything until the operation is complete, and sometimes you need to copy large amounts of data for each thread so it can be read and modified without lock or atomic operations and then after all thread are done with the data that data needs to be recombined. There's also diminishing returns with using multiple threads, the more threads you use the more time you spend managing them, and there's also finite number of jobs that can be processed in parallel so if there are more hardware threads than jobs then additional hardware threads are pointless (as is the case in SupCom). Often you also need to wait for all threads to finish before you can give them all more work to do as the next batch of work is dependent on the results, so no matter what you end up with threads that are idle a lot of the time so you can't really get it to use 100% of the CPU all the time as you can with a single thread game on a single thread CPU.

    Using multiple cores is not something that should just work for every game, it takes a hell of a lot of planning and code design to take advantage of multiple cores and is often either not worth the additional effort and in some cases it would just not not work at all. Multi-threaded code design is one of the hardest parts of programming, doubly so when it's for something as complex as a game but from what Mavor has said in the live streams it sounds like Uber are certainly going to be doing whatever they can to use as many cores as possible, I can guarantee it's a lot of hard work to get it to where they want it to be, though I'm sure they are up to the task.
  11. bmb

    bmb Well-Known Member

    Messages:
    1,497
    Likes Received:
    219
    I don't know why devs try to handle threads by themselves anyway. Isn't that an OS/hardware level operation designed by people far smarter than any of us anyway?

    Just separate out tasks that can be separated into their own threads and let the machine work its magic under the hood. Far as I'm concerned every unit could be its own thread.
  12. AusSkiller

    AusSkiller Member

    Messages:
    218
    Likes Received:
    0
    Because when you handle the threads for your game yourself you can get much better performance, if you have thousands of jobs to do and create a thread for each to let the OS handle them it creates a massive amount of overhead in the OS that will steal CPU cycles from the game. But if you create a thread for each available hardware thread and manually pass it more jobs as it completes you can often get much better results, it's also a lot easier to track when all the threads are complete. You might also want to have dedicated threads for processing something serially that you know will take a while and if you let the OS deal with that sort of thing you can run into problems. Generic solutions are very rarely as good as purpose built ones.

    It's unlikely that everything in the unit's update code can be separated out in such a way that they can all be efficiently processed simultaneously but I'm sure that anything in the unit update code that can be processed simultaneously will be, except they'll probably be put into jobs rather than threads and each thread will be fed a stream of jobs to process until all the jobs are complete, of course I don't work at Uber so their actual implementations might differ, they may even figure out a way to have the entire update work simultaneously which would be awesome for performance.
  13. asgo

    asgo Member

    Messages:
    457
    Likes Received:
    21
    you really don't want to do that.
    oversubscribing is seldom a good idea, oversubscribing in the order of thousands is never a good idea. :)
  14. BulletMagnet

    BulletMagnet Post Master General

    Messages:
    3,263
    Likes Received:
    591
    Because you can't separate out tasks that affect each other. Affecting each other is as simple (and common) as two things writing to the same variable. It's a skilled art to split something up into many pieces and have it work faster than piling it all together.

    Think about it this way; if everything was so easily separable, and if the OS could do a better job, wouldn't we see it in every piece of software already?
  15. krashkourse

    krashkourse Member

    Messages:
    254
    Likes Received:
    5
    Game should go at a set pace... other computers shouldn't slow down for the slowest computer. speed is consistent with server so that what ever your machines speed fast or slow it wont change the game.
  16. bobucles

    bobucles Post Master General

    Messages:
    3,388
    Likes Received:
    558
    COMPUTERS DO NOT WORK THAT WAY!

    All the OS does is assign the hardware and try to manage a thousand ravenous programs all screaming for system resources. Threads don't automagically happen, and multi threading ESPECIALLY doesn't happen on its own.
  17. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    Those screaming about making everything multi-threaded, please don't multi-thread this thread, there's enough fail here already.
  18. numptyscrub

    numptyscrub Member

    Messages:
    325
    Likes Received:
    2
    If the slowdown is not present in other games, they are obviously either using a simpler engine, or artificially constraining the amount of calculation required another way (unit caps, stupider AI, hitscan weapons only etc.). You could technically skip calculation steps (note: it is very hard to do so), however that would have units teleporting around instead of moving, and in extreme cases no visible reason why units have exploded or disappeared. Practise this by running any RTS and closing your eyes, then only open them once a second. Now try to play with that "lag", and tell me if you prefer that to it running smoothly, but slowly ;)

    Trust me, the slowdown is inherent in maintaining an accurate simulation whilst processing too many units to be able to finish the calculations in real time (regardless of how many threads or cores are being utilised). In this sense, the simulation is extending "real time" into "enough time for me to be able to keep up, you'll just have to wait".

    The only fixes are to throw more processing power at the engine, or restrict the engine to never allowing more units that the processing power can handle. Sounds like your other games are using the latter approach.
  19. mushroomars

    mushroomars Well-Known Member

    Messages:
    1,655
    Likes Received:
    319
    SupCom is one of the only games out there with real-time simulation, including gravity, projectile collisions, unit collisions, and live animations all rolled into one. Same goes for TA, which is why they were both so taxing to Computers at the times of their releases.

    I'm sure that PA will have multithreading, which will alleviate any random fluctuations in gameplay speed assuming you are using a multi-core machine. Which everyone in this room probably is.

    Anyways, I would rather have random fluctuations in gameplay speed than framrate drops. They both ruin the feeling of immersion, but one is less shitty than the other.

    Also, they can't just make the game "not slow down." If the server is a piece of crap, and all the clients have piece of crap computers, the game IS going to either run slow or have framerate issues. It's very similar to trying to bake a cake without the right ingredients; you may get something that resembles a cake, but it won't taste nearly as good as the real thing.
  20. syox

    syox Member

    Messages:
    859
    Likes Received:
    3
    Well for my simulations: Selforganizing multiprocessing helped allot. Only issue i had is the communication between them, but ramdisks and files there was enough for me. Also because i am a lazzy programmer i didnt had to care about allocation of memory. Because just shut down one process and create a new and shazam memory cleared.

Share This Page