For example: - Test driven development - Deploy, measure, iterate practices - High level languages
Most of which are rare in the games industry but seem to be very successful in the web industry.
Most of which are rare in the games industry but seem to be very successful in the web industry.
HTTP is also successful in the web industry. Perhaps game programmers should use it to pass around all their information.
Less snarkily, there is a reason why those things are popular in web development: they're good at it. There is a reason why C++ is used in game development: it's good at it. High-level languages are commonly used in scripting and game logic, but, if used in the engine, would slow it to a crawl.
With respect to "deploy, measure, iterate": I have a suspicion that such a methodology isn't entirely feasible in an industry that ships product in the literal sense of shipping product. It's easy enough to do A/B testing on a website. It would be a touch more difficult to do it for Half-Life, given that the install base is approximately everywhere and you have control of roughly none of it.
Unit testing is an excellent technique for any development environment but is sadly rare in the games industry.
Iterating on disc products is not simple :) Though a lot of metrics could be gathered for use on a sequel. During development though iterative development should be ( and often isn't ) absolutely fundamental. Trying to "create fun" is an incredibly difficult task and can only be done with plenty of feedback.
However I've never heard of TDD being used. Also C++ tends to be used as the proverbial hammer (e.g. for scanning debug output, build scripts). C# is quickly taking over for tools but it's also taking over as the new improved hammer.
Test driven development or more simply unit testing code, is writing automated tests that ensure your code at the smallest unit you can access ( e.g. a single method ) is doing what you expect under all conditions.
See: http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test
That having been said, TDD and automated testing can definitely make some headway into game development, but there are a whole host of challenges and questions to surmount there, especially for code-bases that are going to get stripped down to bare-bones every 1-3 years for a new game, if they get reused at all, so the tolerance for hacky code is quite a bit higher.
Of course, a "play test" is not an unit test, or an integration test (and is only mildly similar to an acceptance test.) Playtest-driven development would be an entirely new affair, likely involving gameplay freeze-states and kept in version control, and a constant numerical analysis for the player's emotional state (perhaps using some sort of face-recognition) given alternate code paths.