You may have noticed that I haven’t been posting updates for the past few weeks. My computer hasn’t been hooked up and so I couldn’t work on the game. Instead I’ve been finishing off a major move.

The house we’ve moved into really should have been cleaned before we moved into it, so it’s been a bit of a challenge to clean thoroughly with all our stuff in the house. So a lot of that has been happening, as well as repairs and general moving stuff. Still hard to relax as most things are not really “in their right place.”

I did finish setting up my computer and desk and did a short test stream earlier this week to see if the internet here was decent enough to use for streaming (in short: it isn’t). So, barring a miracle, if I do any work streams going forward, they will be more of the Starbucks variety that they were a few years ago.

Unfortunately, I didn’t really find the gumption to sit down and work on the game any more than just that short test stream. On the stream, I added a little bit of a color difference for the puzzle panel backgrounds depending on whether or not there are active tiles.

It’s a pretty small change, but it should make panels a bit less confusing for new players. I’m still not 100% happy with the look, but it’s a step in the right direction.

I’m hoping to get some more done on the game in this next week. Still lots to do around the house though, so we’ll see.

Seems like I’m writing these things on Mondays most of the time now…

Didn’t get a whole lot done over the weekend, at least not visibly. Most of the work was under the hood or maintenance. I repaired the puzzles which mix the “dice” and “dot” mechanics, after having changed the way the dice mechanics work. The combined puzzle sequence stills need a lot of work to be enjoyable to solve, but at least the puzzles aren’t actively broken anymore.

I got them working again through a small change to how puzzle solutions are validated. Previously, with the dot mechanic, whenever the color of two dots needed to be checked, the code would use an arbitrary number which specified which color dot we were talking about. (i.e. 60 = blue dot, 61 = yellow dot, 62 = red dot, etc.) The change I decided to make is to have it actually directly compare the color values of the two symbols in question. (Technically I compare an integer hash of the color to avoid the == operator overhead of Unity’s built-in color class) Directly comparing colors has a couple benefits when it comes to simplifying the code and also makes future puzzle possibilities much easier.

I didn’t end up revamping the entire puzzle panel system, because after some further investigation, there are some good reasons that I architected it the way that I did, in spite of the fact that it’s unwieldy at times. The main reason is that I’m relying on the Unity serialization system to save the panel layouts, and certain data formats just serialize more straightforwardly and quickly. One dimensional data type arrays are the most easily serializable format. So, even though it would be more useful to have a single tile structure which stores all the relevant data, including references to spawned GameObjects at runtime, it is a bit more challenging to implement than it would immediately seem.

Furthermore, serialization can get real nasty when dealing with null references, as stated on this page in the Unity docs:

Consider how many allocations are made when deserializing a MonoBehaviour that uses the following script.

class Test : MonoBehaviour
{
    public Trouble t;
}
[Serializable]
class Trouble
{
   public Trouble t1;
   public Trouble t2;
   public Trouble t3;
}

It wouldn’t be strange to expect one allocation: That of the Test object. It also wouldn’t be strange to expect two allocations: One for the Test object and one for a Trouble object.

However, Unity actually makes more than a thousand allocations. The serializer does not support null. If it serializes an object, and a field is null, Unity instantiates a new object of that type, and serializes that. Obviously this could lead to infinite cycles, so there is a depth limit of seven levels. At that point Unity stops serializing fields that have types of custom classes, structs, lists, or arrays.

Since so many of Unity’s subsystems build on top of the serialization system, this unexpectedly large serialization stream for the Test MonoBehaviour causes all these subsystems to perform more slowly than necessary.

I may yet return to make some more of those changes, but you can see that the water is fraught with peril. A good approach would probably be to have two formats, one for all of the runtime code, and one that is used for serialization, but this would also create a bunch of potentially slow startup code every time the game was run in order to translate between the data formats (and there’s already more initialization code for the panels than I really want there to be)

On a humorous note, before some of the changes I made, I had this monstrosity of a line of code:

symbol = litSquares[p.x+width*p.y].GetComponent().transform.GetChild(1).gameObject.GetComponent();

And now, with some data restructuring and a few helper aliases, it becomes the much more manageable:

symbol = tiles[p.x+width*p.y].symbols[0]

Bit of a short update this week, but I’ve been busy with life things (moving, putting in a mailbox for four hours), and I didn’t have much free time left to work done on the game.

