TL;DR:

  • Made a generic puzzle system that combines scrolls/spells

  • Found out that all other (non-combat) systems can be replaced with that system

  • Reduced code size by a lot

  • Getting closer to all the systems being feature complete, and therefor to testing!

This week I want to focus on some improvements on one of the final systems that the player gets to interact with. Funnily enough, this system turned out to be so generic, that its gonna replace all of the other non-combat systems reducing code!

I’m gonna go ahead and say it: I’ve never designed puzzles. Puzzles are hard to quantify for me yet, since I haven’t spent a lot of time working on them or understanding what makes a good puzzle. Because of this skill limitation I wanted to tackle this problem from another direction. Turns out, the spell & scroll system that I have is enough of a puzzle for the players by themselves (based on player testing). Finding another puzzle mechanic would also cost a lot of code space, which I don’t have.

Then I remembered about Rube Goldberg machines. You know, the ones you see on Youtube? It’s basically a long string of cause and effect that bring small interactions together into a big chain of events. These machines are interesting to watch, because it’s not immediately clear to what is going to happen or what is going to be the effect of some part of the machine. And here’s where I found out a cheap alternative to puzzles: Make a bunch of Rube Goldberg machines, but just with pieces missing!

  • I can dynamically remove scrolls from a puzzle to the scrolls that the player already has

  • The player can learn new spell combinations through solving a puzzle

  • It brings another layer to the spells that the player has in their inventory

One of the first things that came to my mind, is that I can use the PICO8’s still empty Map Editor to make these machines. Technically, I have all of the sprites as a single tile, meaning I could put them into this map editor and interpret them in code later. This means that I didn’t have to give up more space in the form of data on the code side, keeping this system relatively lean for the amount of content it will give to the game.

The next thing was about making the puzzle “resolve” or “work”. I decided on using a thing called “movers”. For now they’re just arrows pointing in 2D directions (Up, Down, Left, Right) that push an adjacent piece to that direction. This would cause certain scrolls to overlap and them to combine, using the already available combo system.

Once these movers get close to a “Magic” scroll, it resolves. Behind this magic spell, there’s always another spell to represent what your spell should become, to give a player a hint to what the puzzle should resolve to. Also, the magic scroll doesn’t effect the scroll combination, but actuates a spell like it does in normal combat. During the puzzle, it has a similar goal. When a mover encounters a magic spell, it deletes the mover. Once all movers are removed, I check if all of the remaining scrolls are in pairs. And if so, you’ve solved the puzzle!

The next step is just making a lot of these and adding a lot of different directions and other tricks to keep the player on their toes! I’m not sure what constraints I’ll give to the puzzles, maybe I’ll add a time limit. Perhaps I just give the player a 1 time chance to solve it, meaning if you fail, you don’t get a reward. But I’ll get to that with polishing and balancing the gameplay!

As soon as I got the movers into the puzzle system, I noticed something: the puzzle system was a seemingly complete version of a spell combining system. But up until this point I had used custom systems (that take up a lot of code) for the crafting and story systems. If I make a custom puzzle for both crafting (meaning max 2 spells) and story (meaning put any spell without knowing what it should resolve to) I can reuse the puzzle system for those systems as well, I just need to evaluate the results differently! For crafting, whatever the result is of the two spells, you just get as a new spell while removing the two parts. And for the story, I just check the result with the desired story outcome! The result is that I can delete a lot of code that was unnecessarily complex!

Another thing I figured out, is that if the spell system gets too big, I can always choose to make the spells resolve through the Map Editor as well. Since every scroll is just a result of another pair of scrolls. I could just make groups of 3 scrolls/elements in the Map Editor, make a piece of code that looks for the pair in the map editor and reads the 3rd element as the outcome! I don’t have the need to implement this yet, but if the need arises, this could save a lot of code space for the spell/scroll system!

I still have to perfect a lot of parts about the puzzle system as well as the other sub systems in the game, so we’re still relatively far away from a public build.

I’ve decided I wanted to make a little deadline for myself, so as of this post I’ll try to get a playable build ready for Mid April! And with that I want to thank all of the ~1400 views on the TIGSource post as well as the 50 followers on Twitter. If you’re not already following, I’d really appreciate if you do, it helps out a bunch for the project in the long run. Also, if you’re a regular on this post, please leave a comment to let me know what you think! Do you guys prefer the general overlook format of these posts? Would you guys prefer a technical deep dive? What should my next post be about? Let me know!

Anyways, thanks you so much for taking the time to read this post!

~ Bram