This week I didn’t really get a chance to work on the game very much. Was busy with some other things (podcasts, getting stuff done for Patreon backers), and I had a major depressive episode. However, I did work on the game a bit today and streamed some designing of a new mechanic. We’ll get to that in a bit, but first I wanted to talk about some of the things I’ve been thinking about through the week whilst not “actually working.”

Interface Options

The interface problem continues to haunt me, so I’ve been thinking about that a lot and I’ve really narrowed it down to three main options:

Option 1

Keep the current interface and just press onwards with all of its problems. I don’t really like this option for obvious reasons. The current interface is super modal and it just feels kinda bad to interact with a discrete tile-based movement system in 2016 (or whenever the game is done). However, all of the game’s design has been done so far using this interaction method, so it naturally requires the least amount of redesigning work to proceed with.

Option 2

Replace everything in the interface with a “player as cursor” type model, where you’re always walking around on the panels to solve them. The primary issue with this method is that it is a bit incongruous with the way some of the puzzles already work (some of which I rather like), and reconciling this problem either requires some kind of ghost player to walk around on panels that the player cannot access and/or requires introducing the ability for the player to walk up on walls. Or both. So, although this is a promising approach, it entails introduction of some new mechanics that I am not sure that I can really capitalize on in any other major ways besides just using it as an interaction method for panels. The walking on walls thing is certainly cool, and plays off the ambiguity of a top-down perspective in a very Escherian way, but again: I’m not really sure I know how to capitalize on that in a good way. I feel like I’m likely to fall into the pit of bad level design that early-era FEZ did. On the other hand, it is an interesting and somewhat potentially mind-bending mechanic, if I can solve those problems.

Option 3

Giving the player a pointer type cursor which can be used at any time. This is a somewhat nice solution because it can probably be done without any sort of modality, just mapping the cursor to the mouse or to the right stick. However, it again is pretty weird in that it feels like you’re controlling two things and you need to mentally switch modes. But it doesn’t have the problems that the always walking on panels method has, in that you don’t always have to be walking on panels, and you don’t have a player shaped cursor that doesn’t really act like the cursor. The cursor looks like a cursor and the player looks like a player. It also has some interesting gameplay implications in that the cursor can be used on any panel that the player can see, even if they cannot get to it. It does however beg the question of the layer 2 type puzzles, as the player will probably expect to be able to interact with tile looking things in the environment. (Admittedly a problem with the other methods as well, but perhaps to a lesser extent?)

So, I’m not sure which of these approaches I really want to choose right now, as I haven’t totally fallen into that sweet spot where everything just clicks and it’s obvious which is the most elegant way to proceed. It may just be that I have to adopt some sort of hybrid approach. In fact, let’s call it:

Option 4

Take the pointer type cursor aspect of Option 3 (We can maybe implement it as a fairy?), and combine it with the walking around aspect of Option 2, so that the player can solve panels that they are walking around on just by walking around and pressing the buttons, without using the cursor. But they do have the option to move the cursor around and activate a panel which they cannot reach. Perhaps the fairy is the thing that bonks its head on the panels to make them do things? Fairies are kinda magical, so maybe this also ties into the storyline aspect of the protagonist having some sort of magical ability to interact with the panels. Also the “oh you have a fairy” sort of calls back to Zelda 64, which is maybe cool. STEAL IT!

Orthogowhatnow?

So, I decided to put together a bit of a prioritized todo list (well, actually I already had one, but I finally took a look at it and struck some of the completed tasks off the list and added more new ones). Although I think that the interface problem is really the most pressing thing, since it affects so many other decisions, I decided to forgo doing any actual work on that and instead implement a new mechanic idea that I had a couple days ago when I was driving into work.

Jonathan Blow and Marc Ten Bosch gave a talk together at IndieCade several years ago called Designing to Reveal the Nature of the Universe (excellent talk, I recommend checking it out), in which they set out a list of aesthetics for game design. I won’t recount the whole list here, but the one that I was thinking about that led me to think of a new mechanic was “Orthogonality.”

