One last bone before v1.11 is uploaded for you guys... v1.11 brings back the much "discussed" Blue Bar for WeGo players. Yes folks, you read that correctly
Since this is no doubt a big (and good) shock to you all, I think it's a good idea to let you all know how it came to be. Years of doing this with you guys has proven to be beneficial to both customers and to us. The more you understand how it is CM is made the better quality of the discussion here. Well, excepting the crazies that invent their own story and then keep confusing it with the truth year after year. For example, some 13 years later I still occasionally see a known nutter insist that CMBO was originally based on ASL/SL (it never was). Well, mental defects are a life-long problem, so I guess we shouldn't be surprised that education doesn't help
OK, so here's the scoop...
As some of you might be aware of, soon after v1.10 was released a handful of people began to report massive performance drops when playing large battles. This issue was quickly confirmed to be real, not driver related, and not within the player's ability to influence. It was dubbed the Slideshow Problem because when triggered the FPS went down to literally a fraction of a frame per second. Definitely not a reasonable framerate hit!! Thanks to the help of some internal testers and external guys having the problem, Charles found the causes.
Without going into low level detail, the root cause of the problem was a combo of things... medium to low end systems combined with large scenarios and WeGo play. When playing under these circumstances a time came when a lot of units from both sides were in combat and maneuvering for advantage. The normal WeGoer reaction to this is to issue/reissue lots of Target and Movement commands to optimize the situation for the best results in the next 60 seconds. The problem CM experienced was that in the first mili-second of the following turn it was being asked to do a ton of work simultaneously. People with higher end computers may have noticed a slowdown here or there, but not a complete overwhelming crush of number crunching. RealTime players, on the other hand, tend to micromanage units less and to give instructions over a longer period of time. Hence, demands on the computer aren't as concentrated nor as heavy. They probably never saw this sort of problem, ever.
Looking at it now we think the Slideshow Problem came about mostly because of improvements in v1.10's basic functions. Marginal systems using earlier versions of CM:SF went from milder symptoms (i.e. poor framerates, "scarecrows", etc.) to problems which made the game completely unplayable. As unintentional as this was, there was no rolling back the improvements that v1.10 brought to the table. Therefore, we faced a choice... raise the minimum specs for future customers and tell current ones that they can't play big scenarios OR find a way to relieve the bottleneck for systems that can't handle CM as it is now. It wasn't much of a choice in our minds!
The best fix was to recode WeGo so that it pre-computes all the action before showing it, just like CMx1 did. I say "best" for three reasons:
1. A significant number of customers have asked for this feature, primarily so they can skip ahead during turns where there isn't much action going on.
2. Recoding the routines that were choking up computing resources would take a LOT longer and might not make a dent in the problem. And worse, what would happen when we put in more improvements down the road? Get us right back to the Slideshow Problem, most likely.
3. The return of the Blue Bar wouldn't negatively affect any existing or future customer in any significant way.
So the choice of reintroducing the Blue Bar was a win-win for everybody. So why didn't we do it earlier, if it is such a great thing? Simple answer is... we didn't think it was necessary or, for a while at least, possible. A card carrying member of the Blue Bar Brigade might question our definition of "necessary" , but that's the difference between customers and developers... developers have to be pragmatic.
As some might remember, and a search of this Forum will reveal (I know because I double checked before writing this ), I argued against many of the reasons why people thought the Blue Bar was "necessary". Too many people let emotion cloud their arguments and initially we got a lot of abuse and too little rational dsicussion. Many of the arguments blamed perceived, and real, shortcomings of various features on the lack of the Blue Bar. The arguments, therefore, were that the Blue Bar would magically fix various things listed. Even further, some felt that the ONLY way this or that issue would be fixed was to have a Blue Bar. Since many of the assertions were nonsense, and proven so since, we feel quite strongly that not reintroducing the Blue Bar back then was the right thing to do.
Having said that, there was one consistent point made about the Blue Bar that I agreed with. Although I personally didn't think it was a big deal, I did see the desirability of skipping through a "boring" 60 second replay. But there were a couple hundred other rational and desirable suggestions that we felt were more important, so we focused on those first.
On top of comparative prioritization of customer requests, there were a ton of things that needed to be tweaked/fixed before precomputing turns would have been technically viable as a stable feature. The irony is that if we had tried to implement the Blue Bar a year or so ago it would likely have caused more problems than it solved. Now it was implemented without too much difficulty, therefore it didn't have a significant negative impact on the development schedule.
In fact, because of the maturity and stability of the code in general terms, Charles found that he could de-couple the display of the graphics with the math behind them without too many technical problems cropping up. What this means is that turn computation can go faster than realtime on systems that can handle the load being asked of it. In practical terms this means that most people, most of the time, in most scenarios can generally have a turn's resolution crunch in less than 60 seconds. Therefore, if a turn's replay is skipped completely the player may spend significantly less than 60 seconds to get to the next turn. Unfortunately, the opposite is also true... when a turn's replay is not skipped the player will spend more than 60 seconds (max is 120 seconds) before getting to the next turn. In v1.10 and earlier the time was always 60 seconds no matter what. The good news is that if the testers' experiences are representational of the average customers', things should even out so that a WeGo game in v1.11 takes about the same time to play as v1.11 BUT with the advantage of being able to skip through "boring" replays. If true, it's probable that a game won't take any less time to play than before, though it might feel like it because of skipping over "boring" parts of the battle.
In the end this is a win-win for everybody. The Slideshow Problem is gone, middle to lower end players have a better game experience (even in RealTime to a lesser extent), WeGoers have the ability to skip "boring" replays, total gametime is probably about the same, and we've got one less concern as we move along with Normandy development. All good
Steve
Bookmarks