Carriage Defence
User Playtester & Designer
Core information:
-
Developed a system to collect game data from playtesters remotely.
-
Created visualizations of playtest data sets to inform design decisions.
-
Identified design hurdles, proposed solutions, and tested the results.
Concept
An inverted tower defense game. Players traverse a path defended by barriers and bullet-shooting turrets. To protect their character, players use a shield. Every level contains multiple rounds of increasing difficulty (each round adds new turrets and barriers to the path). Between rounds, players can purchase defensive structures (speed boosters or walls) and health.
Process
To be able to collect playtesting data, I created a script that sent game session logs to an email account whenever a user closed the application. These logs contained the following information:
-
The playtester's identification username.
-
Number of attempts performed on each level.
-
Completion rate of each level.
-
When, where, and how players had lost health at a level.
-
What power-ups players had purchased and when they did so.
-
A screenshot of the game state when players died or when a level was completed.
With that information, I was able to:
Visualize Player Damage
I created scripts to help visualize where players were taking the most damage in a level (in red in the image below). Simultaneously, I used the same systems to visualize which sources of damage were the most effective (in green in the image below).
Afterwards, I was able to:
-
Discover useless defenses (they couldn't hit players due to their positioning).
-
Identify unfair situations for players (points in a map where players got hit almost every time).
-
Highlight boring sections in a level (parts of the level where players had few menaces to deal with, thus making the game less engaging).
Statistically evaluate the game's economy
An analysis of how each player engaged with the game's economy revealed:
-
Overpowered and underpowered objects.
-
Poor discoverability of certain power-ups caused by bad UI.
-
Behavioral differences between recurrent players (who had played previous iterations of the game) and new players caused by the new in-game tutorial.
Create a fair difficulty curve
The completion rate across multiple iterations of each of the levels revealed that:
-
The overall difficulty was too high in early iterations.
-
The first level's high difficulty was frustrating and prevented new players from advancing to levels 2 and 3.
-
The challenge presented by levels did not escalate.
All of this information and more was compiled in a data-driven design report that can be downloaded here.
