Postmortem Tournamental

Tournamental Postmortem

This month I worked on a tile-based game project called Tournamental in which I created a mechanic and then implemented one of my peer’s mechanics. It was a data-driven game that meant no collisions or physics-based coding which was a major deviation from what I had learned up to this point in my Full Sail journey. The mechanic that I ended up implementing into the game was called Reverse Tiles which reversed player input when they stepped onto the tile, and also I implemented my peer’s mechanic which gave the player a max amount of moves, and then each tile they moved would decrement that number. This allowed for fun puzzle creation on my end and fun yet frustrating gameplay on the players end.

What Went Right!

Mechanic Implementation – Once I came up with the idea of doing reverse tiles for my mechanic, the implementation of the mechanic was a lot of fun and satisfying once I got it working in-game.
Puzzle Creation – Creating the puzzles using both the reverse tiles and the number of moves mechanics was a lot of fun. I enjoyed setting up the “board” with different pathways, different combinations of tiles, and also mapping out each move to see where extra tiles were needed to allow the player to reach the end goal.
Trello Tracking – This month was the first month that we used Trello to track our mechanic progress. It is a great piece of software that when updated and used frequently was a huge help with tracking what needed to be done and how close to completion the mechanic was getting.
Simple Mechanic – This month I chose to create and implement a simple mechanic of just the reversal tiles. By having a simple mechanic, I was able to get the work done and do so in a timely manner.

Material Replacement – Replacing the materials with visually different and meaningful materials was fun and went very well. From replacing bland grey material on the walls with a brick material and making the reverse tiles pop in a level rather than just blend in with the rest of the tiles/walls. Making each tile feel different from other tiles really helps the player know what will happen when stepping on a specific tile.

What Went Wrong!

Blueprint Struggles – It had been 4 months since we had a class that dealt with blueprints, and that was with collision and physics-based coding, and we were learning how to do data-driven code for the game. With not a lot of exposure to data-based games, it was a little bit of a struggle to really get a handhold on what was needed and how to do certain things.
Mechanic: Laser Manipulation – When I started out on this project this month, I was planning on doing a laser manipulation mechanic which would require the player to move and rotate mirrors to direct a laser into a receiver. But with my little knowledge of data-based games, it was a real struggle to stop thinking in physics-based coding and move over to the data-based side of things.
Crunch Time – This month we had 2 separate classes that asked a lot of us in terms of work that needed to be done, and we also had a hurricane come through in the 3rd week of class. With the intense workload and natural disturbances, I wasn’t able to flesh out my mechanic as much as I wanted to. But I did learn that sometimes crunch is necessary to get the work done and that dividing the workload in-between different days can help with the burnout and negate crunch time in the end.
Overthinking – Even though I came up with, created, and implemented a simple mechanic that didn’t stop me from overthinking each piece of code that I wrote. From not understanding how to get the player’s inputs to be reversed to trying to overcomplicate my mechanic with the laser manipulation. Each step of the way helped me learn how to think one issue through at a time, what question am I asking, what am I trying to accomplish, and what information do I need to get that thing done.

Stress – With changing mechanics, two workload-heavy classes, my own overthinking the code, and having to crunch to get the work done, I became really stressed out. Stress was one of my biggest roadblocks this month as once I was stressed about the work I would overthink what I was doing more and more leading to more and more stress. In the end, I have learned that divide and conquer the workload, stop overthinking, and be ok with pivoting from one thing to another if it first doesn’t work out.

Conclusion

Throughout this month I learned how to divide tasks up to get them done in a timely manner to reduce crunch, how to stop overthinking so much when it comes to coding, and also to be ok with a mechanic/feature not working and to pivot to a mechanic/feature that better suits the project. This month was a great growth month for me personally and allowed me to start to think about coding and mechanics in a different way than I had previously. When things go wrong there is a way through whether that be by pivoting to another idea or by just working through the problem until you have solved it.