Category: Design

84. How I Design Puzzles

~ Matthew VanDevander ~ Leave a comment

This post was adapted from an answer to one of my playtesters questions:

What methods do you usually use to design this game’s puzzles, and which of those methods do you think lead to the best (most enjoyable?) result?

There are three main approaches to designing puzzles in this type of game that I’m aware of.

1.Top-Down Method

This approach starts with the solution state and works backwards to constrain the puzzle so that this is the only solution.

This is an approach which I very rarely, if ever, have used in Taiji. There can be some valid reasons to choose it–if one is in a tight spot and needs to solve another design problem perhaps–but generally you don’t have much luck making good puzzles with this approach.

As a caveat, all design approaches include at least some “top down” elements. For example, one has to pick an idea that seems interesting in the first place. Though it should be easy to see the difference between “this point is connected to this other point” as a top down imposition, and “this is the exact path that you take to get there”. So the problems of this approach often come with the extent to which it is applied. Keeping things in balance I think is a theme that will be clear through this discussion.

Also, if I move to include the observational puzzles in the game, you could argue that those are fully top down designs. But since those puzzles are more about observation or abstracting something in the environment than they are about logic within a grid, the design approach is different. This discussion will be long enough just focusing on the logic puzzles, so I’m going to have to leave the topic of environmentally-clued puzzles undiscussed for now.

Moving on to the next approach.

2. Experimental Method

In this approach you basically just plop down some random things and see what happens.

This sometimes produces good puzzles, but it’s difficult to make larger puzzles that have good solution paths through them. Getting good puzzles this way is mostly down to luck, and with smaller puzzles you just tend to have better luck. Regardless, this approach is the only one you can take early on, since when you are still adding new mechanics to the game, you still have a lot to learn about how your own game functions.

Another downside to this approach that perhaps just affects me personally, is that when just plopping things down randomly, I tend to draw symmetrical shapes because they “look nicer.” Unfortunately this also tends to create symmetrical solutions in Taiji. This is still in the game often enough that players can notice the pattern, but I’ve worked hard to make sure that it is not a universally applicable tactic. It’s okay to have symmetry show up sometimes, as it is thematically appropriate, but too many times and the game falls flat.

And the final design method.

3. Forwards Method

This is the trickiest to explain. Here is a link to a long form explanation and example, but the basic gist is that you start with some deducible situation and place that into the puzzle. You can then add more deductive moves into the panel, creating as much specificity as you want.

This method is useful because it gives you the most control over the players path through the puzzle. You are designing the moves that they will make in the order they will make them.

With that said, it is a tool that must be used with care. Just because you can fully specify every tile in the solution doesn’t mean that you must. Sometimes leaving a little play in the puzzle is more interesting. In a pen-and-paper puzzle, you don’t want multiple solutions because the solver needs to check against a canonical solution in the back of the book, but in a video game you can be more flexible and you should.

Use your discretion as a designer and prune alternate solutions if they allow the player to miss the main idea of the puzzle, but there’s more than one way to skin an electric eel and part of the magic of video games is that they are a bit different for every player. Try to embrace that whenever your design goals allow it.

In the best case, the forwards design technique can allow you to focus your puzzle designs around strong core ideas. But in the worst case, it can lead to a flat feeling, where all puzzles become a sort of paint by numbers.

Still, it is the most powerful technique that I have learned over the course of designing Taiji, and even through it is dangerous, I think it is a requirement to have this tool in your toolbox. It’s just important to remember that you are designing puzzles to serve the overall game design and not to serve the tool.

My Approach

So I mostly use a combo of methods 2 and 3; the experimental and forwards methods. But I think the best puzzles tend to come from a mixture of forwards design and some happy accidents. There are also meta aspects that I could get into which can really take puzzles to another level, but I’ve gone on long enough so that will have to wait for another time.

In any case, over time I have leaned more towards judging puzzles by their content instead of by their enjoyability. I think this is a more stable approach once one becomes more sure of themselves as a designer. However, this does sometimes lead to situations like one I had the other day. There is a particular puzzle in the game that I always loved, but which I have come to realize many players find annoying. I was so convinced that the idea for the puzzle was good, that I didn’t worry too much about its enjoyability. Sometimes this is a good approach, however in this case, my disregard for the enjoyability of the puzzle led me to overlook its failure to communicate any appreciation for that core idea. Players found the way in which I was presenting the idea so repulsive that they came away finding the idea itself repulsive.

