21. Dots, Recursion, Optimization, and More?

This week, I spent some more time designing puzzles for the “dot” mechanic that I mentioned in the previous blog post. I currently have about 60 puzzles sitting around in the world using this mechanic. Definitely take that number with a grain of salt as these are rough draft quality puzzles, and I will probably cut a bunch of them.

“The dot mechanic”: these are some intermediate puzzles.

Still, it’s been fun designing these puzzles and seeing how much I can wring out of just the baseline, without even including the other mechanics of the game. There is a lot of depth and subtlety, and I really think I probably have just scratched the surface what’s there.

In addition to building out this area, I created a functional prototype of an area that I’d been thinking about before I even started building the game (at least as far back as June 23, 2015, which is the modified date on an old Google Doc where I wrote the idea down). I wasn’t really sure how this area would work at all because the concept was a bit strange, but it actually seems to work well and I am happy with how that is going. Unfortunately, to tell you what the concept behind the area is would be spoilers, so I will just leave you with a mysterious screenshot.

What could it mean?

Brute Force Puzzle-Solving, Optimization

So, another thing that I was thinking about for a while, and in particular with regards to designing the dot puzzles, is that it is sometimes difficult for me when designing puzzles to figure out if they have degenerate solutions. By which I mean, I usually am putting a puzzle in the game because I found that it has an interesting and unique solution, but many times I am unaware that there are alternative solutions which may not be nearly as interesting or require as clever thinking on the part of the player.

To that end, I felt that it would be useful to be able to see all the possible solutions for any given panel. This seemed like it would be fairly easy to implement, as it just means using the computer to go through all the possible states that a given panel could be in and checking to see if the panel is solved in each state and keeping a list of all the solved states. Sadly, it was not as simple as I dreamed.

First, even just the basic task of iterating through all possible states for a panel was difficult to figure out how to accomplish. Ultimately, the solution came via mokesmoe, one of the viewers in my twitch chat. It’s a fairly simple algorithm to implement, but it uses recursion and so is a bit hard to wrap ones brain around. But it works and it covers teh whole possibility space once, and only once.

Still, when it came time to test it out, it very quickly became apparent that it was not going to be practical past a very small panel size. Mathematically, this is pretty easy to figure out, as the number of possible states grows exponentially with the increase in panel size, doubling for each new tile that is added. Even a 5×5 panel was enough to lock up Unity completely to the point that after a few minutes, Unity’s built-in crash reporter killed the process and offered for me to report a bug to their developers.

I shouldn’t have been too surprised though. Even though a 5×5 panel seems small, there are 33,554,432 (2^(5*5)) possible configurations that it can be in. If you do anything 33.5 million times then it’s gonna take some time. For example, if each solution validation only took half a millisecond, covering everything would take 4 and a half hours of processing time. (Someone else can double-check my math on that)

So, I set out about trying to optimize the code, both in the coverage code, and in the solution validation code. Sadly, it was a bit difficult to profile what was happening because the Unity profiler and recursion don’t seem to mix very well. Lots of killing Unity.exe from task manager ensued.

Eventually, by pulling some variables out of inner loops and reducing the amount of dynamic memory allocations, I was able to get solution validation down to where it takes less than .05 milliseconds.

Still, although this makes the brute-force solver much more practical, this doesn’t prevent the possibility that some panels will just go into what is basically an infinite loop. So, as an additional precaution, I just added a timeout which will kill the solution search after a certain number of cycles and just consider it “un-brute-forceable.” This basically is just a cheat so that I don’t have to worry about Unity hanging. (Although I still seem to have a problem with some puzzles hanging anyway, so it’s perhaps possible that I’m not doing a thorough enough check (maybe I should just check recursion depth too?)).

Anyway, it was fun to do some optimization work there, but I think mostly I’m still being bitten by both the limits of current technology (we don’t have quantum desktop computers yet), and the limits of high level languages (I don’t really think it should be as slow as 0.05 ms per solution validation on a 5×5 grid, even with the fancy recursive solution validator I have for some of the mechanics)



