29. Animation Nation

The past two weekends, I have been working on revising the design and animations of the main character. The old sprite has served prototyping fine, but it’s time to start working on actual art for some parts of the game, both so that I can start designing puzzles that use more subtle visual cues, as well as for the purposes of being able to promote the game at all. (Prototype grey-box environments can be fun to play around in, but don’t show very well)

Part of this process involved deciding on an approach for implementing the animations into the game. Unity already has a very robust and complex animation system built in to it, but it is much too complex for what I need for a simple 2D pixel art game. Unity’s animation system is built for handling complex motion blending and IK with 3D models. Also, it doesn’t really allow for easy control of animation switching from code. You have to establish all your animation parameters and transitions in the Animation FSM through the Animator panel.

So, I set about coming up with a quick and dirty replacement which would basically allow me to, in code, just say “play this animation now”. This took way longer than it should have, primarily because I couldn’t get a custom inspector for my new “Sprite Animation” component to display the information that I wanted correctly. Eventually I threw in the towel and just divided the system into two component types. One “Sprite Animation Strip” component is added for each individual animation, and there is a master “Sprite Animation” component which handles playing the animations and switching between strips.


It’s pretty messy, primarily because there’s no clear indication of which animation strip is which when you’re looking at the array under the Sprite Animation component. Because of this confusion, it’s not a particularly tenable system if you have dozens of animations, but for the time being it has served my purposes fine.

