3 ms·
Croteam applied lots of automated testing by bots in The Talos Principle to ensure that changes in level design cannot lead to a situation where the game canno
by wolfgke 9y ago
Croteam applied lots of automated testing by bots in The Talos Principle to ensure that changes in level design cannot lead to a situation where the game cannot be completed anymore:
> https://venturebeat.com/2014/11/04/the-talos-principle-underwent-15000-hours-of-playtesting-but-not-by-humans-interview/ https://venturebeat.com/2014/11/04/the-talos-principle-under...
> http://www.gdcvault.com/play/1022784/Fast-Iteration-Tools-in-the http://www.gdcvault.com/play/1022784/Fast-Iteration-Tools-in...
- sk0g 9y agoThat's not TDD, really, but it's a clever way of testing both the AI, and level changes, to a certain extent. If you drop a fucking boulder and you can't cross it yeah, it will light you up with red floodlights, but if a certain corner drops you into the nether... Unless the AI also knows to check each possible interaction, movement, etc.
- majewsky 9y agoCan you clarify why you do not consider this TDD?
- wolfgke 9y agoI think that if one is meticulous, sk0g is actually right (source: https://en.wikipedia.org/w/index.php?title=Test-driven_development&oldid=790275486#Test-driven_development_cycle https://en.wikipedia.org/w/index.php?title=Test-driven_devel...): In TDD one begins anything (in particular any new feature) with writing a test for it, then one runs all tests to see if something fails and only then starts to write code if necessary until all tests pass.
- sk0g 9y agoIn TDD you only write code if it makes a red light green, so to speak. First you make the test, then you run it. It will obviously fail, and then you implement code that starts passing tests.