I knew the idea was good though, so yesterday I went back to the drawing board and designed a new introduction to the idea.

So, as with all game design, be sure to test your design theories against reality and see if you’re getting an acceptable response. Not everyone has to enjoy every puzzle, but if most people hate a puzzle that you’re in love with, then perhaps there is something about the way you presented that idea that could be improved.

As an aside, I want to mention the two biggest mistakes that I see other designers make. The first is not listening enough to others early on in their careers, and the second is listening too much to others once one becomes more established. When you’re starting out, you don’t even know what you don’t know, and it’s more likely than not if someone has a criticism of your game, that you probably should change something. However, as you develop skill and experience as a designer, it is important to learn what your own tastes and values are, and accept that sometimes these will conflict with those of other people who play your game. Accepting feedback and having a guiding vision are both important forces to keep in balance.

Conclusion

In summary, I think the best puzzles are the ones that have a strong idea at the core of them. Something that can be verbalized like “this puzzle shows you that when X and Y are the case that Z occurs” or “this puzzle is about carefully interweaving 4 things while maintaining symmetry” or “this puzzle introduces this new mechanic, but requires the player to deduce its meaning by virtue of it being the only possible explanation”.

I haven’t always lived up to this standard with every single puzzle in the game, but when I haven’t, I have at least made sure that the puzzles serve a pacing reason or form a sequence or meta-structural element that has some unique interest to it.

And well…sequences and meta-structure can add immensely to the enjoyment of a puzzle game, but that’s a whole additional discussion which will have to come at a later time.

Elyot Grant’s 30 Puzzle Design Lessons, Extended Director’s Cut – This is a fantastic resource, and although lengthy, is an extremely enjoyable watch as well.

80. A Trip Down Memory Lane

~ Matthew VanDevander ~ 2 Comments

This post is adapted from something I wrote in the Taiji Discord, but I thought it might be interesting to share it here. By the way, you should totally join our Discord if you haven’t already.

Discord user GingerBread asked: “is there a specific reason why you chose tile shading as a basis for your puzzles instead of line drawing for instance? Was it mainly not to be too close mechanically with the Witness, or did you have other motivations?”

My Answer

The puzzle mechanic came about a bit differently, in that the game didn’t start as a Witness-like game.

Initially Taiji started out in April or May of 2015 as a sort of reimagining of a what a Zelda game could be. I was working with a very talented artist and musician named Martin Cohen and we were just calling the game ZG (for Zelda Game) back then. This was before Breath of the Wild was ever revealed in detail and I was sort of thinking about what a more modern Zelda game might be like: open world, non-linear, hard combat, and one of the things I thought would be good was to have some sort of core puzzle gameplay. (This obviously all ended up being done by Nintendo in their forthcoming game but anyway it was the headspace I was in at the time)

I had initially started work on combat design and some world design ideas, but I realized that I didn’t have any experience with combat design and was having a hard time making progress there at something interesting in a prototype form. So, I decided that I would switch focus and try to come up with something for the puzzles. I had many years of puzzle game design experience already so I thought it would be easier to make headway there.

I was not setting out to do something explicitly similar to the Witness, although I was inspired somewhat by Jonathan Blow talking The Witness having “core puzzle gameplay.” For example, a first person shooter has the core gameplay that you shoot enemies and dodge their attacks. This core gameplay gets repeated over and over across the game, but because of the depth and variation within that core gameplay the game doesn’t get boring just because you’re “doing the same thing over and over”.

Most Zelda games do not have core puzzle gameplay. Although they are not as bad about this as point and click adventure games, they do tend to have disconnected puzzle designs that at best maintain a theme across a single dungeon, and at worst are complete one-offs.

So I knew that I wanted to have some sort of core puzzle mechanic that the player would engage in across the whole game, but that would still have enough depth to stay interesting. The concept for the puzzles being about toggling things into some sort of pattern really just came to me, so unfortunately there’s not a cool story for why I thought of that. But the initial idea was a little different than what it eventually became and was more like the Mattel game Lights Out (a game which I had never heard of at the time). So you would toggle a tile and it would also toggle its neighbors.

So I made a little prototype of that and it seemed interesting. However because I imagined that the goal would always be to just light up the whole grid of tiles, I didn’t think there was tons of depth in that mechanic alone. Instead I imagined that the game would have variety through different input methods. So I also implemented some “snake” type puzzles where you would be forced to fill the grid by drawing out a path (this type of mechanic is still in the game in a few spots).