Here’s a gif of the current work-in-progress walking animation in action (the environment is still just grey boxes though:


There’s a lot of room for improvement. Most notably, I need to fix the hair so that it is always blowing in the same direction. To do this, I’ll probably make the hair a separate sprite which gets overlaid over the main one.  Also she shouldn’t suddenly get a haircut when she is walking, but it is a good start.

Oh, and here’s a bonus gif of just the standing animations on top of a more detailed background.



28. Concept Art!

I wasn’t exactly feeling like my brain was functioning within established parameters yesterday, so I decided to work on some concept art.


I’m pretty happy with how it turned out. Part of the concern with doing an art pass on the game is that I wouldn’t be able to make the art look good and still be relatively low on noise. Since there are a lot of puzzles in the game that are about noticing small details in the environment, it’s important to avoid having distracting elements. I think this concept strikes a good balance between those two goals.

It’s still somewhat plain, and I do need to do a lot more work to be creative with the environment design, but overall, it doesn’t look too bad.

In addition to the concept art, I did spend a bit more time on some puzzles for the dice face area, and I think I’m relatively happy with that area for now. I also got a weird idea for a shifting maze puzzle that hasn’t quite fully formed into something good yet, and perhaps will not do so.



27. More Gallery, and More

This weekend, I went through my backlog of ideas of puzzles for the gallery area (an area that I mentioned briefly in the previous blog entry.) There are now actually 31 puzzles in that area, quite a decent number of puzzles, in spite of the fact that it sort of started as an “odds and ends” area. I still feel a bit uncomfortable about the concept behind the area, because it feels so explicit: here’s an image, solve some puzzles based on it. There are a few puzzles in the area that are a bit more subtle than that, and I have some hopes that when I get around to doing an art treatment on the game, I’ll be able to bring in a bit more of that subtlety. But, as is, I do like some of the puzzles in the area a lot, and testers have tended to enjoy them as well.

I spent a bit too much time on the stream drawing a perhaps poorly hung painting of a snowman for this area, so I’ll share the final image here on the devlog:


Other than gallery puzzles, I spent a bit of time trying to come up with some good intermediate puzzles for the dice-face area, as well as moving towards tidying up the end flow of that area. I didn’t make a ton of progress there, but I did start to make some interesting realizations about the mechanics there that I had not quite settled on before. I am hoping to come up with some good ideas there to take the end of the area to another level, but they haven’t quite hit me yet.

Overall, slow and steady with only being able to work a day a week, but progress is at least happening.

26. Regular Streams

I’ve been streaming on a regular schedule lately, so if you haven’t had a chance to come out to one of the development streams. They are usually at 3PM EDT on Sundays. This last stream started a bit later, but generally that’s when they are. Here’s a link to the twitch page.

I haven’t posted a devlog entry in a couple weeks, but I have been getting some good work time in on the game, thanks to the regular streaming schedule. Just been hard to find time between working on the game and my day job to actually write a update.

So, I’m pretty excited about some of the stuff that I’ve been working on lately, but I feel like I don’t want to spoil it. Most of what I’ve been doing laterly is puzzles that are a bit later in their respective areas. If you don’t care about being spoiled, you can definitely see exactly what I’ve been working on in the development stream archive, but I’m gonna try to keep the blog a bit safer as far as spoilers go, so I’ll just talk a bit in general about what’s up.

For the past two weeks I’ve been focused on the “dot puzzles” area, which I’ve talked about in a few previous blog posts. Specifically I’ve been working on improving the second half of the progression. The existing puzzles are enjoyable, but after a while, they can begin to feel monotonous. So I came up with some additional layers for the mechanics there. I also started mixing the dot mechanic with some other mechanics from elsewhere in the game. I am hopeful that the mixing will be at least a little bit surprising.

I know that’s a bit of a vague description of what I have been doing, but I’ll just post an interesting looking puzzle and let you speculate.


Additionally, after those two weeks of focusing on the dot puzzles, I was starting to get a bit bored, so I decided to shift my focus onto another area of the game. This is an area which I have not really talked much about on the blog here. I call it “the gallery” area. I like the area a lot but I want to avoid spoiling it as much as I can.

Again, most of the work that I am doing here is late in the area. However, I do think that many of the puzzles in this area are abstract and esoteric enough that it is safe to show you a teaser of something strange.


See you next week! I hope you come out to the stream. 🙂

25. Testing

So, as I mentioned in the previous post, I spent last weekend sending out a build of the game to several testers. Because the game is starting to get a bit large, I decided to cut out a couple of the areas which will be in the full game in order to focus the demo only on things that have changed.

What was left took most testers around 2 hours to play through, although some finished more puzzles than others. I’m uncertain how much additional playtime the removed areas would be, but I believe what was tested is a substantial portion of what’s in the game at the moment, so I wouldn’t expect it to add more than another half hour or so.

That’s obviously not really indicative of the final playtime of the game, as things will probably change and some areas will be expanded or reduced in certain ways. I’m a bit ambivalent about the length of the game, as the game is both intended to be “as long as possible” and “wasting as little time as possible.” I’m not entirely certain that it’s not entirely wasted time free, as there is still a lot of traversal time, especially for players who want to leave areas and return to them later. That’s certainly a problem that I hope to solve before shipping a final version of the game, probably by allowing players to warp in/out of each area.

Across all 5 testers, all puzzles were solved at least twice, so that’s some good evidence that the game is at least not totally off in cat hair moustache land. I’d like for people to have a hard time with at least some puzzles in the game, but at the moment there were really only two puzzles which totally stumped people. Not to say that the puzzles were easy, some players would easily spend 10 minutes on some panels. But I would like there to be quite a few more puzzles in the final game that cause people to pack their bags and go home without solving them, as long as they’re good puzzles.

For the most part, most of the things in the game are working the way they should be working. There weren’t many catastrophic failures, but I did have an issue crop up that I’m not entirely certain how to deal with.

Dice Conundrums

(The following could be considered to contain minor mechanics spoilers for puzzles in the game. I don’t describe how the mechanic works in detail or show any puzzle solutions, however.)

One of the issues which came up in this round of testing is one which I had already considered for some time, but have been unable to really come up with a proper solution to. And that’s for the puzzles in the “dice face” area.

For reference, the puzzles look like this, where they have tiles which are marked by black or white dots. The color of the dot indicates whether the tile should be on or off. As a player, which of the two answers on the right would you presume to be a correct way to interpret the symbols? Stop for a moment and think…


If you chose the one on the left, congratulations! You’re correct.

The issue, however, is that many players see the solution on the right as more intuitive. This is not particularly out of the question, as white meaning “turn it on” is quite a natural assumption, and I make use of that assumption elsewhere in the game. It makes sense, but there is an issue. Really, two issues.

Firstly, that when the player solves a puzzle, I light up the panel tiles which were highlighted very bright. In this case, white:


The issue should be immediately apparent here. If the correct answer is white on white, that means there is no contrast and we cannot even see the white dots anymore. It is difficult to see the black dots as well, but this could be remedied by choosing a brighter panel background color.

Alright, but I could still solve this issue in one obvious way, which is to make the solved panel color be something other than white, or make the white dot colors be not as bright, both of which are shown below.


This is fine a fine solution, apart from my other reason for choosing contrasting colors, which is simply for the aesthetics.

Where are the Dice?

There are puzzles later in this area which have more dots per each tile. The patterns of the dots are the same as those which are found on the faces of dice or dominoes.


Notice something about how dice and dominoes are colored? Notably, they are colored for contrast. Black on white or white on black.

There is another aesthetic consideration when it comes to the coloration, which you will find at the top of this blog, but I’m reproducing below in case I change the blog design later on:


If I take as a solution to change the solved color or the dot color, we would get the following:taijipanelvariations

Neither of which really look very good or imply what the original means to. This is a somewhat less important point than the previous one about the dice, but I believe it still stands.

Okay, so you may be thinking about one other possibility which I have not thus far entertained. Why not simply outline the white and black dots?


The issue here is, I think, quite apparent. I just don’t really have the pixels to go around to properly outline them. The five white dots on a white background is just a mess and doesn’t read properly as five dots.

Perhaps if I make the individual tiles bigger?


This solves the readability issue, but my concern now is that it is not very apparent which of the two possibilities is correct simply based on the visual.


I have perhaps rambled about this one point for long enough, but suffice to say it is not a problem that is entirely simple to solve, and I wanted to be clear about how much I have thought about it. I think I have a bit of an idea on how to mitigate the issue with future players, however. As I think a big part of the confusion is the lack of awareness of why they are even that way in the first place. So, I will try priming players with the idea of dice before they enter the area and this may help them to make that connection.

Even if it doesn’t, I have not had a ton of testers complain about this issue, and I believe I have at least two other minor changes that can be easily made to reduce confusion in the area.

24. I’d Appreciate Input

I’ve been extra busy the past two weeks prepping a build for testing, so I unfortunately forgot last week to write a post about what I’ve been doing.

It’s been around 8 months since the last test build that I did, and just testing out the new interface would’ve perhaps been enough, but instead I decided to make some changes, both to the existing areas as well as putting in a first draft of an area for the dot mechanic.

I made a list of tasks that I wanted to accomplish for this specific test build, and set about doing those a bit more diligently. I’d say this is generally a good idea if you want to ship anything: to set out the bullet-points that you need to hit and focus your efforts there. Unfortunately, I still took longer than I expected and didn’t get all of the things on the list done, primarily because I kept subdividing and expanding the tasks.

One of those tasks was to provide a basic tutorial at the start of the game, essentially just a readout with the controls floating in the area near where the player first starts. The issue there is that in order to show the proper controls I need to know if the player is using the mouse/keyboard controls or a gamepad, and it was surprisingly difficult to get this type of information with the input system that I was using.

That system was what I think was a pretty standard system built with the default Unity input system. I had inputs with labels like “Run Button” and “Toggle” and those were mapped to different actions in the game, and different buttons and keys. Unity doesn’t really support automatically remapping these inputs to a bunch of different controller types however, so I had to make a system on top of that where I would have a “XB” and “PS4” version of each input label and then just use some string concatenation to build the proper input strings at runtime based on the name of the input device (which unity thankfully does let me access). But by the time the inputs got to my code, I couldn’t tell whether or not they were coming from a controller or not, as both the XB and PS4 versions of inputs were doubly mapped to keyboard controls as well.

So, I decided to rip out and replace the entire input system in order to get that functionality, as well as to simplify the whole thing for any future input complexities.

In Unity, there’s really only so much you can do without just writing an external dll and handling the input at the OS level (which I may still consider doing). It seemed like the simplest and most straightforward thing to do was to get all of the raw input data that I can out of Unity’s system and then handle the rest entirely in C# code.

The way this worked out in practice was pretty straightforward for the buttons, as unity will just let me poll the event system and has keycodes for all joystick button numbers. With the axes however, I needed to set up input types in the Unity editor just to be able to collect them. I named the inputs “joystick 1 axis 0” through “joystick 1 axis 9”, and set them each to get the axis that matched their name. Although it’s a bit janky, with some string concatenation I now can get all the input info pretty easily into the scripting layer of Unity.

So, once I have all this input data, I need to know what to do with it. In a similar way to the previous input system, I get the name of the controller from Unity and compare it against known strings for each controller type (Xbox 360 or PS4, at the moment, as that’s what I have to test). If I find a controller matching that type, then I set the button mapping for a virtual controller (sort of a platonic ideal of an xbox 360 gamepad) to be equivalent to some pre-mapped structures which simply store the relationship between say, the A button, and a numbered button for that actual controller according to the Unity input system.

I also store another virtual controller for the PC inputs, but here there’s not really an input map. I simply hard map certain keyboard keys to the equivalent buttons. The mouse is stored separately, as it doesn’t exactly correspond to a controller input.

Additionally, whenever I poll each input (whether it be a keyboard press or a button), I update a variable which says where the last input came from,. This is then used to update the final virtual controller state that the game sees. I can also use it later to tell which virtual controller the latest input came from.

Perhaps it’s a bit difficult to explain, but I’ll try to diagram it below:


Overall, I am pretty happy with the results, and it solved the problem of knowing whether or not the player is currently using a controller or the PC controls. However, I still have some old virtual controller management code sitting on top of all of this that I would like to eliminate before I call this system completely rebuilt.

I plan on writing another post this week on some of my thoughts about the testing feedback, but for now I think I will leave it at that. 🙂

Oh, and here’s what the current controls readout looks like in game:03-20-17_20-10-10-1010.png

23. Heading towards a Test Build

Sadly, also didn’t have a ton of time to work on the game this week. Just the day job and me getting hit with a wave of depression, as I sometimes do.

But, I did get a few hours in over the weekend.

Part of what I decided is that I need to get a build out to testers as soon as possible, and that I felt like that was a goal post that kept moving. So the simplest way I could think to get things going in the proper direction was to make a prioritized task list for finishing a build.

I set up the task list in trello and have just been wailing away at it gradually. It might be fun to mention a few of the less obvious tasks that need to be done.

The first task was that since I moved the input method to a point and click system, I needed to implement a virtual cursor so that the game is playable with a controller. This was not too complicated, but there is a lot of room for improvement in the overall feel of the cursor. 

A secondary thing that the game has needed for a while now is some sort of in-game tutorial. Although I do plan on having a real developed sequence that teaches the player how to play in a streamlined fashion, for now it seemed good enough to just put some text floating around near the start of the game. I just don’t want testers to have to leave the game and look at the controls, as many times they forget to do that sort of thing.

The next big task that needs to be done before I can ship a build to testers is that I have to audit all the existing puzzles and make sure that the entire game is properly playable with the new interface. As of the moment, I know of at least one sequence of puzzles that will need some reworking. I don’t have a really elegant solution for fixing them but I do have something in mind that will work.

The problem comes in that with the old input method, the player had to be able to reach a certain tile in order to interact with a panel, and now they are free to interact as long as they can see it. For some of these interactions, simply powering down panels until the player solves the required puzzles will work, but for others, I still need the player to be in a certain area when they are working, and the only solution that I can think of there is just to still have a tile which the player stands on, and the panel is only accessible or unlocked when the player stands there.

Couple other things that I would like to have in the next build, one of which is the dot puzzles you’ve been seeing. Hopefully I can get this done in a couple weeks, at least at the current rate.

22. More Dot Puzzles

Sadly, I didn’t get much of a chance to work on the game this week. However, I did stream for four hours across two different sessions over the weekend.

An interesting puzzle that we came up with on stream. Special thanks to Tim Nicholson for help on it.

Most of the work that I did on-stream was on designing some more puzzles for the dot mechanic. I now have around 30 decent puzzles for a rough draft version of the area, which is more than half the number of puzzles as there are in the largest single area currently in the game. I still think I can get at least a few more good puzzles out of the mechanic, but I am quite happy even if I don’t come up with much more than the current puzzles anyway.

Below is a picture of all the currently existing dot puzzles. I haven’t built an area for them, so they are just floating in empty space in the editor. The circled area is the puzzles I have selected to be part of the rough draft version of the area. I simply showing them as black rectangles, because showing the actual contents would be spoilers. 🙂


Elusive Ideas

I came up with an idea for a new puzzle type in the middle of the night Saturday. (Strangely, I seem to get some of my most creative ideas around the witching hour) This idea was surprising in its simplicity, particularly because I never thought of it in the year and a half that I’ve been working on Taiji. I haven’t quite settled on how to implement it yet, so it remains in the amorphous “idea space” but it hopefully will be interesting when I do/can implement it.

Hope to get more done this week.

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.