Early testing fixes problems that would be a behemoth to tackle later in the development cycle.
I had to expose my early builds to people for criticism in order to achieve this benefit. I gave it to a few friends, didn't say anything, and just observed.
I did my first round of testing with "Move the Blocks", aka MTB (just a placeholder name), as soon as I had a playable demo of the game.
For background, MTB is a casual action puzzle game where the objective is to move obstacles out of the way of a ball circumnavigating the screen.
Building the Minimum Viable Game
Like a minimum viable product, a minimum viable game lets you iterate and adapt your game for greater success.
Game Mechanics
First, I got the basic rules and game mechanics working.
For MTB, that includes being able to move the blocks around by tapping and dragging on the screen. The other main mechanic is seeing the ball circumnavigate the screen and start over whenever the ball collides with anything.
Art
The assets are all currently just "Programmer art" (stand in art if you don’t have the real thing). It conveys basic visual cues. For example, there are some blocks that you can move freely and others that only move horizontally. Horizontal blocks have horizontal stripes to convey the movement pattern to the player. This won't be the final art in the game, but a similar visual cue will exist.
Level Design
I then designed levels and built in player progression. I completed 10 levels before I handed it over to testers. Each level doesn't necessarily get harder, but it might teach the player a new mechanic or add difficulty to what the player already knows. 10 may sound like a lot, but each level in MTB lasts about 10 seconds (without dying of course).
Testing the Game
I gave it to a few friends to test out. Without explaining any of the rules, I asked them to try out this "action puzzle game" I was working on. I wanted the game to be straightforward enough from the user interface and game design that even a few short instructions were not needed to play.
The testers were not necessarily gamers, and even if they did game, they don’t play casual puzzle games frequently. I want the game to be playable for everyone, so they did just fine.
What I learned
Everyone eventually got through to the end of the 10 levels. No one struggled extremely hard and no one got through without dying at least a few times.
There were still many aspects that needed improving.
The first level is extremely simple, as in, you can't lose simple. But people were confused about what the goal even was. My next iteration will have a different level 1.
There needs to be more feedback when the player dies and when the player collects a coin. The coin is just a bonus objective for the level and acts as the currency for the game. People were confusing it with the ultimate goal and didn't even see their money count go up after they collected it.
Graphic and audio cues will help with player feedback when they collect a coin or die. For example, I can add sounds and particle effects when they collect a coin or flash a death symbol upon death.
I also realized that I was introducing too many mechanics too early. I wanted every new level to introduce something new. For a game where each level is no more than 10 seconds long, that can be a little much. Having levels that get players use to existing mechanics will help with practice for tougher parts of the game.
For level progression, I want to reorganize the first 10 levels and then get to a total level count of 20. Constantly iterating and improving player progression will help get new players skilled at the game. The less frustration for new players, the more likely they are to get hooked.
Lastly, getting non-programmer graphics, music, and sound effects always loom ahead. Ideally those would evolve along with the game. For now those will have to wait.
This Minimum Viable Game idea has already given me things to work on. I look forward to the next iteration I can show people.