A few posts back, I wrote about some ideas for revamping the “dice face” mechanic to remove the requirement that the player remember that “white = black” for every panel in order to solve it. So this weekend I worked on taking some steps there. That work was streamed live, so if you want all the details, you can check out the archive here. (although there are a few spots where YouTube didn’t like the music and I had to mute the audio)

I will still have to redesign the start of the area in order to have more interesting puzzles, but I am fairly happy with how the change went. In fact, there are now some interesting ambiguities to play with there that I can probably exploit for more depth.

Unwieldy Puzzle Panel System

I probably need to make some changes to the puzzle panel system in the game, both in order to accommodate a few of the existing puzzles which have become broken after changing the dice face mechanic, as well as for some new ideas that I haven’t implemented yet. I am pretty concerned about how to go about making these changes, particularly without fundamentally changing the way that the puzzle panels themselves are implemented.

Some of the unwieldy aspects are just the interface I use for editing puzzles, but I think the main issue is caused by a design choice that I made early on to shrink the memory footprint of the panels themselves. Essentially, each puzzle panel is just a series of 2D arrays (technically stored as 1D with width and height variables) for each thing that we might want to know about the tiles on the panel.

This was not really a big deal when there were only a few things that we might want to know about the tiles, but at this point, there are 5 different arrays for each panel. That’s not an obscene number, but I am fairly certain that to accommodate all the features I want, I will need to add 2 or 3 more arrays. That’s 8 different arrays that all have to be shuffled around separately.

At that point, it becomes pretty obvious that the data related to each tile should be bundled up. That way we can work with just one array of structs or objects that stores all the relevant data, and easily expand the structure and support each new additional feature without many unexpected code changes.

I have a few concerns with how this will affect the saving/loading code system, but it hopefully shouldn’t be too bad. Overall, it’s just a big revamping project on a core system and I never look forward to those because you end up touching a lot more code than you expected to and possibly breaking some things in the process.

A bit late on this post, but hey! Better late than never.

This weekend, I streamed some work on improving the starting area. Managed to get in a few non-trivial puzzles to cap off the area a bit better and introduce the concept of locked tiles. Locked tiles are just tiles that you cannot toggle from their starting state. Here’s a screenshot of those new puzzles ( a bit low quality cause I snapped it from the stream video):

I also changed the game from an oblique renderer back to an orthographic one. This is a bit of a subtle technical detail, but suffice to say that the change simplifies some graphical things and makes some others more complex.

I had hoped to do the first full art pass on one of the game’s areas, but unfortunately I ran into a bug with Unity’s tile-mapping system. I upgraded to 2018.1 in an attempt to fix it, but I have since been told by Unity Support that the bug is not fixed until 2018.2b, so I will either have to upgrade to the latest beta version, or wait until it gets a full release to hopefully get started on that.

Colorblind Safety

In last week’s devlog post, I talked a bit about some of my thoughts relating to accessibility, particularly when it comes to deaf players. This week I’ve been thinking more about colorblindness.

Trying to come up with a set of color-blind friendly color options is quite difficult as there are several different forms of the condition. Some people have a hard time telling between red and green, and others between blue and green, and a rare few cannot distinguish colors at all.

I tried a few different variants, but many of them had problems:

The absolute best way to deal with colorblindness, of course, is to just use different symbols instead of different colors. This unfortunately is not a straightforward option for Taiji, as differently shaped symbols have different mechanical meanings. You can also use patterns instead of colors, but since the game uses pixel art, the detail possibilities are very limited.

Luckily, since most people can tell the difference between blue and yellow, those colors in combination with black and white provide a 4 color setup that will work for most people and most puzzles, at least where the only thing that matters is telling the colors apart.

However, this may still not be enough for some players, so I’ve decided to address this issue with a two pronged approach. For most puzzles in the game, I will just stick to the “safe” color palette, and the game should be accessible to many players by default. However I will have an additional assistance menu where the player can choose alternate colors if the defaults are not easily distinguished.

Additionally, there will be a set of completely color-free assistance symbols which can be enabled. These will be useful for puzzles where the player needs to know exactly which color they are looking at, or for when more than 4 colors are necessary.

Here’s my first pass at that:

Of course, the symbols themselves are subject to change, but the important thing is that the symbols combine and mix the same way that colored light does in the real world. In this case, the color model is subtractive.

For clarification on what I mean, here are the symbols again, now colored with their corresponding colors:

I’m not certain this will work for all the puzzles in the game, but it’s a start and it’s fun to think about.