20. New Mechanics Ahoy!

This week, I’ve finally finished up the replacement interface enough to get back into designing puzzles. At first, I returned to a mechanic that I was in the middle of prototyping when I took a break from working on the game, but after some thinking, I realized there are some issues with it that I don’t know how to resolve yet.

As I mentioned in an earlier blog post about the mechanic, it’s a good mechanic as far as orthogonality goes, but the issue is that it just doesn’t stand on its own very well. It only really gets interesting when it’s combined with the other mechanics. This might be fine if it was a purely augmentative mechanic, but it isn’t.

Additionally, it’s a big goal for the design of this game to have the player solve puzzles without requiring verbal hints, and unfortunately this mechanic is non-trivial to teach the player this way. Essentially, it’s a difficult concept to grasp that doesn’t actually go very deep once you do grasp it. So, it doesn’t feel very rewarding. Until I come up with some changes to the way it works that make it deeper, or at least much easier to teach, I have decided to shelve it in favor of trying something else.

(By the way, As I mentioned in the previous post, I’ve been live-streaming some design/programming work on the game on twitch, so you can see some of this new mechanic being prototyped in the archives here.)

That New Mechanic

So as for the new mechanic, I’m not going to go in-depth about how it works, as I want to maintain a bit of mystery about the game. A big part of the game is the sense of discovery, coming upon some inscrutable thing and poking and prodding at it in order to figure out what’s going on.

But, the important thing to note is that so far this mechanic is working out much better than the last one. It creates interesting and subtle puzzles which are just as good as the others in the game. I am still in the process of seeing how deep it goes and how well it interacts with the other mechanics in the game, but in the meantime I will let you look at some of these new puzzles in an unsolved form and speculate on their meaning.

Let’s just call it “the dot mechanic”

The only thing that I will say about the mechanic is that it primarily came to mind when I stopped being so worried about whether or not I was cribbing ideas from The Witness. In my mind, it’s pretty similar to one of the mechanics in that game, but due to the fact that the interaction method of the puzzles in my game is quite different, the way in which it manifests is actually pretty unique.

Day Job and Productivity

So, the other big thing that’s happened this week is that I’ve gone back to my day job. This poses a bit of a problem as it’s usually quite difficult for me to maintain a good work momentum when I’m also working 8 hours a day. Thankfully (or perhaps not, if you ask my wallet), I haven’t been working a lot of hours this week, so I’ve still been pretty productive.

I just hope that I can keep up some level of momentum on the game as my hours pick up at the job. Part of my issue is that when I put the game down for a day or two, I start to over-analyze everything and worry too much about whether or not I’m taking the right steps.

By now I should have realized that it’s more important to just keep moving than it is to be certain that I’m not making a mistake. I can always course-correct later, and I even if I think about it all day before making a decision, I only have so much information. Scrapping and redoing thing is just part of the process, even if it is still pretty uncomfortable for me.

19. Finalizing Up the New Interface

First, I’d like to notify anyone who is following the blog that I have recently been streaming development of the game over on twitch, so follow the channel there and ask to be notified when it goes live. If you missed the stream, you can find a complete archive of all the development streams on my YouTube channel.

So, at the time of the last entry, I was struck with the problem of resolving the ambiguity between the point-and-click type panels and the walk-around type panels, in that they looked pretty much the same. I was also considering abandoning the point-and-click interface as a solution.

This week, I did some more iteration on the artwork for the snake panels, and I’ve reached something that I’m pretty happy with, overall.

Primarily, It is clearly distinguishable from the point-and-click panels. But it also solves a lot of the other small issues that the panels had: The start tiles are clearly elevated compared to the other tiles, and for panels where the player can start on any tile, the startable tiles subtly depress and show a small highlight, encouraging the player to press a button to activate the panel.


