In this blog post, I’ll talk about the design & creation process for Machine at the Heart of the World as well as a short post-mortem. It contains spoilers about the game mechanics and uncovering game mechanics yourself is a huge part of the gameplay so if you have not played the game yet I strongly suggest you to do it first.

Just for a quick introduction, in this game, you are presented with a field of glyphs which you read/parse left to right, row by row and build a set of actions from them. Actions are eight directional arrows (which correspond to keys QWE AD ZXC) and center action (key S). As you read the glyphs you calculate a certain number followed by an action which denotes how many times that action will appear in the final result.

Basically a game about transforming an input (glyphs) into output (actions).

Designing gameplay & rules

When, by random chance, I saw on Itch.io that MonoGame jam is about to start in a week I immediately knew what game I wanted to make. The idea for the gameplay used in Machine at the Heart of the World was with me for over a year, ever since I was making a very peculiar pair of levels in a certain brilliant puzzle game (DROD). I actually even had a prototype build there, except it used different, far more complex rules.

In one aspect the game was closely inspired by The Witness – its approach to tutorialization, though I became loose on that rule near the end not wantint to alienate most of the player base (more on that in the post-mortem section). The core of the gameplay was meant to be experimentation and educated guessing from the get-go and that part worked really well for the most part. The rules were designed so that the playfield is stateless (with an exception of the bomb which was not used in the final version) which created some problems for at least a few players in terms of expectations.

Designing setting & story

The style was a joint effort between me, Alex (Cage) and AceMan – Jack of Shadows was an inspiration to me and I knew immediately that the action will take somewhere at the center of the world. The actual machine the player interacted with initially was meant to be steam punkish, a lot of brass and cogs, but then AceMan suggested something ancient in stone, Alex found the below image and, ultimately, we got the current style which uses brass, stone and glass. We also talked a little bit about references to some specific civilizations and cultures but, ultimately, only the numbers were taken from various non-European scripts.

As for the story, like I mentioned before Roger Zelazny’s Jack of Shadows was an inspiration here. I am a huge fan of his work (Amber chronicles are one of my most beloved series and I find Lord of Light to be a masterpiece) but that one short story had a lot of great ideas that just immediately clicked with the project in my head. The game’s title is directly from it; the world that does not rotate; descending to the machine to change how the world works; the murdered man mentioned in the intro is the man Jack kills in the book.

Coming up with why the world has stopped and what are the consequences was the biggest problem for me because with my writing I always strive for complete internal consistency and having a good explanation for everything, even if that explanation is only in my head. In this case, though, I didn’t have the luxury of time nor of space to bring out a scientific theory of the stopped world, so with pains I just handwaved it.

Handwaving is very important in writing.

Designing the ending

I like it when games step out of their own medium even if just a little – Undertale and Doki Doki Literature Club are the reasons the game reaches a locked state at the end. As for the “twist”? Really, you should’ve seen it coming. I’m not going to go into more details about what and why because most of it is obvious and the rest is unimportant. And if it’s not obvious then, well, either you didn’t pay enough attention or I overestimated my abilities to present a minimalist story.

Additionally, I allowed myself to end the game like that mostly because it’s a jam game, there isn’t a better time to experiment!

How much time did we spend on it?

I’d say I spent between 30 and 40 hours on the project, most of it being the weekend before the deadline and the opening Sunday. On Saturday I worked till about 4 AM, on final Sunday till about 1:30 AM after which I woke up at 5 AM to work. During the week I spent maybe 2 hours each day due to having to help my wife with the kid. The art took about 3 days to make and I don’t really know about the rest of the team – we worked remotely.

Now let’s take a more critical look at the game, shall we?

Post-mortem

I am very happy with how the game turned out. A couple of people have managed to finish the game by themselves and everyone generally praised it with one person saying they’d even buy it.

Level design

With that said, I have a couple of issues with the level design which was probably the least polished part of the project despite being the heart of it. As an example, a lot of people have tripped on the first big level which has a structure like that

    1 2 3 * 8
    - 4 - 4 1

To solve it correctly, you sum all of the numbers on both sides of a mathematical operator before applying it, ie in this case (1 + 2 + 3) * (8 – 4 – 4 + 1). But while the game attempts to teach you that there are three problems:

1. this rule is not reinforced enough times;
2. the times when it is taught can be interpreted differently and that’s the first time you encounter it again;
3. the line break after 8 sends a message to a player that the following glyphs should be summed separately, or at least it’s easy to think that.

Another problem is the chameleon glyphs (aka eyes) and the parentheses – they have simple rules but they are not taught well enough. At the point I was making them (about 2-3 hours before I submitted the game) I was already tired and just wanted to get it done. The levels are thus showing too many rules at a time without really reinforcing any of them.

