Over the span of a month, I worked on designing mechanics for a tile-based game named Turnamental. In the initial week, my efforts were dedicated to extensive research on mechanics from other games within the same genre. During this research I aimed to look for ideas that are both fun and unique. After finding a magnetic mechanic in an old flash game, I decided that would make for a fun puzzle mechanic. So for implementation, I crafted a detailed design document to outline the steps needed to implement it into the game.
After I had my mechanic documented, my goal was to implement the chosen mechanic and document the process within a tight one-week timeframe. I had quite a bit to implement for my chosen mechanic. I wanted the player to be able to use their magnet tool to traverse and solve puzzles, I also wanted multiple ways for that magnet to interact with the environment. so I chose to create a magnetic anchor that the player can move towards, or by changing their polarity to launch themselves away from the wall.
As this sprint concluded, I was worked to implement a mechanic devised by a peer within the same condensed week. Where the documentation produced during the previous week served as a valuable reference guide to help implement their mechanics into the game.
Researching A Mechanic: when researching mechanics I knew that I didn’t want to implement mechanics that you see in every game like spikes, moving platforms, crumbling tiles, ice floors, among others. While these mechanics are tried and true in their ability to create fun and interesting puzzles, I wanted to challenge myself and try to find a mechanic that isn’t as prevalent, and create some interesting puzzles from that. I did quite a bit of research, however, when I found the magnetic mechanic, I felt confident that I could create something unique with that mechanic.
Learning Curve Mastery: As I entered the turnamental project there were a lot already established, multiple functions, variables, blueprints, etc. Initially, my first instinct was to treat this like a blank project, so I threw myself into it, trying to cram and force my mechanic into the project. However, that approach quickly proved inane. So early on, I took the time to learn the intricacies of what was already established. And after taking that time, it proved valuable when it came time to implement my mechanic. I had a far better understanding of what I needed to do.
Efficient Implementation of Magnetic Wall Interaction: With that understanding, it made creating the code so much simpler and quicker. Implementing player interactions with the wall, including interactions being blocked by specific tiles, even Implementing Timothy Obenauf’s clone mechanics was quick and painless (however that was mainly thanks to a clear and concise guide). This ease of implementation allowed me to get an early start on some puzzle designs and sound effects.
Time Management: During this endeavor I had anticipated some further time constrictions besides the weekly deadlines. With work and the upcoming holidays being at the forefront of these concerns. However I managed to work out a schedule that allowed me to not only work some extra hours at my job and finish creating gifts for friends and family, but also finish and deliver a project that I am pleased with how it turned out. It was a very tiring schedule not allowing me ample time to rest, however the end justifies the means.
Productive Puzzle Design: Despite my time constraints, I was able to create more puzzles than I had initially planned and showcased. While designing them I went with the approach of testing how each mechanic interacted with the other mechanics (this also helped with finding any bugs). Once I found some interactions that seemed interesting I crafted puzzles to explore it. Designing these puzzles was probably my favorite part of this project.
Gate Animation Challenges: The implementation of the gate's open and close animation presented some challenges that I haven't encountered before. This bug occuring when the player jumped on and off the pressure plate in rapid succession. The way that it had been implemented, from my peer’s guidelines, allowed two timelines to conflict and fight over where the gate ended up. Typically ending with the gate floating above or below the level. When I attempted to fix this bug, nothing seemed to work. I attempted countless iterations involving one timeline, two, and none at all. Fortunately I did end up devising a solution (which is what’s showcased in the driver sprint’s video). however the need for multiple iterations and debugging consumed a significant portion of my time, impacting the inclusion of multiple aesthetic features.
Scope Creep: Unfortunately, due to over ambition when it comes to the mechanic as a whole and some unforeseen time constraints created by the gate animation bugs, several aesthetic features, including environmental assets, player tool remodeling, and better sound effects, had to be cut from being implemented. While they are smaller cuts, their absence was a compromise to better fit the time allotted.
Code Optimization Opportunities Missed: In my future projects I would like to improve on how I write my code. The vast majority in this project was unoptimized, and in retrospect I see where I went wrong. I used a lot of repetitive code that should have been its own function that utilized while loops. The code in its current state is downright ugly, hard to read, and tedious to code. So from this point on I am going to try harder to optimize my code while implementing mechanics. So that if anybody needs to read it, it’s well organized and easy to follow.
Creating a very limiting mechanic: while I am happy with how my mechanic turned out, and would love to elaborate on its design further. I do feel that, as far as puzzle design goes, I chose a very limiting mechanic. I found it to be quite challenging to create puzzles solely relying on my mechanic. I feel that a mechanic should be versatile and multifunctional. However, for the majority of my puzzles I found myself relying on other mechanics more than my own.
Mismatched Mechanics: After the navigator sprint I had to choose a mechanic that one of my peers designed. I chose the Clone mechanic designed by Timothy Obenauf, and while it was designed very well and a great mechanic. I don’t feel that it paired perfectly with my mechanic. I ended up using portions of my mechanic to iterate on Mr.Obenauf’s design, leading to what was essentially a portable magnetic wall. I feel that I could have chosen a more suitable mechanic to pair with my own in order to reduce any unnecessary iterations or retractions from the original designs.
In the month-long journey with Turnamental, I learned a lot from both successes and challenges. Learning from the established blueprints and functions was a learning curve, but taking time to understand them paid off during the implementation of the mechanics. Efficient time management allowed me to meet deadlines despite work and holiday commitments, resulting in a project I'm pleased with. Looking ahead, I've learned the importance of code optimization and the need for versatile mechanics. The mismatched pairing of mechanics also taught me to choose based on function. In summary, Turnamental was a journey of growth, creativity, and valuable lessons that will shape my approach to future endeavors.