A few weeks ago I read this tweet:

In summary:

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

— MOOMANiBE (@MOOMANiBE) June 22, 2017

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

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

So, where do I go from there?

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

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

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

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

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

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

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

•   •   •

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

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

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

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

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

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

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

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

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

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

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

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

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

The 3-Act Structure of Puzzle Sequences

INTRO    >    BUILD-UP  >   CLIMAX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•   •   •

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

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

“Invisible Cities” – Italo Calvino

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

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

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

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

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

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

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.

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.

 

 

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.

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. 🙂

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:

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.

Anyway….

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.

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:

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.

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.

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.