So, I’ve finally finished up auditing all the puzzles in the game. Essentially, just solving them all and taking notes on what might need to be improved or removed. Overall, I think the game is in a pretty good place moving forward. There are some areas that I’m pretty happy with as is, but there is still a lot of work to be done to improve some other areas. Obviously this is just considering design work. Let’s not even get into how behind the curve I am from an aesthetic point of view.

Early Accessibility

This week, I chatted with a deaf accessibility advocate for games. This was an interesting and challenging conversation, and has left me thinking a little bit about what’s involved in making a game more accessible, and how that intersects with the design of Taiji. Obviously, I think that accessibility is an important and often ill-addressed concern, and my goal with the game is to never make a puzzle difficult for reasons that have nothing to do with its subject matter.

However, I think there is some tension between accessibility concerns and the pursuit of particular subject matter. As an example, if you want to do puzzles that are “about sound”, deaf people will unfortunately, but necessarily, be excluded.

It is easy to see why making a puzzle that relies on pure audio cues is a bad move from an accessibility standpoint. In many cases, it would be easy to make additional visual cues, and to not do so can simply be chalked up to laziness.

But my big question is, are there particular cases when not adding those cues can be justified? And if there are, what are they?

Some of my thoughts on this are a bit hard to clarify without specifically addressing and spoiling some of the puzzles planned for Taiji. Even still, after discussing the details of the puzzles with the aforementioned accessibility advocate, they did not seem particularly convinced that there was any tension other than my laziness and lack of care.

Similar concerns arose in the wake of the release of The Witness. There are some puzzles in that game which people who are color-blind or hard of hearing will have trouble with, or may simply find impossible without just looking up the solutions. Because of this, the designer—Jonathan Blow—has been called callous, “ableist”, or at best unconcerned about accessibility. The last one is particularly strange, considering the game received a PC patch to add a click-to-move mode, and nearly all of the puzzles in the game—including many that use color as a cue—are designed to be as accessible as possible; symmetry puzzles that care about colored hexagons using cyan and yellow, for example. In my last point of defense of Jon Blow before I move on, he has been quoted saying that he wanted to ship the game with a puzzle which only color-blind people would be able to solve, however in this case he was hamstrung by the the poor color consistency of most display technology.

So, what is the reason to make those kinds of decisions? To create puzzles which by their very nature exclude certain people from fully enjoying your game? Jon Blow says it is because the puzzles in The Witness are all “about things.” I agree with this sentiment, but it perhaps requires a bit more clarification to even make sense.

In many puzzle games, the “point” of the puzzles is essentially to be a challenge. The puzzles are meant to be hard for the player to solve, and probably fun as well. In games like The Witness (or Taiji, for that matter) the point of the puzzles is significantly subtler. The puzzles are intended to be interesting and, about something real. By “real” I mean that the subject matter is, at best, not confined simply to the game. The thinking that a player will do when solving the puzzles can be taken with them back into the real world.

It may seem a bit callous, but it should go without saying that both sound and color are phenomena that really exist, even if some people cannot experience them.

This can seem to lead down a path of reckless disregard for other people, so I think it is also very important to emphasize that what I’m talking about here—both in my own case and the case of The Witness—are puzzle games. These are games that, by design, will exclude people who are simply not intelligent enough to complete all of the puzzles in the game.

So What?

Perhaps all of this can just be seen as a long elaboration intended to serve as an excuse for my laziness, or “ableism”, or perhaps some other unidentified flaw of character. However, I still have not addressed the core issue:

What am I going to do about accessibility?

Currently the plan is to make the game as accessible as I can. When puzzles involve the use of color for separation, but are not explicitly about color, I will endeavor to choose colors that will work for as many people as possible for that purpose.

But what about when puzzles are explicitly about those things? What about puzzles about sound, for example?

In these cases, I will primarily design the puzzles with the intent of pursuing the subject matter that interests me. If I have to choose between a puzzle which can be made accessible or painting myself into an inaccessible but more interesting corner, I will most likely choose the corner.

However, I also intend to provide some level of assistance when possible. This, in itself is a tricky proposition, because I do not simply want to condescend to players who are using the assistance options. In essence, adding accessibility seems as though it will often amount to designing an entirely different set of puzzles. The puzzles therefore must be interesting in their own unique ways, and must endeavor to be analogous to, and at least as challenging as, the inaccessible puzzles.

