12 ms·
Steam could be a major force in turning around the recent slew of absolutely craptastic, completely broken, game releases recently. QA/QC should not happen at
by bane 11y ago
Steam could be a major force in turning around the recent slew of absolutely craptastic, completely broken, game releases recently.
QA/QC should not happen at the customer level.
- minimaxir 11y ago> Steam could be a major force in turning around the recent slew of absolutely craptastic, completely broken, game releases recently. This is an interesting comment because the primary suspected reason for the implementation of Steam Refunds was Steam Greenlight, which allows anyone to upload a game to Steam, and after community vetting, the game could be released on the store proper. Of course, many of the games were either poorly tested or use assets which the developers claim as original but are not. Steam Refunds fixes this in most cases Jim Sterling has a good showcase of these games: https://www.youtube.com/playlist?list=PLlRceUcRZcK17mlpIEPsV8gRg_Kjxuy_3 https://www.youtube.com/playlist?list=PLlRceUcRZcK17mlpIEPsV...
- Abraln 11y agoThe absolutely dreadful launch of Assassins Creed: Unity probably did not help. Consumer confidence was dropping fast, having a refund option encourages trying new things and takes some of the risk out of AAA pre-orders.
- SilasX 11y ago"We don't need unit tests because we have integration tests. We don't need integration tests because we have QA acceptance tests. We don't need QA acceptance tests because end users will report any bugs to us. We don't listen to user feedback because declining sales will tip us off to the problems. We don't pay attention to sales numbers because creditors seizing our assets will alert us of the shortcoming."
- rob_lh 11y agoI don't know if you're quoting or referencing something, but that's fantastic.
- SilasX 11y agoThanks! Just something I dreamed up one day when someone said "you shouldn't have unit tests for private methods because unit tests of public methods will catch them" and I extrapolated from there.
- pbh101 11y agoMy approach when I find myself wanting to test private methods is often to extract a new class, for which the methods under question form the public interface (working with Java here).
- malkia 11y agoIf you have an unit test on private members, then you can't change the implementation safely without breaking tests. The point of the unit test is to test the interface in isolation, not the implementation - e.g. do you really expect when testing a hash-map the elements to be in specific order, or do you test for their presence?
- yk 11y agoDepends. If we take the example of a library, then there are some tests which should never break ( except if the major version increases). But it is entirely sensible to check if you broke something internally during development.
- nicobn 11y agoThis is true for totally isolated unit tests but false for tests that require stubbing. You can theoretically use the same tests for a map implemented with one version of a hash table or the other. But once you start testing classes with dependencies, your tests inevitably touch implementation details. For example, unit testing a hash map that is backed by a memcached server would require some form of stubbing. The metatesting reason for this confusion is that in the example you used, the scope of unit testing is the same as the scope of integration testing. If a class has 0 dependencies, a unit test is also an integration test, because it tests all the dependencies of the class, of which there are none. So going back to your original point, your affirmation is true for full integration tests, i.e. tests that do not stub any dependency. If you do not stub your network connection to the memcached server, the same test - albeit with a different setup - can be used for a local hash table implementation.
- yoklov 11y agoI know you're joking, but it's pretty much infeasible to test the kind of bugs typical in games using automatic testing. So much is content driven, and the state space is far too large. Even for stuff that's fairly testable, like navigation, collision, etc, you have the issue of there being a million edge/degenerate cases, and it's very hard to know this never hits one in the game code or content. So the best you can usually do is test library code. Not that this has anything to do with AK, which sounds like plain old sloppiness.
- willvarfar 11y agoWhen the office staff go home for the day, their rubbish hodgepodge of PC varieties and specs should spending their evenings playing the game with a game bot.
- serge2k 11y agoOk, but in this case they chose to put in a 30FPS cap. Ignoring that performance is well below even that, they should have known it was unacceptable.
- maccard 11y agoWhy is that unacceptable? From the reports I've read re enabling the 30fps cap removes many of the performance problems. Some of the game logic can be hard coded to accept 33ms frame times, especially if the console versions are capped at 30 and the PC version is a port of them. They made a technical decision to cap it at 30, there's nothing wrong with that. If you don't agree with it, then don't buy it.
- lsadam0 11y agoI'm a developer, but not a game developer. Making the decision to hardcode game logic to only accept 33ms frame time sounds like a pretty dumb choice. I would wager that if your fix is to artificially cap performance of your software, then something in your code base sucks majorly. Call me crazy.
- kelvin0 11y agoI wish I could fit that quote on a regular coffee mug!
- johnchristopher 11y ago> Steam could be a major force in turning around the recent slew of absolutely craptastic, completely broken, game releases recently. > QA/QC should not happen at the customer level. With the exception of games running under Linux https://news.ycombinator.com/item?id=9757382 https://news.ycombinator.com/item?id=9757382 :).