I play a lot of indie games, as well as a lot of itch.io stuff– smaller, shorter and simpler games. What I often notice, though, is that some of these games have really tiny but frustrating issues that could’ve been prevented, or moments where I just get stuck thinking the game glitched out.
One tool you could use to help to avoid these frustrating moments is playtesting, which will help you to spot the most obvious issues in your game that could prevent enjoyment. However, playtesting will face you with the ugly faces of your game– especially the first few tests, where you can see all of your game’s shortcomings. It can be depressing, and might make you reluctant to do tests at all. This post urges you to press on, because playtests introduce the element that completes your game: the players.
You will need to move the game out of the bubble it’s being developed in. When you give it to someone else, you will learn new things about your own game. These can be either good or bad, informative or not really helpful. You’ll need to learn to deal with that. Don’t make it the player’s fault (‘You’re playing it wrong!’), instead, look at where it is going wrong on the design level, as objectively as possible. It is human tendency to do this— I find watching playtests embarrassing, personally. It can be scary, but in the end, it’s for the good of the game.
In this post I explain which playtesting progress works for me. I playtest my games from time to time, so having a structure for organizing it is pretty helpful. It was designed to be efficient: get as much useful info from tests while organizing as few of them as possible. I’m intending this post for people who want to get started with playtesting, so if you already have a procedure that works for you, please stick to it!
For my own record, here are my favorite games I played in 2017. Just like last year, I don’t really mind if a game was released this year or sometime before—just that I played it in 2017. The list is no particular order.
(This post is primarily intended for those invited to playtest my games– but you might also find this information useful if you’re looking into simple recording software yourself. Enjoy!)
Recording gameplay footage creates the most useful information for me, while keeping the workload for you low, aside from actually testing the game. It can be a bit tricky to set up, so here’s how it works.
Please do a test run of your recording program to make sure it works and is set up correctly! Thanks!
I love UI and UX. It’s quite hard to design, and takes a long time to get right, but it’s so satisfying when you ultimately get it right. I’m currently working on the UI of my precision platformer Mobility, and I’ve seen a lot of both good and bad examples lately, so I thought I’d write about the subject more in-depth.
The goal of most UI, no matter if it’s for an application, a game menu, the interface of an operating system, or whatever, it’s to get the user from A to B as fast as possible. That means it’s both obvious to the users/players which actions they need to take in order to accomplish their goal, as well as having as little steps between A and B as possible. In the context of a game, this usually means that the player can get from booting the game to actual gameplay as quickly as possible, and for bigger games, that users can comfortably navigate inventory, shop and trade menus.
Let’s continue the tradition of explaining the design of my games using my latest creation, Sokobanana! I’m primarily making these so I can reference my design choices later in case I forget them, but I’m putting them on my blog for everyone to see. This contains spoilers for the puzzles of Sokobanana, so play that first so you know what I’m talking about. You might need to click ‘Read more’ to display the entire post.