I did some other cool interface readability work, but I won’t post it here because spoilers!

The Nitty Gritty Stuff

Mostly though, this week has been technical work.

I did some general performance optimizations when it comes to the panels. They weren’t running terribly, but it seemed like a good time to clean up a lot of the code because I am close to finished with the new interface and know what I need to keep around. Also, there were just some dead wrong things I was doing with regards to solution validation on panels that were eating up CPU cycles. One of them was a bit of a “how did this ever work?” type issue.

Another nice to have feature, which really doesn’t impact the player’s experience much, is Unity’ live script reloading feature. I had broken it at some point for the puzzle panels, and I took the time to investigate why and fix the problem. It was relatively simple, with the only real issue being that I was storing some gameObject references using multi-dimensional arrays, and (amazingly) Unity does not serialize multi-dim arrays.. In order to fix that, I just replaced the multi-dimensional arrays with single dimensional ones and just use [x+width*y] every time I want to access them. I’m still not super happy with this solution, but it at least got the script reloading working.

There was a minor additional snag when trying to get the script reloading working. Which is that even though it was actually working, I couldn’t tell because part of my code didn’t think the panels were visible on-screen and was disabling them (premature optimization bites me again!) The issue here was again just serialization, although most of the panel was getting serialized properly, the bounding box structures that I use to determine visibility were still getting destroyed on script reloads, so all the panels would fail the visiblity check on script reload. Oops!

The rest of the work that I did this week was just about ensuring that all of the existing puzzles are still solvable using the new interface paradigm. There are currently 138 puzzles in the game, which may not seem like a lot, but it’s enough that it can be a bit hard to remember what features all of them do or didn’t use.

As of now, there are only two more small things on the list to implement and the game will be fully playable again, which is great.

Only major bummer is that I have a cold, and I have to go back to my day job in three days.

18. Interface Work and Concept Art

This week, I have been pretty happy with my productivity on the game. I actually did a couple of development streams for the first time in like 6 months at least.

So, what exactly have I been up to this week?

Concept Art

One of the items on the tasklist for the game ever since I started thinking about doing the art myself was to try to do a full concept piece, in order to get some kind of idea of what an area in the game might look like in the style I’ve been working in. After all, doodles are nice but they don’t really look like a game.

So, the piece that I decided to do is intended to be a take on the starting are of the game, which is a floating island.


Obviously this is super WIP, and I wouldn’t necessarily expect the final version of this area to look anything like this, or the final art to resemble this beyond the broad strokes. But overall, I’m pretty happy with the way it came out.

Interface Redesigning

The main subject of my streams where I was working on the game was the issue that stymied me so badly for the past six months, which is the issue of how the player is going to interact with the panels in the game.

Since I didn’t have a particularly great idea of how to proceed, I just went ahead with what seemed like a good idea and implemented a point-and-click interface. This means that the player can walk around, but also use the mouse to click panels and toggle them off and on.


The interaction of just clicking and toggling the tiles feels pretty good, but it unfortunately ends up creating a bit of a separate issue. Explaining exactly what the issue is will take a bit of doing, but I’ll try.

As I explained in one of the early posts on this blog, the toggling type panels are not the only type of puzzle in the game. There are also another kind of puzzle in which the player is constrained to draw a line by illuminating tiles one at a time next to each other. In the game, this manifests as the player walking across the panel.


The issue comes that I’m not sure what sort of symbology to use with these “snake” puzzles, because when the player is clicking on these squares with the mouse in order to toggle some panels, when they see another identical square, they want to click it. I could perhaps solve this issue by having all the tiles on the snake panels be the “broken square” type that you see pictured here. This is nice because they appear to still be tiles, but they don’t feed into the square symbology so much that the player will assume they can click them.

However, this is still not a full solution to the problem, because I am already using that symbol to represent tiles that the player cannot start from when they are walking around on the panel. In fact, I came up with this idea in the first post on this devlog.

