I think the Valve ones stay and the non-Valve ones disappear, but I'm not sure. I know if you never install Dota 2 or TF2 they never get added to your library, but I don't know what happens when you uninstall them. |
It's just the number of people that have the game in their libraries. So if Warthunder shows up in your Steam library, it's being counted in these stats. That means every person who installs the game adds one to the purchased stat, and every person who uninstalls the game subtracts one from the purchased stat, since I'm pretty sure F2P games disappear from your library when you uninstall them. |
In your original post, you told Relic to "follow [Valve's] example" and "hire more people" so they can, as implied by the blog post you linked to, fix bugs like Valve fixes bugs. Except Dota 2 has less people working on it than CoH2 does, so your entire argument that more manpower = better bugfixing has no factual basis in reality, since the accomplishment you're using as your main piece of evidence was achieved with less manpower, not more. When this was pointed out to you in clear terms, you continued to defend your baseless argument despite having zero supporting evidence beyond the blog post you initially linked, which is actually evidence against your position as I pointed out above.
http://en.wikipedia.org/wiki/Brooks%27s_law
Please inform yourself before you pretend to have a clue about how software development works. |
Getting 6-pooled, proxy 2-gated, cannon rushed, proxy 2-raxed, or 4-gated makes the game easy to get into?
When you play CoH2 you don't have to worry about economy, workers, base building, expanding, buying detection, macroing, upgrades, etc.
For a player who's never touched an RTS before, SC2 is infinitely more complex and difficult to play than CoH2 is. Saying people prefer SC2 to CoH2 because CoH2 is more complex doesn't make sense, because CoH2 isn't more complex. It's different, sure, and it's less familiar to people who are used to traditional RTS games. But it's not even close to being more complex. |
i would consider all those to be at least somewhat related to solving gameplay engine bugs. there's also the issue of whatever those people are supposed to be doing either not being done or cutting into someone else's time.
dota 2 is also (as far as i can tell, having played ~~60 hours of it) in much better shape, balance and bug wise, than CoH2 and (again, as far as i can tell) has much better analytic tools available to the people working on it. theoretically, once you reach a certain point with a game you only need one or two part time balance devs and occasional time from a programmer to keep a game balanced. RET had only bC on it for several months and it was *mostly* fine. as time goes on the amount of effort required for fixes should decrease as the slop is taken out of the system...
the coding problems, pathfinding in particular, are fairly complicated but the balance issues mostly come down to making changes to a spreadsheet and then testing said changes with a heavy does of judgement involved. more manpower means that changes can happen faster and they're easier to test test, provided everyone involved has decent judgement and is properly supervised.
You think HR and community management are related to solving code bugs? Umm...
Dota 2 never had a team in excess of 50 people; even at its largest, Dota 2's team was smaller than CoH2's. Again, you think more manpower is going to help CoH2 because...why, exactly?
Regarding the state of Dota bugs: http://dev.dota2.com/showthread.php?t=127919
You linked to a blog about a bug fix and used it to complain about Relic not fixing bugs. Now you're talking about balance, as if the two are related at all in terms of who works on what. You're fairly clueless aren't you? |
You have to worry about positioning just as much in SC2 as you do in CoH honestly, just in a different way. And micro in SC2 is mechanically much more difficult because you have a lot more units and therefore need a lot more actions to micro effectively, while maintaining your macro at the same time.
SC2 is far more complex mechanically than CoH2. It's not even comparable. |
Maphacking is impossible to prevent in client-side games, and making an RTS server-side is impractical. Relic has also shown an ability to detect maphacking through battle servers, as evidenced by their ban wave on maphacking a while ago.
In reality, the vast majority of "hacking" incidents people report or complain about are just better players with better game knowledge. In the years of play and thousands upon thousands of CoH1 games I played, I never once suspected an opponent of maphacking. It's really not as prevalent as people want to believe. |
Are you purposefully ignorant? Because it's clear you haven't read a word I've said. And since when are Art Directors, Senior AI Artists, Data Analysts, Executive Producers, Financial Controllers, HR Coordinators, Associate Brand Managers, Cinematics Artists, Communications Coordinators, Community Managers, AI Programmers, or Tools Programmers responsible for gameplay engine bugs? There is a single Relic job posting right now related to general programming. Please get your head out of your ass.
Dota 2 has a team of 28, including designers, programmers, and artists; they have access to far less raw manpower than Relic does. More people are working on CoH2 than Dota 2 right now. Tell me again how important manpower is to bug fixing? |
Why do you think manpower would suddenly fix bugs? Valve didn't fix this bug because of manpower. They fixed this bug because they added a fuckload of debug material to their replay files and were able to use that material to find the source of the issue once they got their hands on a replay that reproduced the bug. Neither of those are very manpower-intensive operations; the entire process was probably done by a single programmer.
http://en.wikipedia.org/wiki/Brooks%27s_law
Adding manpower, especially to maintain code, more often than not results in more problems and does very little to increase the rate at which current problems are solved. You need to train your programmers, let them become familiar with the codebase, and make sure they don't fuck something up because they don't understand why something was done a certain way. It takes an incredible amount of time and effort to get a programmer up to speed with people who have been working on a product since pre-release, and more often than not they're going to introduce new issues while they're ramping up because it's impossible to understand every single nuance of a complex codebase until you've worked with the codebase for an extended period of time.
http://www.giantbomb.com/dota-2/3030-32887/credits/
Those are the credits for Dota 2.
http://www.mobygames.com/game/windows/company-of-heroes-2/credits
Those are the credits for CoH2. CoH2 has a whole lot more manpower dedicated to it than Dota 2 does. Manpower means jack shit. |
It literally took them months to find and fix that bug. The entire purpose of that blog was to show idiots that bugs are fucking difficult to find and fix unless they're extremely fucking obvious, in which case the bug probably would've been fixed before it went into production. There's no "example" to follow here, it's just one programmer giving a little insight into their debugging process and showing people why you can't magically fix shit overnight, which nobody who isn't in software development seems to be able to understand.
If you can't accurately and consistently reproduce a bug or find the single line of code in thousands where the bug occurs, you can't fix it. I work on systems with bugs that have been around for years, because they happen once every few months in multithreaded projects with hundreds of source files and thousands of lines of code and can't be reproduced. Unless you can reproduce the issue or get it to happen in a debug environment (which Valve essentially forced here by dumping so much debug info into the replays that they just needed a timestamp to get what was probably the equivalent of a complete memory dump at that exact time in the game), there's probably nothing you can practically do to solve it.
Also, adding programmers generally leads to a reduction in software quality, not an increase. Relic hiring more people would likely cause more problems. |