This still wasn’t that interesting, so I instead started thinking about how I might clue the player into different things to put on the grids. I came up with a couple puzzle sets that I thought were itneresting (both of which are in the game still in a somewhat evolved form), and I felt like I was really getting somewhere.

Unfortunately, I still had not figured out anything about the combat, and I also felt like the puzzle design would really take some time to flesh out (I didn’t imagine it would take 5 years). But because I knew I was onto something really interesting, I wanted to spend as much time as possible prototyping the gameplay before really committing to anything. So I suggested that Martin take a break from doing art and music concepts at least until I had developed this part of the gameplay further. (Ultimately I decided that I would pursue the project solo, though this in no way discounts Martin as an artist and musician, and I enjoyed working with him immensely. It had much more to do with my fear of relying on anyone else, but that’s a story for another time perhaps)

So I shelved the combat and focused on puzzle design for a while. I designed a set of puzzles that let the player just toggle things in a free form way with no particular constraints (this was just going to be another one of the interaction methods at this point). Suddenly it was nearing the end of 2015, I had a growing document full of puzzle ideas, and soon a game that I had been anticipating for nearly 7 years would be released.

That game was The Witness, and my hype level for the game was somewhere above what was reasonable for a jaded 26 year old man. I thought that the game might (just maybe) turn out better than Braid.

I just happened to be laid off of work when The Witness released and I played it all day every day for a week until I had seen everything it had to offer me. I was blown away. Not only did I find it better than Braid. Not only was it the best game I had ever played. I thought perhaps it was the best puzzle game possible.

I was elated, but I was also devastated. Much to my surprise, almost all of those exciting gameplay ideas in that document I mentioned earlier were also in The Witness in stunning fully developed forms that were much better than anything I could have done.

…what was I going to do now…?

I felt for a time like there might be no point in what I was making. It felt both too similar and and also lesser. I recall an email chat I had with Brian Moriarty around this time where he commiserated with my feelings of burgeoning irrelevance, and opined that Jon had “made Salieris of us all”. (Don’t know who Salieri is? Feel free to google it, but honestly that’s kind of the point)

However, I picked myself up off the ground and resolved to continue forward. Although The Witness had well mapped the territory ahead, I felt I could use it as a guidebook on what types of things would work in this kind of game and when there was overlap between the ideas, look for different forms of those ideas to the form they took in The Witness. I set out to make Taiji into a game that was both similar to, and different from, The Witness.

If The Witness was a telescope with which one could peer out at the universe and see certain ideas, I began to see Taiji as a different telescope with a different vantage point with which to look at some similar ideas. There was value in the different perspective even if sometimes the subjects were similar

With that said, one of the big things I chose to copy from The Witness was the symbols on the puzzles that you slowly discover the meaning of through experimentation. This ended up forming the bulk of the gameplay depth of the game, and I have been relatively happy with the degree of overlap and separation between the two games puzzle ideas.

Eventually as the game developed further, I felt like the alternate puzzle interaction methods were the least interesting things in the game. Also because those puzzles were just about space filling with no symbols or environmental cues it was casting this doubt on all the other puzzles that “oh maybe I just fill it all in?”

So the “lights out” type puzzles and the space filling stuff in general was cut from the game. And I also gave up on combat. (The Witness + Combat could still be interesting, but Taiji is not it) So the final game now focuses on puzzles where you can freely toggle tiles, and there are a few snake type puzzles that use a different interaction method where you’re walking on the puzzle in order to toggle the tiles.

I don’t know if that answers the question about how I chose tile shading, but hopefully it was a fun story!

P.S. The Mill area is done now, I did a video devlog about this, and here’s a screenshot:

77. One in a Mill-ion

~ Matthew VanDevander ~ Leave a comment

Gosh, time sure does fly when you’re making a game. I seem to have let June slip by without an update here. Although I have kept up with the video devlog series over on the YouTubes, I recognize that some folks just like to read a little more than they like to look at my beautiful face and unkempt mane.

I’ve been fixing up small things around the game that have been annoying me for a long time. There’s still bunches left undone on the “nice to have” list, but I’ve tidied up some important ones. Mostly I’ve been doing this because the progression on the artwork for the Mill area has been going a bit slower than anticipated (even though every time I do an area I anticipate it will take more time than the last!)