So, I’m not really sure what I can do for these panels that won’t really conflict and will not really seem ugly or in-obvious. I did some tests on the stream of a few possibilities, but none of them really made me happy. I have even considered simply raising the starting tile, but that runs into other issues, in that I then have to ask the player to press a button when they step on each raised tile, or else they cannot start at a tile in the middle of a panel if all of the tiles on the panel are startable.

A Solution?

So, the solution that I’m currently entertaining as of the time of writing this post, is to simply abandon the point-and-click interface, and have the player always walking on all of the panels in the game. This is naturally a consistent interface, but is a choice that I had been avoiding, primarily for aesthetic reasons, because it implies the constraint of always having the panels in the game be on the floor.

However, I may be able to accept that constraint. Either way, I’m not sure what the “right” answer is, I am just trying to do something that has the lightest contrivance.

(There is still another issue with this particular approach that has to do with some of the types of puzzles in the game, but I believe that I have a tenable solution for those as well. I can’t really go into the nature of those puzzles though because it would be spoilers. Perhaps you will be able to catch it on one of my streams, though.)


17. Woah, Dave, working on Sounds

I actually cracked open Unity and worked on the game project yesterday. My thinking was that I had some people who were interested in the game remark about wanting to test it, and I don’t really have a properly playable build of the game at the moment.

So, I opened it up and proceeded to work a bit more on the interface transition, although I am still not entirely sure what the final approach should be. I also found a few bugs and quirks along the way.

One bug was due to the way in which I was determining what tile the player was standing on. This was due to a decision, which seemed innocuous at the time, to test a rectangle instead of a single point. This normally causes no problems, but there are certain degenerate cases when the player walks across a field of tiles that the tile which is currently highlighted will sort of ping-pong back and forth between the tile below and also above the player. I am again, not entirely sure why this is the case, but switching the test to a point test seems to have resolved the issue, and feels much better from an interaction standpoint.

The other thing that I tried out, was adding some more feedback to the puzzles in the game in the form of audio. Thus far, playing the game has been entirely silent, and I started to wonder if some of the complaints about the feel of interacting with the panels in the game had to do with the fact that there was no audio feedback to what the player was doing. I unfortunately do not have a properly functioning version of the cursor interface to see if the audio feedback would be sufficient there. I sort of broke it when  I implemented the direct interface. I was hoping to keep them side-by-side, but that was somewhat more challenging than it initially appeared it was going to be. I may still decide to re-implement a cursor just to see if it is better, but I’m not sure. Main priority is just to get the gameplay up and running again.

16. More Art Style Testing (COLORS!)

In the last post, I mentioned a bit about getting back to looking at doing color in the game, because believe it or not, I’m not making an entirely black and white game. I very much want to do an art style which is mostly monochrome but has splashes of bright colors that pop against the rest of the image.

Here’s my first test of that:


It’s again not a proper mock-up, but is more of a doodle, but I am very happy with where things are going and will try to perhaps do a proper mock-up/concept in the next week.

I’ve gone back and forth about whether I should talk about spoilery things on this blog or not. In general I feel like it’s okay because I haven’t really planned on making the blog public, but as time goes on, I keep thinking maybe I should make this public anyway. I just worry about talking so openly about big reveals in the game that I would like to keep under wraps. Or especially as may be the case here, big reveals that haven’t fully formed yet and so talking about the “ideas” is somewhat irrelevant.

I think for now I’ll just talk about what I’m thinking anyway and worry about it down the road, and perhaps it will make this blog stay more of a pure thing anyway by doing that, because I’ll have reason to not publish anything for spoilers.

(SO, SPOILERS, also some spoilers for The Witness here)