Perhaps this will not be enough, or not even be possible. After all, I am mostly opining here without having fully designed any set of puzzles like this. But I think this is the best way for me to balance these two ideals: accessibility and truth.

Addendum

I want to clarify a couple things: What exactly is the difference between a puzzle which is about sound or color and one that simply uses it as a cue. And why do I think that the former cannot be made accessible without simply designing a different set of puzzles?

To do so will require spoiling a couple puzzles. The Witness is a hugely broad puzzle game, so I can actually find examples in both the positive and the negative without talking about any other game.

Spoiler Warning: If you have not completed the two areas shown below in The Witness, then avoid reading further.

The Keep

So, in the example of puzzles which simply use audio as a cue, but are not really about sound; we have the example from The Keep. The third hedge maze puzzle in the front courtyard must be entirely solved by listening to the loudness of your footsteps while walking on the gravel pavement inside it. The maze on the panel matches the shape of the hedge maze which contains it, and particularly crunchy spots found while walking through the physical maze denote an area to be avoided when drawing a corresponding path through the maze on the panel.

The reason that I say this is not a puzzle about sound, is that it would work just as well if you simply wrote out separate captions for the footstep sounds. The softer ones being written as “crunch“, and the louder ones being written as “CRUNCH“. The puzzle would essentially work the same.

It is important here to note the difference between subtitles and captions. Subtitles only show you spoken dialogue, whereas captions will also give you a textual indication of important audio cues.

The actual puzzle here is about noticing that the loudness of the footstep might be important, and then figuring out in what way. The argument against accessibility here is that hearing players are inundated with the sound of their footsteps throughout the whole game, and so this is a subtle thing to notice. Consequently, captions would be much less subtle.

I think this is actually not a very good argument: First, it isn’t really that subtle, as the important footstep sound is unusually loud here. And secondly, if the consistency is really that important, just put captions on all of the footstep sounds in the game. Make them small and unobtrusive if you have to.

Sadly, The Witness does not support captions at all, and therefore this puzzle is impossible for deaf players without simply looking it up.

The Jungle

So, in the positive example, we have the puzzles in the Jungle. These are puzzles that are actually about sound, or more specifically: about hearing. This will be harder to explain, because the puzzles themselves are much more subtle.

First, if you need a refresher on the content of these puzzles, I actually have an analysis video on the first half of this area, in which I discuss some of the subtle details involved:

 

Now, I want to bring the attention to my specific point earlier. Why do I think that these puzzles cannot be made accessible without simply making a different set of puzzles?

In this area, the essential task that the player is doing is listening to some bird songs, and transcribing the different pitches of the notes onto the panel. One could easily imagine some sort of analogous visual cue: a series of mechanical birds which all chirp in time with the notes, and are set on branches of varying height, with the height of the branch corresponding to the pitch of the note.

This type of cue would in fact work quite well, but only for the first three puzzles in the sequence. Past that point, the puzzles begin to play with both the particular difficulty of distinguishing different notes by ear, and the way in which we focus our attention on certain sounds by filtering out others. Both to our benefit and our detriment.

Perhaps again, there could be some analogous changes to our cues here. Perhaps the birds start out in linear order as they would be on the panel, but they begin to be shuffled up, and the player must watch the order in which they chirp. Perhaps the branches which the birds are situated on begin to blow in the breeze, and so it is more difficult to tell which bird is supposed to be higher. Perhaps there is a branch which is broken and the bird has fallen onto the ground. Perhaps there are birds which are not situated on branches at all, and they are irrelevant. These could be interesting ways to evolve the sequence, but what I am trying to argue is not that the puzzles cannot be made accessible, but that by doing so, they are now puzzles which are fundamentally about something different.

They are no longer puzzles about sound, and now are puzzles about spatial relationships between moving objects.

Does this make these accessible puzzles bad? No. But it does make them different puzzles.

This post has very minor mechanical spoilers for the game.

Earlier this week, I teased that I had found a solution to a lingering design issue:

 

The issue itself I’ve talked about in a previous blog post. You can read all about the problem there, but to briefly recap: I have a mechanic where depending on if a symbol is white or black, this indicates whether the tile containing it should be lit or unlit:

The correct combination is “black means lit” and “white means unlit”, but the issue is that some players find the opposite to be more intuitive, for perhaps obvious reasons. This means that those players will continually input solutions that are technically correct, but are logically reversed from one that the game will accept.