Part of the delay has been from doing some design revisions to the overall flow of the area. I mentioned these plans in the previous post, but I wasn’t expecting that the structural changes to the area would require so many puzzle design changes as well. It turns out that when you are planning on having an area be mostly knowledge-gated, you have to design puzzles that are specific to this purpose. Good knowledge-gates put up an initial barrier of complexity, but then fall rather quickly if the player has the pre-requisite knowledge.

Who’d have thunk that a good knowledge gate is one that gates mostly on knowledge!

In addition to this, I felt like there were a few small ideas in the area that could use a bit more polish in how they are delivered to the player. One of my favorite things in puzzle games is when I’m put in what seems like an impossible situation, based upon everything I’ve come to assume about the mechanics of the game. But the design or layout of the puzzle allows me to deduce that some move that was previously unknown to me must be possible. So, I have been doing some redesigns to create that type of experience. Requiring the player to guess that there is some emergent behavior of the mechanics that is non-obvious rather than giving them a simple situation which just illustrates it.

At this point, I’m fairly happy with the puzzle set for this area, and I think that the flow of ideas will work well. So I’ve spent the past week or so sketching out some rough ideas for the visuals. This has required me to do a lot of research on different types of machinery so that I can hopefully create something a bit plausible as a functional space.

Concepting is still a work in progress and things are subject to large changes, but here are some things that I’ve drawn along the way so far.

76. Endings and New Beginnings

~ Matthew VanDevander ~ Leave a comment

Things are finally progressing! I finished up the endgame area a week ago and shipped that out to a small group of testers. I believe there will still be some changes/improvements there, but overall I’m happy with the initial feedback I’ve seen.

Experience has shown me that when I take this long between builds of the game, major things will end up broken. Because of that, I’ve been taking a little downtime between shipping this build and implementing the next major area for the game. I didn’t want testers finding game-breaking bugs while I’m ripping up so much that I can’t ship a build until I finish the art for the next area.

Thus far, The bugs have definitely started to flow in. In fact, I’ve not been able to address the endgame area feedback as much as I’d like because there were so many other bugs. But it’s good to have my decision to postpone major changes validated.

In the meantime, as part of my break from game-breaking work, I’ve completed one of those “nice-to-have” improvements on the list; something I thought I might not be able to get done before ship: I’ve been re-doing some of the art for the starting area. You can see a couple comparisons below:

It’s hard to believe it’s already been two years since I originally did some of this artwork, but it’s been in desperate need of improvement for a while. I think the revision has much stronger details while also having a cleaner look that fits better with the rest of the game’s aesthetics.

It’s also a bit of a testament to how much I’ve improved as an artist over the course of this project. When I first started doing the art, I really didn’t know if I’d be up to the task. I’ve done some dabbling in visual art through my life, but I’ve never considered it something that I was particularly strong at. But through a combination of thoughtful art direction choices and just churning away for years on end, I think I’ve achieved something that looks nice and works well for the game.

So, What’s Next?

As I mentioned in the previous post, the next major task on the list is the artwork for the Mill area. I also need to re-think the structure of the area significantly. The current implementation is too straightforward and boring:

As you can see, most of the area is just a straight line. Although there is a bit of branching in the middle, the puzzles on the left side there are completely optional, so the main thrust of the area is totally linear. This structure, combined with the sheer number of puzzles in this area (44 essential, 25 optional), can be pretty exhausting for players to go through, and although adding artwork to the area can help significantly with the fatiguing aspect of the experience, I also want to try some other things.

I’ve experimented a bit with the structural designs for each area as I go along. I always try to do something a little different. Some areas are very linear, with a straight line of puzzles you have to all do in order. Some are mostly linear but with a few splits that you can do out of order. Some are almost entirely non-linear, with many options that are equally challenging.

One of the things I’ve thought about doing with the Mill area is designing it a bit “backwards”, with the player finding the hardest puzzles in the area before the introductory panels. This could backfire horribly, since some players may assume they should be able to solve anything that’s accessible to them, but it fits into my plan to go for a much more non-linear and knowledge-gated approach to this area than I have achieved with any of the others.

By “knowledge-gating”, I’m referring to the concept that the only barrier to progress is that you don’t understand how to do something, rather than requiring the player to obtain some item, or solve a long set of puzzles elsewhere.

Perhaps the area will be split into several buildings which can each be entered by solving a difficult puzzle. Each of these difficult puzzles will require some knowledge gained elsewhere in the area. This means that the player will have to explore around a bit when they first enter the area before they find a puzzle they can gain some traction on, but hopefully it will create that fun experience where the player realizes, after learning some new concept: “Aha! I know how to do that other puzzle now!”