So, what I keep thinking about and what’s stumped me for like 6 months is the interface issue, as well as my desire to have some sort of equivalent of The Witness’s layer 2. This is mainly because I feel like my game takes obvious inspiration in terms of the panel puzzles from that game, but I don’t have any equivalent of the environmental puzzles, nor did I ever even really conceive of a thing. Since, in the case of The Witness’s design, the environmental type hidden object thing came before the rest of the idea, I am kinda at a disadvantage and maybe working backwards.

It’s certainly possible that I should throw in the towel here and just not have any thing of the sort in my own game, but I feel like that would probably be a disappointment to anyone who came to my game based on its similarity to the Witness and were hoping for a similar type of experience.

However, this is a real tall order, because I can’t simply do the same thing that The Witness did. For example, one could imagine a first-person version of Taiji where nothing in the world is square, with organic architecture with lots of flowing curves, and hidden squares in the environment which the player needs to line up their perspective to see. It would perhaps be a cool thing in a way, but it would nonetheless be entirely derivative, and for me, not that satisfying to design.

Essentially it would be the same game, only with a different symbology. The circle would be traded out for the square:

The circle is the one on the right.

So, I would rather take a cue from The Witness on a higher level than that, and instead think about how I can have a similar level of secret. How I can have a game that builds towards a startling revelation but does not have the same revelation, so that it would be just as satisfying to a player who had already played The Witness and might go in with a certain mindset and expecting a certain thing.

This more or less means that I have to work backwards, but I am hopeful that I will come up with something that is at least interesting and different, even if it doesn’t end up being profound.

So, the real spoilery thing, if I actually succeed is what exactly my thinking is on that secret.

I’ve thought a lot about what it should be, and my current best guess, as well as the only idea that I’ve taken far enough to visually prototype is this idea of selective color.

Over a year ago, when I first started the project in its conceptual phase with Martin Cohen, I was thinking about a Zelda-type game with a color theme, but I was not exactly sure how that would manifest. I kind of had an idea that you might be able to add or remove objects which were a certain color. Now, I am coming back to that idea, but I am planning on taking a somewhat different approach to executing on it, which is mostly in having the primarily black and white world, so that color objects will stand out.

My hope is that if I give the player explicit ability to interact with colored puzzle panels, they will perhaps not put together the link that they can also interact with objects of the same color in order to solve puzzles. We will have to see how that turns out in practice, but essentially the idea is just that color will be used as a marker for something in the environment that can be interacted with and perhaps this can be done in a subtle and revelatory way.

The other thing is thinking about generosity in terms of game design, because I have a primary worry about this “layer 2” nonsense since forever ago. Namely that it will feel too restrictive and therefore won’t be very satisfying. It will feel more like, oh I just need to find the red things and then click on them. So, that’s the main thing that I haven’t really figured out yet, but part of me has wondered if I shouldn’t just opt for a game design where the entire world is toggle-able on and off. I’m just not even sure how a game holds up when you can do that type of thing. I certainly don’t want to go halfway and then put limits on what you can and can’t toggle in a way that feels arbitrary. So instead, I must simply come up with rules about what is interactable that feels good but also feels surprising.

An example of an explicitly tile-based game, perhaps you could toggle tiles on and off?

I suppose that’s all a bit rambly, but my main thinking is that the color limitation will make it not feel arbitrary what is interact-able or not. The only concern then becomes whether or not it makes it feel too restrictive or unsurprising. I may need to think about it for a while longer before coming to the proper conclusions about how exactly to implement the idea.

15. Art Style Tests and Layer 2

Over the past week or so, I have been thinking more about how to do a big secret in the game, and I think that I may have come up with something that will work reasonably well without being too obvious.

I’ve also been doing some artwork testing, thinking about what types of styles I’ll be able to achieve on my own, and focusing primarily on values. I am also doing low-color pixel art aesthetic. I don’t love love the results yet, but they aren’t too terrible and perhaps indicate that I can do the art myself:

It’s not exactly a proper mock-up or even a piece of concept art, but more just a collection of doodles using the limitations I’m looking at. I do want to add some color in, but I’ll get back to that later. 🙂

