Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Mustrum_Ridcully" data-source="post: 3803529" data-attributes="member: 710">I think one of the problems with playtesting a new game system is that the players are simply so unfamiliar with it.Imagine they would really need to digest all the rules first and than create new characters, and play them to level 30. That's obviously impossible in the given time frame. (You can't extend test times infinitely, because you need to sell the product before you run out of money <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /> )So, the approach is probably: Let's build several sample characters at different levels, and provide the players with some encounters they have to "beat". The players still have a lot of catching up to do, but you remove a lot of the initial build-up. And you can also improve the test coverage. In software testing, unit-testing is a very typical part of testing. This means you don't test the whole application, you test small subsets (units) of it with test data - does this method/function/subroutine return the expected results with the given test data? You will also later have some component/module testing (does this sets of methods/functions/subroutines work together as expected)Even later you will make a system test and check if all works together.Selecting test data is also important - you have two approaches - black box and white books. In case of black box testing, you only consider the interface specificiation of the testable unit (which gives you what type of data you can enter and what types of outputs you should expect). In case of white box testing, you look how the codes actually behaves dependend on input values and (warning: simplified) try to cover each possible path through the code.On a D&D base, a single unit test is probably something like a skill or BAB. Quickly tested.A Component Test might be test for a class or the spell system. More difficult to test, but at this point, play testers can't really help you much, as you can't "play" just a class.A System Test would be the real play-testing. Now, you get to choose your "test data" to input.Black Box testing would probably be: "Take these characters and see how they fare in these encounters".White Box testing would probably be: "How does Fighter Build 1 compare to Fighter Build 2 in this encounter (or maybe even: How does this Melee Warrior Build compare to this Spellcaster Build in this encounter?)". I am not sure how much White Box testing is actually done in playtesting - This is probably the point where you really test the fineprints of your system and find the hidden roads to unholy (Wotc Boards) Character Optimization. But there are so many possible builds and thus test cases that testing it all might take forever until you find something. So, this might be the type of "bug" that the user finds out at home... <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /></blockquote>

Verification