<div class="gmail_quote">On Tue, Jul 14, 2009 at 9:58 AM, Travis Howell <span dir="ltr"><<a href="mailto:kirben@optusnet.com.au">kirben@optusnet.com.au</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The main problem with using the same people to testing games (especially<br>
those with multiple game paths) each release cycle, is it is far too<br>
easy to get tired of those games. With people only playing the essential<br>
parts more and more, each release cycle.<br>
</blockquote><div><br></div></div><div style="text-align: left;">That would be my concern as well. Something else that occurs to me, though, is whether we could leverage the event recorder with such a role. I personally feel that a proper event recorder would make release testing much easier, particularly if you could play games back at higher speeds (sfx and music included). That way, it would be easy for 'testers' to ensure a given game has no crashing bugs, or obvious graphics glitches in it, without having to remember all the actions in the game.<br>
<br>On Cruise, for example, I keep needing to refer to a walkthrough when I've been testing rapid complete play-throughs (which I did whenever I changed any core functionality), since so much of the game is asking specific quesitons to people or finding an object which just appears in an area you may have previously searched.<br>
<br>My point is that a 'tester' position may be worthwhile, but I think only if we can supplement it with a functional event recorder and playback. Otherwise I think that testers may be get weary of testing the same test of games each time.<br>
<br>Paul.<br></div>