Heyyyyyy what's up. I made a little puzzle game in a week for a jam and, as of writing, it is one of the most popular out of almost 1,000 games submitted, which has absolutely floored me. I'm not really sure what I'm supposed to do about this, if anything! I figure if about 20 of you have downloaded the source code for this game, then maybe some would be interested in the design decisions I made along the way.

THE CORE DESIGN IDEAS

I've had a general game concept sitting in my back pocket for a while now, which is to use an inventory and equipment system in a strictly logical way, where the player must select a specific loadout to solve whatever challenge lies ahead of them.

It's a pretty flexible concept, and I figured the most elegant way to make this mechanic work in any setting is to give the player an equipment slot for each control they have available, as if the player is rebinding their controls when choosing a loadout. Many games already do this to an extent, but I liked the idea of being able to rebind ALL of your gameplay controls, not just the dedicated action buttons. This would allow the player to sacrifice a core mechanic like "move backward" in order to equip an additional ability.

When presented with the jam theme of "Aberration", this idea came to mind because it is a very mechanical and literal interpretation of things not behaving as they do normally. I already had the concept in mind of having different abilities and only having the UDLR slots available to use them.

I wanted to do something very simple and elegant, and I didn't want to fuss with complex bug-prone systems for rebinding controls like UI for a game jam, so I came up with the idea of putting the different abilities on the playing field itself and having the player assign them by picking them up. This is a lot more fluid and elegant than a "setup and go" kind of game, and also offers a lot more potential for interesting base mechanical interactions.

THE MINUTIA

The first draft of UDLR_Modify was substantially different from the final product. The base interaction of "move right into a token to assign it to your right control" was in place, but you could overwrite a slot that was already filled. The yellow token was the dedicated Push ability, meaning you needed a yellow on a side to be able to push anything on that side.

Eventually I decided that this didn't offer a lot of interesting puzzles without making new token types for new abilities. Since you can overwrite any slot, there is rarely a situation where you don't want to pick up a token without some significant level design contrivances. Locking the slot down when an ability is picked up does two things:

1. More easily allows puzzle designs where the player must be considerate of what tokens they pick up where and in what order
2. Creates further complexity when paired with the mechanic of needing to collect every token before heading to the exit

Locking down a slot when filled then made it obvious to make a locked slot act as the push ability instead of having a dedicated token for it, so the yellow token got a complete redesign. Locking down a slot also introduced the green "empty" token as a way to enable levels with more than only four tokens.

The specific mechanics of the green and yellow tokens were mostly decided on whatever was most interesting, trying to remove any "boring" interactions that would be difficult or uninteresting to put in a puzzle. For example, if you can pick up a green token when that slot is already green, that just deletes the token, and the only reason not to do that is if you need the token later. Green slots pushing green tokens made it so green tokens must be saved for later and introduces more possibilities for puzzle design.

Yellow tokens follow a similar logic. Picking up a yellow token when you already have a yellow token makes a token disappear without changing the player's state, which is boring. Instead, I made it so having a yellow token equipped made you push yellow tokens from any side, which not only got rid of the undesirable "boring" interaction, but was also an interaction unique to that ability, further opening up possibilities for puzzles. I tried to better communicate this interaction by giving the player a yellow aura, which also makes it more clear that having a yellow equipped anywhere changes how the player behaves on all sides.

There is still a "boring" interaction with a yellow token picking up a green token, but I decided that consistency was more important here than being interesting.

I think I could've gone a different direction with yellow tokens, where you could pick up multiple yellow tokens at once, allowing you to effectively multiply the number of tokens being picked up at once. This is potentially a good mechanic that I might explore in a future version of this game.

LEVEL DESIGN

The level design for this game was a matter of trying to explore the mechanics as best I could in a limited number of levels, which was the result of a lot of trial and error. Some levels clearly communicate a particular mechanical interaction and those tended to come together very quickly. Other puzzles are more "crunchy" and require more logic akin to Sokoban rather than the specific mechanics of my game, and these puzzles usually took a much longer time to design and de-cheese.

A lot of folks seem to be enjoying the game despite not making it very far. I think this might just be the nature of a jam puzzle game - I wanted to explore the mechanics as best I could within a limited number of levels so that I could ensure better puzzle quality and not take up too much of players' time, and the end result is that the player is quickly thrown into the deep end and expected to have multiple insights within the same puzzle. I think this is a better standalone game than something easier, but the best version would simply be a longer game that also is structured in a way to make the more difficult levels be more clearly optional.

VISUALS

I've been learning Inkscape recently and decided to use it for all of my graphics, and I think it turned out nice. I couldn't tell you a lot about why I made each thing look the way it does, other than that I spent a bunch of money on an architecture degree and I've built up a decent intuition for making simple geometry look nice.

I decided that presentation for this game was important, as puzzle games can be pretty dry and unengaging otherwise. I figured a lot of the game mechanics and level design out early, and I didn't want to spend my entire development time in the level design mines, so I put a decent amount of time into the audiovisuals. Being a simple and elegant game also helped me here, as there were fewer parts to polish, and therefore less effort required to make the whole thing aesthetically consistent.

CONCLUSION

I want to make a longer version of this game! The positive reception tells me this is something people want to see more of, and I have more ideas on where to take these mechanics. It does mean I need to put some of my other projects on hold, but UDLR_Modify will hopefully let me build an audience and reputation so that those other projects can release to people who are already excited to see what I'm working on.