I always try to push myself to do better with every new thing I add to the game. It’s what keeps this project engaging and enjoyable for me over such a long development cycle. (coming up on 6 years now!) Unfortunately this does mean that each new area has tended to take longer than the previous one, but I’m excited to get started on the Mill, and I think it has potential to be one of the better areas in the game.

75. Putting the Ends Together

~ Matthew VanDevander ~ 1 Comment

I am still working on the Endgame area. I had hoped to be done with it by the end of last year, if you can believe that. So I would say things are progressing quite a bit slower than anticipated. With that said, the puzzle design for this area is now complete, as is most of the art, so I’ve just been assembling the pieces that I’ve created. Wiring up the bits and the bobs, so to speak. I’ve been doing a lot of this on stream, compromising a bit on my desire to keep everything about the Endgame unspoiled, but I think it’s more important for me to be able to focus and get the Endgame area done as quickly as I can.

Here’s a spoiler-free screenshot of some of that:

Once I finish the Endgame, there’s really only one large task left on the list, which is the Mill. So, in spite of being behind schedule, there’s still a decent chance that I can ship the game roughly on time. As I regretted in the previous devlog post, I do wish there were more time for me to polish up stuff and re-do bits I’m not as happy with as I could be. But alas…

One major thing that I’ve had to cut is simultaneous console ports of the game. The current plan is for the initial release of the game to be PC only, and then I will do one unannounced console port as soon as is reasonable. It would help me a lot with determining where best to focus if you would answer the following poll.

73. Website Updates/Ending Puzzle Games

~ Matthew VanDevander ~ Leave a comment

Since you’re reading this on the development blog, you’re probably already aware; but I freshened up the home page to be cleaner and more informative for newcomers. There’s also some nice links at the bottom to all of the places you can find Taiji around the internet.

Speaking of which, you can now join the Discord group and chat with other folks who are excited about the game. We’ve got room to grow, so I hope you’ll consider joining our little community!

If you have any suggestions or complaints about the website or the discord group, then you can leave a comment on this post or talk to me on Discord and I’ll see what I can do!

Working on The Endgame

Taiji’s ending involves some puzzle concepts that I don’t want to spoil, so this article will be spoiler-free as far as Taiji is concerned. However, I will need to discuss some other game’s endings for context. Spoiler sections will be marked if you want to skip them, you may be able to pick up enough with context.

Because I want to keep the ending a surprise, I haven’t been able to work on it on my livestreams. But bouncing between working on art for the livestreams and working on the endgame prevented me from being able to do the type of Deep Work necessary to get the ending right.

However, as I’m heading into what should be the final year of development, it is urgent that I have this part of the game design worked out, so I’ve been taking a bit of a sabbatical from livestreams so that I can focus on getting the ball rolling here. This past week has involved dusting off some code that I haven’t touched in almost six months.

What Makes a Good Ending?

Making a satisfying ending for any video game is a challenge, but I think I puzzle games are a particular enigma. With action games it can often suffice to cap things off with a particularly difficult boss battle. But what is the equivalent of a boss battle for a puzzle video game?

The most straightforward interpretation might be to simply have a really hard puzzle to cap things off, but this is a fundamental misunderstanding of the role that boss battles serve. Boss battles are not simply “the normal gameplay, but harder.” Instead they offer a different type of gameplay than the rest of the game. The boss enemy will usually have complex movement patterns that require memorization, and may change over the course of the fight, or perhaps the environment will become involved in the battle in a way that it previously hadn’t.

The important takeaway is that satisfying endings require a change-of-pace. There ideally needs to be a shift in the gameplay style, context, and intensity. How you choose to accomplish this is really up to you, but the point is that although a hard puzzle may suffice for the ending to a smaller subsection of your puzzle game, it cannot be relied upon on its own to create a satisfying final coda.

So, let’s take a look at some of the methods that other games have chosen in order to achieve this change of pace. One of the most common methods that I’ve seen is to introduce a timer of some kind.

(mechanical spoilers for the end of Portal and Portal 2 follow)

Both Portal games, for instance, end with boss battles where the player must solve a series of portalling challenges in a limited amount of time. Apart from a bit of a forced mechanical trick at the end of Portal 2, both games don’t introduce any new mechanics at the end and instead have the player exercising basic puzzle skills that they have mastered earlier in the game, with most of the challenge coming from the time constraint.

(end Portal spoilers)