This is a particularly nasty issue, and solving it seems to require a compromise of aesthetics or intuitiveness. Again, I’d suggest you read the original post if you want to understand more, but in summary: none of the possible aesthetic solutions I could think of really worked well.

So why do I think I have a solution now?

Partly, I think I mistook the domain of the problem. I believed that what I had was an aesthetic issue, and so I was trying to solve it in the aesthetic domain. But in fact, I believe that the core of the problem is mechanical.

See, the dice face mechanic has two aspects. The first one is the one that we have already mentioned: a black symbol means that a tile should be lit and a white one means that it should be unlit. The second aspect, I don’t want to spoil here, so bear with me if I’m being vague (although I have talked about it previously on this blog).

The solution is that I need to decouple those two aspects. If I simply remove the lit/unlit requirement from the mechanic, it solves most of the problems. The only downside that I can see is that I will have to redesign the early puzzles in the area (about the first 10 panels or so), as those panels mostly focused on this aspect of the mechanic. For the later puzzles, I believe I can make most of them work by using the separate mechanic of locked tiles (tiles on the panel that the player cannot toggle from their starting state) in order to force a certain dice face to be on or off.

In some sense, this is a realization of my failure to enforce orthogonality (one of aesthetic virtues outlined in this talk, which I also share) between the dice face mechanic and the locked tiles. In fact, I mentioned this exact possibility in a previous post about orthogonality:

Second, I felt like the “is it lit up or not” aspect was an additional point of overlap with the dice faces, which already care about being lit up. It may come to a point where I want to separate out that aspect of the dice faces themselves, but at this point, I’m letting them care about what’s lit up or not, so it seemed like the new mechanic shouldn’t care.

So when I said “win-win-win”, what are the 3 wins here?

1. Removes confusion. By simply locking the tiles whichever way they need to be for any given puzzle, I remove the cognitive overhead of the player having to remember which is which, and put the focus on the actual content of those puzzles.
2. Removes busy work. At the moment, a skilled player starts one of these panels by immediately turning all the black marked tiles on and all the white marked tiles off, because no matter what, the solution will always require them to be that way.
3. Larger possibility space for solutions. The fact that, by default, the tiles no longer care about whether they are on or off, allows the player to have more flexibility in the way that they choose to solve a puzzle. This also gives me as a designer more room to play with the player’s expectations, and create puzzles where the solution may require some thinking about which colors to choose.

There’s also an additional and more subtle win across the rest of the game, in that as long as the dice face symbols were always suggesting that “white means black” and “black means white”, there would always be a bit of incoherence to other puzzles in the game that might simply require the player to match colors.

All the way back in the second devlog update, I mentioned that “the best ideas are the ones that solve like 3 problems at once and in hindsight just seem stupidly obvious.” Admittedly, I haven’t done a full pass on the entire area, so I may be putting the cart before the horse, but I feel pretty strongly that this is another example of that phenomenon.

I spent this week going through the puzzles that are currently in the game, and filling up a Google doc with notes and annotated screenshots about stuff that needs improvement.

This is a time-consuming process (actually not finished doing that as of this writing). It’s also a bit discouraging as it reminds me how much more work there is to do, even just from a design perspective. But it is necessary work for me to really triage what’s in the game and figure out what I should focus my efforts on first. It also helps me get back into the zone of thinking about the game after having taken so long away from it.

Sadly I don’t have much visually to show for it, because I don’t want to just post up a bunch of annotated screenshots of puzzle solutions, so instead what I will show you is…DOODLES!

I keep a notebook of graph paper that I use to try to find more ideas for puzzles when I’m away from the computer. A lot of times I’ll work on finding new ideas in the early morning or late at night. I pretty much just fill up pages and pages of tentative ideas. Most of them I throw out, but it’s worth doing because occasionally there’s a eureka moment and I find a mechanic or puzzle idea that’s worth taking the time to implement into the actual game. There perhaps is a better way to make this time more productive, but it’s what has worked for me thus far.

 

Alright, I’ll be back next weekend, hopefully with something more to show. Actually if I get fully done with the audit, I may be able to stream something. (Cause once again, I don’t really just want to stream myself going through and solving all the puzzles in the game.)

Whew, it’s been a while! It’s dusty up in here.

Have no fear, Taiji is not cancelled. I just took a few months off from working on it, and somehow that few months turned into a few more. But now I’m back and ready to start working on this beast again.

