Periodic Devlog #2

Status Updates

• Demo 2.0 is released, I hope you are enjoying it.

• Gearplexed is registered for Steam’s Next Fest in June.

• The final artwork pass is complete. Some levels got a light touch, others got a complete makeover, and a few levels were completely redone from scratch. The next step is to add Steam Achievements. As of this writing I have 12 achievements in mind, which run the gamut from gimmes to major challenges.

• I’ve narrowed the release date down to a three-week window in late July, and I plan to announce the specific day late June/early July.

Game Design Part 1

I’ve divided this devlog into two parts. Part 1 focuses on the general game design philosophy of Gearplexed, while part 2 will get a little more into the technical side. As I mentioned in the last devlog, there aren’t a lot of gear-based puzzle games out there. That gives it a high score on novelty, but also gives very little reference for where to start with such a game and what features a gear-based game would need to be engaging and fun. Considering that I’ve been dabbling in making factory games for years, it was tempting to go in that direction. But factory games are a beast to make, and being my first public release, I wanted to limit the scope to one game mechanic which is explored thoroughly.

Any game needs goals and progression to make it into a game, otherwise it’s just a sandbox. I remember seeing a snippet about Nintendo’s "WarioWare, Inc.: Mega Microgames!" (2003) on YouTube some time ago and was intrigued by the idea of each screen being a completely different game. The early design of Gearplexed saw each level as a unique gear-based puzzle scenario with what I had termed as a, “one-note story” that would be used to explore different mechanics and playstyles. For example, you might pump water to a town using a specific rotational speed, let a cat out of a castle by operating a rack, keep a vehicle running using randomly generated gears almost like a variant of Tetris, build a micro-factory, etc.

It’s not particularly hard to come up with 10-20 of these scenarios, but coming up with 50-100 such scenarios proved to be a significant creative burden. Not to mention each level would require a major, one-off art project. Early testing with placeholder goals taught me that building the gear trains and getting everything spinning in the right direction and at the right speed was more challenging than expected, but also where all the fun of playing was.

At best, the one-note stories added little more to the game than background noise. At worst, they over-constrained the puzzle design. I distilled the design down to several abstract puzzle styles that retained the spirit and variety of the one-note stories: simple spinner levels, rack puzzles, chest that provide random elements, operate a micro-factory, etc., which are cycled in an 8-level structure.

The story placeholders used in early alpha builds turned into the spinners that are in the final version. I made these spinners visually interesting by using a planetary gear set that serves as both a progress indicator and as a hint for how fast it needs to turn (if relevant), then gave them a nice satisfying completion sound. There are a few exceptions, making an interesting to play puzzle always comes first. Then if there happens to be a little scenario that can be made from it without a huge amount of extra effort, I went for it. However, most of the game remains as abstract puzzles.

What gear ratios to use? How are gear ratios made? How do we prevent the game from turning into math homework? I’ll plan to talk about these design decisions in Game Design Part 2. Thank you for reading!