The problem with puzzle games having time-constrained challenges is that they can devolve into a sort of worst-case scenario if you’re not very careful about designing them. If the puzzles are too much of a challenge or the time limit is too aggressive, players may find themselves repeating one of the least replay-able forms of gameplay besides horror.

(I mean, I’m a huge fan of puzzle games, but it’s an obvious fact that you often get much more out of replaying action games due to the dynamics of the gameplay than you get out of replaying a fixed set of puzzles, even in a fantastically well-designed puzzle game.)

(mechanical spoilers for The Witness follow)

One possible way of resolving this problem of repeatability is to introduce dynamics into the puzzle gameplay. The Witness does this with procedurally generated puzzles both in a small subsection of the Mountain ending, and in large form in its hidden Challenge area. Although the player must repeat the Challenge many times in order to succeed, because the puzzles are different each time, the player is never doing the exact same set of gameplay events through their many attempts.

(As a side note, if we consider The Challenge to be one of the endings, The Witness actually has three different endings: The meta-puzzle gauntlet inside the mountain, the time-limited challenge, and the sky lounge ending. Perhaps The Witness is “covering all the bases”, having multiple endings which might satisfy different players in different ways.)

(end The Witness spoilers)

There are lots of different approaches that have been attempted with puzzle game endings, and I won’t rule out incorporating some aspects of what other games have done into the ending for Taiji, but it is my plan right now to attempt something that I have not seen done before.

With that said, it is a large design and tech challenge and it is still in the nascent stages as of the writing of this article. But if I can pull it off, I think I will have created something that I personally can be satisfied with.

Oh, there’s also a another ending. 😉

62. Metamusings

~ Matthew VanDevander ~ Leave a comment

Four of the ten major sub-areas of the game involve symbols embedded into the puzzle panels which the player figures out the meaning of over the course of the area. In each of those areas, there is also metapuzzle used for navigating that area. These metapuzzles require the player to solve multiple puzzle panels which interact with eachother in some way. Each area has a unique theme to this metapuzzle which is connected to the general theme of the area’s mechanic in some way or another.

I’ve had three these metapuzzles designed for a while now, but I’ve been spending the past week or so designing and implementing the fourth one. I’m also in the middle of ripping up the area containing it and doing a proper art pass on it, so the following screenshot is an example of something super work-in-progress:

I don’t want to explain too much of how the puzzle works, so as not to spoil things, and because I am likely to change some details as I continue implementing it. But the basic idea is that you can move the bridges between each circular platform and you use that to get around the area.

It’s been a bit of a technical challenge to get this puzzle implemented, and as of this writing, there are still a few features that are not set up yet. Part of the challenge here is that so much state can be changed across the metapuzzle, and it’s important to keep all of the state in sync.

The overall theme for the area is a terraced garden surrounding a dry lakebed. The major features of the area are still work in progress as well, but I have begun some work on the artwork for the entry terraces, which you can see below:

These will require some more detailing work, but the overall structure is more or less correct. The design of the stepped gardens is loosely based off the Hyakudanen at Awaji Yumebutai. In the game, the player will start at the stop of this stairwell as the entryway into the area. Once they get to the bottom, they will find some puzzle panels opening access into the metapuzzle section.

58. Arts and Crafts

~ Matthew VanDevander ~ Leave a comment

This past month, I’ve been both working on Taiji and crunching on promotional materials for Manifold Garden. (Which is out now on Apple Arcade and the Epic Games Store, by the way! You should check it out if you like puzzle games. I get no extra money if the game does well, so I am just recommending it personally.)

Seeing off Manifold Garden has been exciting. But turning back around to work on my own thing has been a bit depressing. It still has so much further to go before it will be done! I’ve been trying to keep my head on straight but it’s been a bit of a damper on my spirits.

The Breaking Point

Some technical aspects about the visuals in Taiji started to come unraveled earlier this month. One of the decisions I made early on was how to sort all of the individual graphical elements in the game. Although for 3D games, sorting is just handled as part of the perspective (except for translucent objects), in 2D games you usually set up an explicit sorting order.

In Unity, there are actually two systems you can use to handle sorting, the first is a sorting axis, which is equivalent to the Painter’s Algorithm: objects that are further away from the camera are drawn first and closer ones are drawn last.

The other system is Sorting Layers. These are just buckets you can put different objects into and you can set the order in which the buckets draw. My initial idea was to only use 3 sorting layers for the entire game: a layer below the player, the player layer, and a layer above the player. This seemed like it would work, because you are additionally allowed to specify a numerical sorting order for the objects within each layer.

