“Nice game,” you’re probably thinking, “but can it be reduced to dry, boring diagrams?” It sure can!

Three sequential tile interaction diagrams

In these diagrams, rows containing yellow diamonds represent interactions between tiles (i.e. puzzle solutions, roughly speaking). A single row can actually represent multiple interactions that occur in sequence, so four diamonds don’t necessarily mean a single interaction involving four tiles.  A vertical line with no diamond means that the corresponding tile is not involved in the interaction represented by that row.

Rows containing blue squares represent tile states and state changes in-between interactions (e.g. the player may be navigating around within tiles, but tiles are not interacting with each other). A vertical line with no square means that the corresponding tile doesn’t undergo any important state changes at that point in the game.

If a line (coming from above) ends at a yellow diamond, that represents the end of the tile’s life; it has been absorbed through interaction with another tile. If a line begins at a yellow diamond, that’s the beginning of the tile’s life; it has been spawned by another tile. So from these diagrams we can see the lifetimes of different tiles as the game progresses. We can also see if one tile goes a long time without interacting with other tiles (it’s just a long vertical line passing through the diagram) which might be an issue.

Now consider the middle diagram above. There are a couple of rows that have five tiles. Not all five are involved in a single interaction, but they are all present at the same time. This is a potential problem if there are only four grid squares in which to put tiles, and situations like this are what led me to develop shelves.

But even with only four squares available, a five-tile situation isn’t necessarily a game breaker, because tiles can sometimes be stacked. We potentially have a novel situation, one where the player must find a way to stack tiles not (directly) in order to solve a puzzle, but simply in order to make space for another tile. Juggling tiles around like this could even constitute a puzzle in and of itself.

Or it might be a confusing headache. I could have made it possible to stack any tile on any other tile at any time (most of the time with no useful effect) but I chose not to do that because it could lead to tiles being lost and forgotten at the bottom of a pile. Forcing the player to stack tiles temporarily in the course of solving a puzzle could have the same problem.

So will I need to enable shelves or not? Or should I just tweak the design so there can never be more than four tiles at once? We shall see.

This is the first of a series of posts on the software tools and processes used to create Gorogoa. The first thing I’ll cover is how static images are created. The process is straightforward, and I basically developed it through trial and error rather than, say, consulting someone who actually knew what they were doing.

First I draw pictures, using pencil and paper. These pencil drawings consist of outlines and possibly some shading, but no color. I do the coloring on the computer so that I can change colors after the fact, or use the same pencil lines for multiple objects that are different colors.

Step 1: Pencil Drawing

I could use other “traditional media” like pen and ink for these drawings, but so far I’ve been sticking to pencil to achieve a consistent visual texture. Another option would be a digital drawing tablet, as some have recommended. I’ve never used one, so I have no sense of how well that would work. For now I enjoy the freedom of being able to draw anywhere with minimal equipment.

Early on I would often model objects in 3D (using Blender), print out renderings of those objects, and draw over the print-outs to get the geometry right. But that process was imperfect, and now most drawings of static objects are done free-hand (as in the example shown).

The next step is to scan in the drawing and run it through a simple process that converts the background color to transparency and does some contrast boosting. I could probably do this in Photoshop, but I have my own tool that does it.

Step 2: Processed Scan
(Gradient indicates transparency)

Then I clean up the drawing in Photoshop, and color it in. Generally I have one Photoshop layer for each colored region (all of which are underneath the layer containing the scan), so that I can go back and change individual colors later. Sometimes I’ll also harden up the lines and/or add shading and highlighting.

Step 3: Color and shade in Photoshop

That’s about all there is to it. In the future post I’ll talk about how 3D data is used in the game and how the different forms of animation are done.

I’ve been working on adding a new feature to the game, which I call “shelves.” These are areas to either side of the playing grid where tiles can be placed, either by the system or by the player. Tiles that are placed on a shelf become inactive, i.e. they can’t interact with other tiles. So the shelves are just a place to store tiles when there isn’t room for them on the grid (or the player wants them out of the way for some other reason). The main idea here is to allow more than four tiles to be in play at a given time.

This is not a change I undertake lightly. Simplicity is one of the main virtues of the design, and I don’t like adding visual or conceptual clutter. In general, the constraints imposed by the game’s minimalist construction are healthy for the creative process. But I find that the four tile limit is one constraint too many.  There’s a point in the demo where the player’s progress is arbitrarily blocked, only because allowing them past that point too soon could bring a fifth tile into play. I don’t think this sort of thing is good for the game.

In a sign that I may already be abusing my new-found freedom, one of the puzzle sequences I’m designing could yield as many as eight tiles on the field simultaneously. That may or may not be a good idea, but I want the breathing room to explore those options.

There are other ways I might achieve the same effect. One possibility is to add rows and/or columns to the grid itself. Adding rows would likely force the individual tiles to be smaller, but the standard rectangular aspect ratio of most devices should have room for another column without changing the tile size, so the grid could be 2 x 3. I’m not ruling that out, but I already want more than six tiles.

I’ve also considered doing away with the grid entirely, allowing cards to be placed anywhere on the field as long as they don’t overlap (this is the way jigsaw puzzle assembly interfaces usually work in video games). But that option would represent a big change, and I’d have to give serious thought to its implications.

So for now I’m trying this.