I actually forgot to post an update that I should have a while ago: I did some art tests and a complete re-design of the starting area puzzles. I may cover those new starting area puzzles in more detail later. But here’s one of those early art tests. (VERY WIP)

---

In the interim while I wasn’t working on Taiji, I was very active working on other things. So here are a few of those other things that you might want to check out:

Most recently, I released a short puzzle game called Polarization. If you like puzzle games (presumably you do), and sokobon-likes in particular, you should check it out!

I did a video essay about 2016’s DOOM and how it manages to feel fresh while recapturing the magic of the original.

And perhaps more appropriate for a puzzle-game interested audience, I did an analysis video of some of the early puzzles in the Jungle area in The Witness. This is a segment that I had to cut from the non-verbal communication essay that I keep threatening to release. I think it’s good, but the focus was too specific.

Hopefully you enjoy checking out some of these other things I’ve been doing lately. Keep your eyes peeled because I will be starting back on Taiji soon and will have some updates. I will probably stream some work on twitch as well, so follow me there if you aren’t already.

A few weeks ago I read this tweet:

In summary:

design your game’s level pacing the way this image designs its sentences pic.twitter.com/3Ws3XysyIa

— MOOMANiBE (@MOOMANiBE) June 22, 2017

The linked image is reproduced below, in case the twitter embed breaks at some point:Obviously, pacing in games is very important, but this comparison got me wondering about how exactly you pace games which focus on puzzle-solving. It’s not that I haven’t thought about this at a subconscious and abstract level. In designing Taiji, I care very deeply about making sure that the game is as interesting as possible, and this often means addressing pacing, at least in some hand-wavy way. But, I’ve mostly been playing by ear, and I haven’t put forth my approach as a formal set of design guidelines.

I did give a semi-formal lecture on puzzle game design a couple of years back, intending it to be a bit of an elaboration on a lecture given by Marc Ten Bosch and Jonathan Blow in 2011, taking those ideas and expressing them as a practical set of rules. I thought it might become a useful resource for beginning puzzle game designers, which seems to have been validated by some of the responses I’ve received. Watching it is useful in understanding the design approach that I use, but because it is so high level, there is still a large amount of intuition required when the proverbial puzzle design rubber meets the road. And furthermore, it doesn’t really say what pacing in a puzzle game is, much less how you should go about improving it.

So, where do I go from there?

I actually spent around six months working on a video essay about The Witness, wherein the explicit goal was to use that game as a case study for exploring the details of good puzzle game design. In particular, I find The Witness to be a standout example of non-verbal communication of ideas through gameplay (Conveyance), both when it comes to teaching the player new mechanics through play, and more remarkably, the way in which the mechanics combine to express something fundamental about humanity’s search for Truth. However, in my writing and editing process, I got lost in the details of individual puzzles and didn’t manage to connect them to the larger picture of the game.

Although I don’t consider that effort completely abandoned, I still feel I lack the proper words to really express my thoughts about the subtle things happening in that game’s design.

I sometimes get questions or suggestions from viewers on my twitch streams. Sometimes these are good ideas, but when they are bad ones, I tend to take an inordinately large amount of time attempting to explain why I think the idea is bad. I mostly do this because I do not wish to appear as though I am simply a diva who is following his own whims, and is insulted by anyone’s criticism of his creative vision. Rather, I want people to understand that I am working within a design framework, and there are certain decisions which very clearly step outside the framework.

The issue is that it’s only very clear when viewed from inside my own mind, but outside of my mind, the framework is ill-defined because I oftentimes lack the words to really express what I am even talking about fully.

I tend to detest jargon, but sometimes creating new terminology is useful, or even necessary to logically explain the choices that one is making, or to make those choices more effectively.

A good example of useful jargon is the entire field of music theory. Without the abstract concept of playing “in the key of A minor”, we would instead have to rely on everyone’s instruments being tuned into the same key by one person who understands the harmony on an intuitive level, or we would require an inordinate amount of communication and correction among the musicians who wish to play together as a group.

So, the main question that I have been turning over in my mind, is how exactly do I define what I think of as the “ideal” pacing or flow for a sequence. What follows is a first attempt to address that question.

•   •   •

One of the great things about the structure of Taiji is that the entire game is open from the beginning. The player can choose from several major areas and tackle them in any order that they wish. Sometimes progress in an optional area will be halted because of lack of knowledge of a puzzle mechanic from another area, but there are no artificial barriers to progress. This allows the player to set their own pace, to a certain extent. If they get bored with the nature of a puzzle that they are stuck on, they are free to travel to one of the other areas and think about a different type of problem.