The primary benefit of this approach is that it is player-centric. This means that I know that all objects in the “Below Player” layer will always be drawn below the player, and vice-versa for the “Above Player” layer.

But what happens if I want to have objects that are above the player at one point, and then below the player at another?

There are two types of scenarios where this problem might happen.

One is “vertical” objects that the player can walk around, such as trees. If we place them below the player, the player will be walking above the branches, and if we place them above, then the trunk will float over the players head. This problem is easy to solve by simply placing those objects on the player layer. In this case, Unity will fall back to the sorting axis and sort by distance. However, we can tell Unity to sort using the Y-axis, instead of the Z-axis. This means that objects that are higher on the screen than the player will draw behind them, and those that are lower, draw in front.

The other slippery sorting situation is when the player is underneath an area which they can climb up into. A basic example of this is a bridge over a canyon. The player might be in the canyon, walking underneath the bridge, but they can also climb out of the canyon and end up above the bridge, walking across it.

The player can go up those stairs at the top of the screen and then walk over the bridge.

This scenario is challenging to achieve under a simple 3 layer (Below Player, Player, Above Player) setup. The only real way to do this is to either shuffle all the objects between the above and below layers, or have copies of the objects on both layers, and only enable whichever is appropriate depending on where the player is.

I was using a mixture of both of these systems up until recently. It worked, although it was quite cumbersome. You’re moving around of dozens of objects from layer to layer all the time, and you can’t even see any of the visual issues until you run around the game. But eventually you run into scenarios where there need to be more than two layers, and it all falls apart.

So I made the difficult decision to change the entire sorting system used by the game. Under the new setup, each area in the game has a sorting layer, and the player is moved from layer to layer as they walk around the world, always staying at order 0 in whichever layer they are in. Objects with negative sort values will be below the player in that sorting layer, and those with positive values will sort above the player.

This setup makes so much more sense. Since only the player ever moves around, I never have to worry about the environment looking any different than it does in the editor.

In fact, I feel like I should have changed things over much sooner than I did.

I think this particular type of mistake was misguided optimization, which is even worse than premature optimization. Instead of optimizing for my sanity, and the simplicity of building the game over the long haul, I tried to optimize for the number of layers without being sure that it would ever be an issue. It wasn’t a performance concern, more just an aesthetic one.

I think it’s important to accept that your game is going to be a big icky mess at some point anyway, so you just should just leave the cleanup until you can actually see what you’re dealing with.

In any case, things haven’t been perfectly rosy with the new setup, but I’ll leave that story for next month perhaps. See you soon.

Proof Of Work

Perhaps you’d like to see the work I did related to Manifold Garden? If so, you can check out the following links:

Mood Trailer

Manifold Garden Instagram (Daily Videos since July 18)

Edge Detection & Anti-Aliasing Comparison 2015 vs 2019

Architectural Inspirations

Now Available Trailer (Although about 80% of this was Derek Lieu, and I just polished it up and replaced a few shots)

I also did a ton of odds and ends stuff that I can’t really take the time to list here, but suffice to say it’s been a bit busy.

55. The Sound of Music

~ Matthew VanDevander ~ Leave a comment

Apologies for being a bit late on this devlog entry. I’ve doing a little bit of super part time contract work for the past several months, to give myself an occasional mental break, as sometimes problems in Taiji just need some clock-on-wall time for me to really solve effectively. Anyway, that contract work got unusually non-part-time the past two weeks, so I didn’t end up writing the devlog post when I meant to.

Recently I finished up the mainline puzzle set for a new area in the game. I call these puzzles the “line” puzzles, which may give future readers a hint as to what I’m talking about. I think it came out quite well for a first draft, and I really only need to do the mix-in puzzles with some of the other mechanics in the game before calling it a finished draft. There’s probably some serious ways to push on the concept, particularly at a meta level, but I’m glad there’s something approaching a finish line for that area. In any case, I don’t want to spoil the details of that area, so I’ll keep it all a bit mysterious. However, I need to actually talk a bit more in-depth something, so I’m going to discuss an area that has been in development hell for years: the sound puzzles.

Don’t worry, I won’t spoil very much about the details, other than to say that there are some puzzles in the game that focus on sound. They’ve been put on the backburner mostly because I was a bit worried that they wouldn’t be much appreciated. You see, audio puzzles in games have a bit of a shady reputation. Even the audio puzzles in The Witness, of which I am a big fan, tend to be derided by most players as “basically impossible”.