If you don’t know what orthogonality even means (which why should you, it’s a long word and ugh math), it technically refers to the general property of two lines forming a right angle, across 2 or more dimensions. However, for the purposes of this discussion, it basically means design concepts which do not overlap with eachother.

A Tale of Two Mechanics

Some mechanical spoilers below.

So, I was trying to think about some other types of symbols to put on panels that might introduce constraints and create more puzzles and interact well with the existing symbols (just the dice faces at the moment). Earlier, I had thought about odd and even, but the issue there I realized is that there is significant overlap with the dice face puzzles. They are both about the total area of a shape. As an example, if you were to have a panel which had 4 symbols on it, each on different tiles: a 4 dice face, a 3 dice face, an odd symbol, and an even symbol. The solution would probably be: oh I need to put the odd symbol with the odd dice face and the even symbol with the even dice face. This observation about the single solution quickly turns into a generality about the puzzles.

This might seem fine, but to further illustrate my point of why this is a bad choice of mechanic, I will posit the following question:

“Are there many situations in which this new mechanic (the odd and even tile constraints) could equivalently be expressed using an existing mechanic (the dice face constraints)?”

I would posit that the answer in this case is yes, which generally means “don’t do it.” I could go into a lot of specific examples of how they are equivalent mechanics, but I will just give one and move on.

If we were to take the following panel, wherein we say that the 0 is required to be part of a lowlit area which is odd and the 1 is required to be part of a lowlit area that is even:

The possible solutions would be as follows:

Although we cannot entirely duplicate the same panel with the same set of solutions, we can cover the bases and achieve very similar results across 3 different dice face panels:

Whose complete solutions are as follows (note that in addition to covering the solutions of the odd/even one, the leftmost panel has two additional solutions due to the way in which dice faces combine with eachother):

“But Matthew!” you say, “look at how many solutions there were for that one odd/even panel, and you’re trying to say that a mechanic which cannot duplicate that solutions space without three separate panels is BETTER?”

To which I would say, “yes.” And the reason being is that sometimes having a tighter solution space is actually a much better thing. And even if you were to disagree with me on that (a fair choice), the argument is really about whether or not to add the odd/even mechanic in addition to the dice faces.

Clearly, I would say, the answer is no.

The New Mechanic

So, while looking for orthogonal concepts, I happened across the idea of having a tile care about the state of its immediate neighbors. This is nice because it has nothing to do with area, and only has to do with the fact that the tiles are on a grid and each tile has up to four neighbors.

So my initial implementation of the mechanic was for each tile to care about how many neighbors it has that are lit up. This is perhaps fine, but it seemed to have two problems.

First, that it was too prescriptive. I tend to avoid puzzles and mechanics that basically feel like I’ve envisioned an exact solution and merely laid down some tiles to enforce that you draw that line or whatever. This has a lot to do with my desire for bottom-up puzzles and things that I have discovered rather than just pulled out of my ass.

Second, I felt like the “is it lit up or not” aspect was an additional point of overlap with the dice faces, which already care about being lit up. It may come to a point where I want to separate out that aspect of the dice faces themselves, but at this point, I’m letting them care about what’s lit up or not, so it seemed like the new mechanic shouldn’t care.

So, what I decided to change the mechanic to is instead an equality check, simply enough each tile cares about how many neighbors it has that are the same as itself. This has the nice property of opening up the solution space a bit more (even though sometimes it’s better to have a narrower solution space, I tend to feel like it is a sweet spot in the middle that I’m aiming for), as well as making the concept fully orthogonal to the dice faces.

Here’s an example of one of the puzzles that we discovered on stream which I particularly like. (I’ll leave the solution as an exercise for the reader. Keep in mind, yellow means “the same as me” and blue
means “not the same”.):