So uh, I’m making a puzzle game now. Taiji really inspired me to make a puzzle game and it made me come up with some ideas for puzzle mechanics. I had a new worm in my brain and I wanted to start making a new thing.

So I guess that’s what I did. As with all of my projects, I ran headfirst into the problem entirely careless about how unprepared I am for this particular endeavor, or the fact that I’ve never actually made a puzzle. But nevermind that, how hard can it be? (very)

So what now?

Well, the first thing was to figure out what the puzzles will be like. The Witness used mazes as a base concept, Taiji used binary tiles as a base concept - what does Xau use? This one was surprisingly easy for me, and I’m not particularly sure why, but I chose node graphs. My main explanation is that it’s because I had the idea during/slightly after the Summer Of Math Explanation 2, so my youtube feed could’ve been filled with more videos about node graphs. But when I look at my history, I find a single video about node graphs. I really just don’t know.

Node graphs come with a few interesting challenges. I know that I’ll eventually have to face the graph isomorphism problem, but for my own sake I’ll just pretend it’s someone else’s problem for now, even though I’m the only person working on this project.

The real challenge I’m having to tackle is that node graphs give you a lot of freedom. This is generally bad for puzzle games - what you want to do is make the player start in a weird, seemingly confined possibility space and make them figure out how to apply the rules of the puzzle (which can be either the way objects move, for puzzles made out of physical objects, or whatever programmed logic you have made) to move forward. In Baba Is You, one of my favorite puzzle games, if you manage to get rid of all walls and all things that kill your character you’re usually more than done with a level.

So, adding restriction is important. Part of the way I’m planning to do this is making rules that constrain how many states the puzzles can be in. Which is what every witness-like puzzle does. It’s just slightly harder with a node graph because of the lack of base restrictions.

The other issue is teaching the player the rules. Xau will (mostly) follow the “tradition” of not using words for anything, which means that I have to communicate thigns non-verbally. Matthew Vandevander, creator of Taiji, has a series in his youtube channel where he analyzes how The Witness does this, which is very convenient for me, but I also want to look into how to do this myself. Maybe I should do an analysis of games like Understand, to see if I can get fresh ideas. I think that could be pretty cool.

A friend helped me come up with a series of puzzles that teach the player everything they need to know about the node graphs and the first mechanic that the game introduces, and then finishes it up by testing your knowledge of everything you learnt before proceeding. It’s simple, and the player will likely not feel like they’re being taught anything, but the design is sneakily making sure that one knows what kinds of structure one can make within the rules of this game. I’m thankful for her help there.

Another interesting thing I noticed with playtesters of the early versions of the tutorial area was that people with less knowledge of The Witness and similar games get stuck in places where people who do know about that game would go by easily. It was an interesting lesson in videogame literacy - Xau was expecting the players to have played a videogame that is like Xau, of which there (as far as I know) are not many.

I had seen people face similar issues in other games - Hollow Knight expects you to know how metroidvania games work, for example. But I’ve never really had to solve this. I ended up making the tutorial shorter and simpler, trying to remove redundancies, but making sure to guide the player’s hand a bit more before letting them experiment further. I think I succeeded at this - no other playtesters which haven’t played similar games have gotten stuck at it so far.

A thing that I’ve had to design (and which I’m actually quite proud of) is how the game teaches you the basic controls. It first makes you press the space bar to verify a puzzle that is wrong, then teaches you how to connect nodes, then tells you to press space again to verify the right answer. It’s almost like what Taiji does, but I feel like Taiji doesn’t really make it initially clear that the space bar confirms your solutions and that you need to press it to check if your solutions are correct.

After these, I think I’ve gotten better at showing things nonverbally. Few people have gotten stuck at the new mechanics I’ve added, and I’m pretty sure that the thing that is to blame is my inability to notice patterns that may be misleading for the player and confuse them further. This was an interesting reminder for me to take that visual design decisions aren’t just visual in a game like this - they may be what the player decides to use as a clue.

This is certainly an interesting project to undertake. I hope to see it finished, but knowing me, that may take a while, or not happen at all. Either way, I hope it’s interesting enough both for me and anyone who may happen to care.