This design could easily be used as an excuse to not care about the internal structure of each area, but I still try to do my best to pace and structure the areas properly from within.

Still, until I read that tweet, I didn’t even think to use the word “pacing” to describe the concern. Other genres have been thinking about pacing for decades, but the primary historical difference between puzzle-solving games and those other genres, is that other genres have core gameplay, and puzzle games do not.

In a shooter, for example, the core gameplay is running around, jumping, and shooting enemies make progress. As the game goes on, you might get new and more powerful guns, the enemies might become more varied or have different movement patterns, but the core of the game is always that same core gameplay. In fact, the core gameplay is why we even call these games “shooters”.

So, one might ask, why would puzzle games not have core gameplay?

The answer, is that some do and some do not.

Disregarding the variety of action puzzle games (such as Tetris) which clearly do have core gameplay, and focusing on the category of puzzle-solving games, there are a two main categories: games with systemic puzzles, and those which feature one-off, ad-hoc puzzles. The main difference being that the systemic ones have core gameplay, and the non-systemic ones do not.

Without core gameplay, it is next to impossible to pace a game. This is why adventure games have such a reputation for ridiculous difficulty spikes and poor pacing. Some puzzles can be solved in a few minutes, whereas others will hold up players for hours or even days. Although the primary gameplay in an adventure game is “solving puzzles”, because each puzzle is entirely different, nothing the player learns in one puzzle can be carried forward to help them solve the next. (There are some exceptions, but this is more due to rigor on the part of the designer than any true systemic underpinnings.)

The great thing about systemic puzzle games (games like Taiji, or The Witness, or Portal) is because all of the puzzles are built atop an underlying system, every puzzle has the potential to teach the player something about how that system behaves, and the player can use this information to better solve new puzzles.

When there is a sequence of puzzles which are specifically designed to build up an understanding of a systemic idea in the player’s mind, this functions very similarly to a paragraph of text. (In the lecture I gave a couple years back, I referred to this concept formally as a capital-S Sequence, but whatever you call it, it’s just a smart way of structuring of a series of puzzles.) In the same way that a paragraph is a series of sentences elaborating on one shared idea, a sequence is a series of puzzles with a shared idea at their core.

So, back to pacing for systemic puzzle games. How exactly do we go about it, and can we at least draw a broad outline of what constitutes good pacing?

I would say that the ideal structure for puzzle sequences follows a dramatic arc. The beginning is marked by a slow and logical build-up, the player works through puzzles step by step, and then there is a climactic moment to cap off the sequence. This climax to the sequence can take on a lot of forms, but the first two parts are usually very similar across all sequences.

This structure shares an obvious similarity to the Three Act structure for storytelling. So, let’s just borrow that terminology in order to define it formally:

The 3-Act Structure of Puzzle Sequences

INTRO    >    BUILD-UP  >   CLIMAX

Every puzzle sequence has an main idea at its core, this is either a system or something that all of the puzzles in the sequence are “about”. For purposes of discussion, we’ll just call this The Main Idea. 

INTRO: In this act, The Main Idea is introduced in a relatively opaque, but simple way. The player solves a puzzle, or a short series of puzzles, and then they understand (or believe they understand) The Main Idea well enough to begin deductive reasoning about puzzles in the next act.

Because the player may not fully understand The Main Idea even by the end of this act, the puzzles here should be very simple and able to be solved quickly in order to not lose momentum early.

The player will be solving most of the puzzles in this act using intuition, so it is important to keep their assumptions in check and make sure they don’t get lost in the weeds. This is a particularly good time to use Reprises (when the structures of two puzzles are very nearly identical, in order to emphasize the differences) to create counterpoints to certain wrongheaded assumptions and build understanding.

BUILD-UP: In the second act of the sequence, The Main Idea is explored more deeply, with various puzzles gently increasing the challenge or layering on complexity.

Puzzles in this section are less intuitive, and require the player to use a more top-down approach, deducing the solutions based on what they have learned in the first act. Momentum is ideally constant or very gradually decreased during this part, with each puzzle taking about the same amount of time as the one before it.

CLIMAX: In the final act, we finish exploring The Main Idea, and the puzzles reach their highest point of challenge as the sequence ends.