This shows how important testing is – I am sure if I had someone to play the game I’d immediately see those problems (and so would they). Then fixing them would be a matter of minutes.

Another issue is how the levels are actually built, due to time constraints I didn’t make a level editor and instead opted for writing them as strings:

    // Negation exam
    new ScreenData(
        EngineTilesUnserializer.UnserializeScreen(
            "65"
            + "d8 d4 o! d4 o! d2"
            + "o! o* d1 d1 o* d8"
            + "o! d4 o! d4 d1 a4"
            + "o! d2 o* d4 o* o!"
            + "d1 o- d4 a3 o! a5"
        )
    ),

It made it tedious and annoying to make them so I usually had to start with a pretty solid idea of what I want to make. Later I limited myself to minimal changes.

One final struggle was balancing difficulty. How many times the same rule has to be reinforced in different ways to make sure everyone understands it? And how many repeats is too many for those who figure things out faster? I tried to strike a balance in most sections of the game between those two but, ultimately and unfortunately, I opted to make things too demanding in the final stretch.

Chameleon glyph misunderstandings

A lot of people were confused about the way chameleon glyph works. Just to give you background, this is a glyph which kinda looks like an eye and looks in one of eight directions. When parsing it you just take the value of the glyph it is looking at – and that’s the problem. The most intuitive thing for many people (and I am not saying they are incorrect) is that a chameleon looking at another chameleon takes the form of whatever that chameleon is looking at. That is, if A looks at B and B looks at C, A should become C.

But that’s now how the rules work and there are two reasons: stateless board and more interesting gameplay.

By stateless board, I mean that everything is exactly what it is when you look at it, and the only thing you need to keep in mind is the “stack” of things in your head when you are reading the glyphs. You need to know the current sum of numbers, whether you’re in the middle of negation/inversion and so on – this makes the state of the game. The rest is exactly as you see. Imagine an ignore glyph followed by number 4. When a chameleon looks at the number it doesn’t matter that it is preceded by ignore, because the only state that matters is what you see. Similarly, chameleon takes the form of another chameleon instead of whatever it looks at. The whole game is built upon this rule (with two exceptions I’ll cover next).

The other thing is this makes for a far more complex and interesting rule, as otherwise a chain of chameleons could just be replaced by whatever the last one is looking at and that’s it. Nothing else to think about. That’s why I am still happy with how this element works.

Parentheses issues

Parentheses are a pair of glyphs which we’ll codename Left and Right. Whenever Right is encountered for the first time, move back to the closest Left and continue reading the script from there. Then, when reading previously activated Right, just skip it.

The mechanics are pretty powerful, giving a lot of interesting interactions with other elements and add reasonable complexity but they break the statelessness that I’ve mentioned above. In retrospect I find this to be a failure in the design together with how poorly they are introduced.

I also made a huge mistake of comparing them to parentheses in the in-game text which immediately gives you a wrong context and set of assumptions.

The bombs

There is one element that was coded and had artwork but was not included in the game – bombs. So as you read the glyphs, the moment you encounter a bomb the state of the field would change, the bomb and up to 8 glyphs directly around it would be removed.

It has a lot of puzzle potential but increases the complexity by an order of magnitude and just throws the stateless nature of the game out the window. Yuck. But it could create some pretty awesome scenarios. There is also another reason they didn’t make it into the game.

Puzzle size

Initially, I wanted the puzzles to be up to 9×9 and the glyphs would scale down in bigger stages. This made things too small so I settled down on the 6×5 the game has right now which, coincidentally, made the bombs much harder to include effectively in a puzzle.

I think it was a good decision for the jam, but if I were to ever turn this into a bigger project it’s way too small. The original plan in my DROD hold which held the prototype was for the game to consist of small puzzles which teach you rules and one humongous puzzle that requires pen and paper to solve that is an exam of all the rules introduced. And that’s the direction I’d rather take the game in the future.

Some closing thoughts

I admit I was really afraid no one will like the gameplay at all. I was worried no one will enjoy a game where you have to experiment with the rules to figure them out without guidance (and no feedback like in The Witness). But I was wrong~!

Speaking of The Witness someone has said about this game something like this: “games which copy The Witness make the mistake of not providing the feedback on what is wrong” – and I don’t disagree, to an extent. The difference is this game is about translating input into output, while input is about providing input that is then validated by various rules. This fundamental difference makes it possible for it to have a feedback mechanism which doesn’t trivialize the game.

But in Machine you can’t have this, the best you could do is just provide a diff between your output and expected output but then it turns into a game of “input anything then copy the expected solution”. Far from being an engaging experience.

And that’s all I have to say about this game. My final thought is – if your scope is sufficiently small and well defined a tiny team can create a pretty polished product in a surprisingly small amount of time.

References

1. Antikythera mechanism photo from Wikipedia.