The game I’ve been working on as part as an university project was announced recently, and I’ve been responsible for the UI and UX for it. It falls into multiple genre boxes, including “adventure”, “open world”, “zelda-like”, “farming”, and more. From the get-go, it was clear this project needed a lot of UI, and user friendly one as well. That’s where I come in, and use this post to explain what that process was.
Two years ago, I had an idea for a platforming game. I love the genre, and it wasn’t the first platformer I had made. I had already made a dozen games, from jam games to multi-month projects, but none of them really managed to get a lot of attention. Would my design skills finally be good enough to make a game that would reach an audience, unlike my previous twelve games? Little did I know that it would take more than two years to get the game to release, and even less that the game’s reception would go well over any expectations I had.
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!