Sometimes the most satisfying way to conclude the sequence is by introducing a twist. This is a puzzle which must be solved through lateral thinking rather than deduction. There is something that the player does not know which is required to understand and solve the puzzle. Optionally, this knowledge can redefine or re-contextualize The Main Idea. If this happens, when we proceed to the next sequence, it will be with the same Main Idea, but with the new context.

Pacing in this final act is less important, and the puzzles can be very difficult and time-consuming here. As a rule though, the final puzzle in the sequence should take longer than the ones that came before it.

(Additionally, it is useful to remember that a larger area which explores one Main Idea can be built up out of multiple sequences. To reprise the literature metaphor, the larger area would be similar to a chapter in a book, where the sequences would be paragraphs, and the individual puzzles, the sentences. In this case, each sequence will usually explore a small aspect of the overall Main Idea, and the structure of the full area will have an arc of increasing difficulty that is somewhat similar to the individual sequence, although not as rigid.)

The best sequences are generally the ones which hit the main points of each of the acts very clearly and without losing player momentum at the wrong times. Ideally the overall pace should start quickly and slow as the sequence progresses, with the easiest puzzles being in the Intro stage, and the hardest and most time-consuming puzzles being the Climax to the sequence.

Ideally we want to think about pacing as controlling the difficulty of the puzzles over time, but evaluating the difficulty of any given puzzle is not straightforward. In fact, it is one of the more subjective things in the entire field of game design. Although the skills developed by playing one action game oftentimes carry over to the next, this is rarely the case with puzzle games, and the perceived challenge of any given puzzle can vary quite dramatically between individual players. There is some correlation between higher IQ and lower perceived difficulty of puzzles, but there is still enough variation in the ways in which people think that some difficulty spikes are probably unavoidable.

I think this is a big reason why, perhaps more so than for other genres, it is important to have a large number of testers on the game, and to take each individual test with a grain of salt. One has to have a strong vision for what the player’s experience should be like, and also have a developed sense for when the deviations in a particular player’s experience are acceptable and when they are not.

This is more or less where my theory starts to unravel a bit. There may be a way to develop a good method for objectively evaluating puzzle sequences, but I see this as one of the areas where it is still more art than science. Even with infinite time and good luck, when making puzzle games, one must always accept that a certain number of players will have a bad experience. Really the best you can hope for is that a greater number of players will have an experience that is closer to the ideal than those that do not.

•   •   •

I’d like to close with a quote from Italo Calvino’s Invisible Cities. I didn’t really find a way to work it into the essay naturally, but it resonates with me in relation to the type of puzzle game design that I do. It comes from a chapter in the book which is sort of acting as a meta-commentary for the whole book. For context: the structure of Invisible Cities is a series of descriptions of the ways in which a city might be constructed. However, there are some descriptions which are more valid than others:

“…from the number of imaginable cities we must exclude those whose elements are assembled without a connecting thread, an inner rule, a perspective, a discourse. With cities, it is as with dreams: everything imaginable can be dreamed, but even the most unexpected dream is a rebus that conceals a desire or, its reverse, a fear. Cities, like dreams, are made of desires and fears, even if the thread of their discourse is secret, their rules are absurd, their perspectives deceitful, and everything conceals something else.”

“Invisible Cities” – Italo Calvino

Since I’ve been working a lot at my day job, I haven’t had the energy to work on the game outside of the Sunday streams. Unfortunately, I also had to cancel a couple streams, so progress lately has been pretty slow. I also forgot to post a devlog update after this past stream. Oops!

This past weekend, I built out a full rough draft quality version of the “dots” puzzle area. Here’s a screenshot from the editor of the entire area as it currently exists.

The player enters from the top left, learns the basic mechanics and then the area branches off into some variant types of puzzles which layer on some additional mechanics. This is good because it maintains interest and gives the player options, although the exact puzzles will need to be iterated on until they have a good sequence flow.

But even accounting for that future improvement, I still feel like the area is a bit too flat overall. It’s just kind of a bag of panel puzzles, without a lot of interaction with the environment. I don’t yet have clear idea on how to fix that, but I will hopefully come up with something.

Mostly this critique comes from comparing the area to the dice face area, which is perhaps the most developed area currently in the game. That area has a few problems of its own at the end, in that I don’t feel like I quite switch it up enough right at the end, but there’s definitely a good interplay between the core mechanic of the area interaction with the environment.

Next up, I’d really like to improve the walking animation for the player, and do some more concept art. Then I have some ideas that I want to try out as an alternative implementation of one of the other areas in the game.