There are really 4 major limitations to the art style:

  1. I have to be able to do it.
  2. It needs to be relatively flat, while still looking good.
  3. The panels need to be clearly readable.
  4. (Sorry, this one’s a secret)

14. Kept You Waiting, Huh?

So, it’s been a good darn while since I posted on the devlog, but it’s also been a good darn while since I did any actual work on the game. Today I decided to sit down and start doodling some pixel art, considering the very real possibility that I will need to scope the game at a level where I can do everything myself. I started the project with Martin Cohen, who is an excellent pixel artist and musician, but realistically speaking I cannot afford to pay anyone to do art or music for the game. It’s just not a feasible proposition, and the game is roughly 50% cheaper to make if I just do everything myself (not entirely, as I am much less productive than Martin…hmm…maybe Martin pays for himself after all, hahaha!)

Anyway, so I’ve been thinking about what types of art that I can actually do, and since I suck so much at color, I figured I’d at least start with some black and white mock-ups:


I may actually stick with black and white and low color counts for the full game, because it’s an interesting limitation, and I think you can still do some good things with it. But, perhaps if I keep at this type of thing, I might be not terrible enough to actually do color stuff too. The bottom right mock-up is a bit more of a game boy palette, but is just what aseprite automatically chose from its default palette.


I kinda want to talk about scope a bit more though, as I find that it is perhaps the biggest determining issue for me as to whether or not I can complete a given project. On my last game, I think the major reason that I was unable to ship the game was because I had set the bar for completion too high. I had brought on a very talented artist to do hand-painted art for the game, but looking back on it, I really should have just done pixel art and done it myself.

The fact is that I can do music and art, I am just not as talented as other people. But the fact also is that other people cost money, and although I can and have pursued profit-sharing in the past, the truth is that if the people you are working with are worth their salt (which they should be if you want the game to be successful), then they will find that salt elsewhere.

The problem with downscoping for me has always been that it’s just extremely hard for me to do it. It always feels like I’m compromising on “the vision” for the game. I understand that it really doesn’t matter what I dream for the game if it’s not possible for me to actually achieve that, but I always seem to have a hard time lowering my expectations for the project and just shipping something.

Suffice to say, it’s a concern that I really go back and forth on and I don’t have a strong opinion about, but if I’m accepting of my own limitations, it makes sense to try to lower the bar for completion a bit on these longer term projects and accept that I’m not going to ship the best looking and biggest game ever as my first project.

At least as long as I have like no money in the bank.



13. Forgetting Something?

The goal was to keep a weekly development log, but it’s been over two months since my last entry. A lot of things came up, but I haven’t really touched Taiji much. Been working on other projects and personal things, so not completely unproductive, but my whims have not pushed me back into game development yet.

Always a strange thing, I let my mood dictate to a certain extent what I work on, but I also try to push myself to complete longer term projects.

I suppose I’m lucky that I still don’t have any better ideas than Taiji, but this interface rethink problem has really bogged me down. I don’t like the old interface and I have doubts about my current idea for the new one. Still, I have no better plan for replacing the interface than what I was already proceeding with.

12. Slacker

I believe I even skipped a week or two of updates on the blog here. Still not worked on the game. Kind of amazing how I let procrastination snowball. I try not to beat myself up too much when I don’t feel like working on it and don’t get anything done, as the negative energy really is not very constructive. But I’m starting to feel pretty useless.

On the plus side, things in my personal life have been improving dramatically, and I have been having a good time lately. I suppose it lends itself to asking a question of what is really most important in life to me. I feel like my primary motivator is love, and all other motivations are secondary to that. If I don’t get the love then it’s more important for me to be creatively productive, for example.

I’m not sure, though. It’s just a theory. Either way, things are good for me but not so good for the game, until I sit my butt down in that chair and finish this interface overhaul and get on to designing some more puzzles and such.