4 ms·

I'm not sure I agree with the whining part, there is also an awful lot game developers could learn from web developers. For example: - Test driven development

I'm not sure I agree with the whining part, there is also an awful lot game developers could learn from web developers. 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.

phsr 17y ago
Game Development is test driven...When they play the part they just coded, isn't that testing?
- daredevildave 17y ago
  Not quite the same thing, you are talking about QAing the product. 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 http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test http://en.wikipedia.org/wiki/Unit_test
- bendotc 17y ago
  That's barely even testing, and it's certainly not TDD. If I play through the feature I just coded or the bug I just fixed, I can verify that it's doing what I think it's doing, but I need outside verification that it's correct. In effect, I can verify my code's precision (it's doing precisely what I told it to do), but not it's accuracy (if my idea of a feature is inaccurate, my own testing won't catch that). 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.
- derefr 17y ago
  I don't think you understand the significance of the word "driven." Coding something and then testing it is not TDD. In TDD, you don't write any application code that a failed test doesn't demand in order to pass—and even then, only just enough to make that test pass, even if it just means alwars returning 4 from a rand function. 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.
gloob 17y ago
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. 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.
- daredevildave 17y ago
  I agree, there is no way a to-the-metal game engine will be written in any apart from C/C++ for a while. However, there is no reason why the higher level logic of the game ( the bit that is done by the designers/gameplay programmers ) shouldn't be done in a higher level language. 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.
teamonkey 17y ago
Others have pointed out that C++ is a necessity for at least the high-end games that push the hardware. High-level languages are used for scripting and logic (especially Lua). Deploy-measure-iterate is often used in the after-market for those games where it is appropriate, and in-house before release. 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.

phsr 17y ago

Game Development is test driven...When they play the part they just coded, isn't that testing?

daredevildave 17y ago
Not quite the same thing, you are talking about QAing the product. 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 http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test http://en.wikipedia.org/wiki/Unit_test
bendotc 17y ago
That's barely even testing, and it's certainly not TDD. If I play through the feature I just coded or the bug I just fixed, I can verify that it's doing what I think it's doing, but I need outside verification that it's correct. In effect, I can verify my code's precision (it's doing precisely what I told it to do), but not it's accuracy (if my idea of a feature is inaccurate, my own testing won't catch that). 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.
derefr 17y ago
I don't think you understand the significance of the word "driven." Coding something and then testing it is not TDD. In TDD, you don't write any application code that a failed test doesn't demand in order to pass—and even then, only just enough to make that test pass, even if it just means alwars returning 4 from a rand function. 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.

gloob 17y ago

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. 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.

daredevildave 17y ago
I agree, there is no way a to-the-metal game engine will be written in any apart from C/C++ for a while. However, there is no reason why the higher level logic of the game ( the bit that is done by the designers/gameplay programmers ) shouldn't be done in a higher level language. 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.

teamonkey 17y ago

Others have pointed out that C++ is a necessity for at least the high-end games that push the hardware. High-level languages are used for scripting and logic (especially Lua). Deploy-measure-iterate is often used in the after-market for those games where it is appropriate, and in-house before release. 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.