Posts page

Typing Games: how and why?

Article

A beginner’s guide to designing typing games and exploring their niche market

A short article based on this genre study was published on gamedeveloper.com

If you already know some typing games, you probably have an opinion, good or bad. If you don’t know much about them, no worries, that’s what I expected. The genre is very niche, and for good reason: how odd to want to control a game with typing! It is indeed so odd that it brings unusual and pretty exciting design challenges. But the genre is so niche that there are few, if any, design resources available. That’s where I come in! I’ll try to give a good overview of typing games based on my personal experience as a game designer on Epistory and Nanotale, various typing games I’ve played, and interviews I’ve had with other typing game developers.

I plan to cover a bit of the history and background around popular typing games, then delve into the design considerations that typing poses and the solutions we can find. Finally we’ll look at where the genre is headed.

Continue reading “Typing Games: how and why?” →
Pages: Page 1, Page 2, Page 3, Page 4, Page 5, Page 6, Page 7, Page 8, Page 9, Page 10, Page 11, Page 12, Page 13, Page 14, Page 15, Page 16

A simple format to archive design decisions

Article

This article written during Nanotale’s development describes how we kept an archive of decision-making within the design documentation with the help of a few simple icons.

Before starting production on Nanotale, we took some time to prototype various typing gameplay ideas. When prototyping, you have to focus on the things you want to test, and iterate on them as fast as possible. There is no time to document everything. But the prototypes do not always speak by themselves. (Sometimes there is no playable build to keep, like the time I tested interactive dialogs by acting as the NPC and talking through Slack with a colleague. We will get back to that.) So we needed a way to archive what we learned from each iteration, in a format that would be quick to write and read.

Continue reading “A simple format to archive design decisions” →

“Solving patterns” in Shift Quantum

Article

As level designers on Shift Quantum, when experimenting with newly designed blocks (even before they were implemented) we identified and listed the different micro problems they could generate. Complex puzzles are built later by combining them. Each micro problem has a micro resolution pattern that the player has to figure out and learn. I call those atomic blocks of puzzle resolution “solving patterns”. Continue reading ““Solving patterns” in Shift Quantum” →

The problem behind the solution

Article

To get to what I mean with that enigmatic title, I should start with an example. A few days ago, with a fellow designer, we started working on the level design of a puzzle game. Because the project is in early development, we try and playtest different approaches. One of them is a large level with a lot of open space. Near the end, there is an empty corridor longer than the screen’s width.

Two out of five playtesters, while crossing that corridor, immediately asked for a sprint feature. Of course we expected that reaction: it takes just too much time to simply cross that level. But that’s why it’s a great example of the phenomenon I want to talk about. Is the scale of the level too big? Or the character too small? Maybe, but what players wanted, running through that corridor, was to press a button and sprint.

Continue reading “The problem behind the solution” →