Playtesting and Results

We learned trough the last projects at university that it is quite helpful to have a constant play test schedule that gives a bit of feedback every week. This way we can always be sure that we are actually working in a direction that shows the desired results and see problems when they arise more quickly.

Another benefit is that this encourages having a playable build ready at all times, which in turn encourages everyone to see that their content is added to the current development branch from which we do the builds.

Our schedule was at first to have a play test each Friday, something we changed to variable days during each week later in the project as Friday tented to be quite a long day otherwise even if everything went smoothly.

Each playtest was supervised by at least one team member, who took notes and spoke with the playtester after he had filled in the Document shown above. The Idea here was to have a easily "quantifiable" side of the feedback trough the documents, but on the same time to also make sure we gather the more personal feedback and information that would present itself.

Later on we also added a screen recording via OBS to the playtest setup, that allowed us to find bugs that surfaced during the playtest and better understand the circumstances of their appearance in the game, allowing for faster bugfixes.

I gathered the results of our biggest Playtest in one Document and tried different ways to visualize parts of the results.

For me it was actually quite surprising how much clearer the sight of a pie chart or a simple bar chart displaying the results can be, compared with simply stating the numbers given for each answer.

For future Playtests I will make sure to go the extra mile and represent them in this way, as it tends to be way easier to show to the rest of the team, and if done consistently should allow to show the game getting better trough the feedback it gets.

Playtest Results as PDF File

As the development of Pandemic was plagued by a variety of different roadblocks of all sizes, upholding the planned play test routine was one of the first things that fell apart.
I decided that instead of forcing them to happen, I would focus my effort on other parts of the project, as we already had enough positive feedback for the core game at this moment and even if we screwed up now the core game play would still be enjoyable and hopefully carry the rest of the experience.

As we only managed to pull the whole Project together in the last view days I am glad to have made this choice, as we otherwise would had not enough time to reach a presentable final build for the deadline.

Additionally, play testing every week at the beginning of the project proved to be detrimental for bigger tasks. As some aspects of the game were not far enough implemented when they where tested they tended to get quite harsh and bad feedback. Especially two of our combat systems could have worked, in hindsight, if we had worked longer with them, but we cut them out after getting quite a lot of negative feedback for them in an early still barely working stage.

My main Takeaway here is for future projects we will only include those parts of the game that are already prototyped well enough to work halfway decently, or if not possible otherwise to keep from changing things to fast based on feedback on such "early" concepts.

In order to achieve this, my current plan would be to do play tests on a biweekly basis, corresponding to our two week project Milestones. This should give us enough time to put more time into deciding which parts of the project get into the current build, and what to look out for during the play test.