But recently I decided to dust off the old concept I had for them and implement something a bit more complete than my first prototype.

The initial reaction from playtests has been…well, not great. I’m still not sure whether what I’m doing is just not working, or if it’s just not found the right players yet. I’ve more or less decided that I’m willing to accept if only 10% of players actually enjoy the area, as long as they really do enjoy it. The last thing I want is for everyone to like “the idea” of the area, but for no one to have enjoyed it. So hopefully some players will enjoy it, and as for the rest of players, at the very least they should be able to complete the area with the help of some assist mode features.

It’s actually a bit hard for me to decide on the exact form that the puzzles for this area should take. I am certain of the core idea, as it is something that is fundamentally interesting to me, connects to something real outside the game, and something that is a natural fit for the puzzle style of the game. But there are probably two or three decent ways of implementing that core idea, and I’m not certain I’ve chosen the best one for my first implementation. I’ll have to think about it some more, and perhaps give it some more of that patented clock-on-wall time.

I think one of the best superpowers that a designer can develop is a sense of comfort with things sucking for a long time. The longer you can be comfortable with some part of the game being terrible before deciding to cut it, the better chance you have of stumbling on some good ideas on how to improve the area.

With that said, there are actually 2 or 3 areas in the game that I’ve been a bit stymied on for a while. I’m more or less twiddling my thumbs on those concepts, hoping for some inspiration to strike. If it doesn’t, I may strongly consider cutting those areas from the game completely. I really hope that I don’t have to though, as the core concepts for the areas are interesting to me.

One somewhat irritating thing is that other people who’ve played the game advise me that these areas in question “have a lot of potential” and that I shouldn’t cut them, but fail to have any insight on how to capitalize on that potential. In the end, game design can be a very solitary journey.

A bit of a short one this month, but I’ll try to be on time…next time!

54. A Chicken With Its Head Cut Off

~ Matthew VanDevander ~ Leave a comment

So, this past week I spent a few days polishing up the character movement and animation, primarily focusing on adding running animations. The results are as follows (Recommend watching at 60fps):

I’m pretty happy with the running animations, although they do make the walking animations look a bit cheap by comparison. I figure most players will just toggle running on and play the game always running everywhere, so it’s probably fine if the walk animation is not as developed.

This week, I’ve also been trying to think a bit more concretely about the big picture ideas for the game, including story and world design.

Right now the world design of the game is pretty much non-existent. Everything in the game is just laid out in the way that was most convenient to fit everything together without overlaps. However, I’d like to do something that has a much more overlapping and interconnected feel.

My ultimate inspiration for world design is Dark Souls (wait wait don’t close the browser tab). I don’t necessarily want to attempt that game’s scale, but one of my favorite things about the game’s world is how you head off in a long winding direction that you think you will never come back from, only to find an elevator that takes you straight back down to the central hub area, unlocking a massive shortcut in the process. This creates a wonderful sense of surprise and is a real tangible reward for exploration. And the best thing about it is that there’s almost no cheating involved in the 3D space of the entire game world.

If you’ve played the game, you probably already know all about this. But if you haven’t, here’s a good look at the world of Dark Souls using a map viewer tool:

Now, obviously this is a very high bar to attempt to reach, especially in a 2D game, but it has at least got me thinking about what types of tools I will need to accomplish anything even remotely close to that. (More on that perhaps later)

Secondarily, I’ve been thinking a bit more about what I want to do about story. What store do I want to tell with the game, and what methods of storytelling are appropriate, both to the style of the game, as well as my limited resources (I am the only one making the game, after all).

I’ve been pretty stumped on this, as I don’t want to resort to JRPG style characters who simply stand around and bark repetitive lines if they’re not involved in a cut-scene. Nor do I really want to put text in the game at all, if I can help it. Luckily, inspiration struck this week when I was watching my girlfriend play through Journey. I had played the game years earlier, but the way in which the game communicates a clear story through entirely non-verbal means struck me.

As with my inspiration from Dark Souls, I don’t necessarily want to emulate Journey’s scope, and I don’t plan on putting cut-scenes in the game. (Or, at the very least, they would be extremely minimal at the start and the end of the game.) In particular though, I’m interested in how the game uses murals hidden throughout the world to communicate a backstory element. So, you may see a similar approach in Taiji, as it’s a good cost-effective and unobtrusive approach.