A simple format to archive design decisions

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

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

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”

Handmade vs randomized level design in Epistory

This is an old article that was written as a dev blog post for Epistory, a typing adventure game and the first project I worked on at Fishing Cactus.

The problem

As in most puzzle / adventure games, Epistory’s level design, is designed manually from the world layout to the smallest puzzle. But to save time and money, we need to automate everything else, like generic and repetitive patterns or effects that give life to the world. That is what this article is about: the level building of all the things that are not unique or designed for a specific purpose. Continue reading “Handmade vs randomized level design in Epistory”

Epistory is not your usual typing game

This is an old article that was written as a dev blog post for Epistory, a typing adventure game and the first project I worked on at Fishing Cactus.

It all starts with (good) intentions

When you start creating a game. When you think you have a great idea to turn into a great game. When that idea has just been tested and when your team thinks it may very well become that great game you have in mind. There is something you know you must do. You may have already done it during the early design process but the original vision has changed now that you made different rough gameplay tests and added new members to the team. That thing – the title already spoiled it – is defining your intentions. Continue reading “Epistory is not your usual typing game”