Design SprintS

What Went Right:

• • Implementation - I was able to implement my mechanic with little issues successfully. The experience I gained as a programmer and scripter helped me complete what I set out to do with little complications, allowing me to further tweak and develop my mechanics. I do a good job of breaking down what I want to be done in segments to create a more simplistic design process. In this class, we used Click Up to help with simplifying the design process which made implementation that much smoother.

  • Classmates Mechanics - When developing classmates mechanics had no issues even though in some of their mechanic videos, I felt were missing some pieces to how their mechanics work effectively. Despite that, I was able to implement and develop them with my twist. The first mechanic I chose was the “Patrolling Bot” mechanic and the second was the “Ice Tiles” mechanic. I believed these mechanics would work extremely well with the mechanics I made and improve the flow of the game.

  • Developing Mechanics – I was able to take the mechanics that was given to me and develop them into something more that improved the immersion and flow of each level. With the patrolling bot mechanic, I was able to effectively make a bot that flows in one direction as it was intended but I further developed a different version of the bot where it can move in different directions. For the ice tiles, it was intended for the player to step on a tile and flow in one direction to the end tile, but I made sure to give a back-and-forth motion.

  •  Level Flow – With the mechanics I implemented I was able to map out levels to efficiently utilize certain mechanics and illustrate how they were able to mesh well together and create very good levels. I have always had a programming talent but admittedly I have much to work on in level design. In my approach to designing these levels with my mechanics effectively I decided to approach it the same way I approach scripting, by breaking it down and doing it step by step. First, since the game is tile-based and is effectively a grid much like my storyboard when I used Google Drawing, however, this time I hand-made the levels using a grid and figuring where to appropriately place obstacles and other challenges to create good flow and keep the player entertained.

  • Storyboard – When providing my storyboard and mechanic idea it was beneficial to gather that feedback early on as it helped with getting my mechanic more flushed out when considering the player agency. Initially, my mechanic party tiles were going to be used as a means for the player to progress through the level. However, due to feedback and combat frustration for not getting the appropriate color, I would provide alternative routes to progress through the level that ideally would be harder if they were to get the right party tile color. 

What Went Wrong:

• Too Much Tweaking – I spent a lot of time tweaking mechanics that took 90% of my development time. Whenever I implement a mechanic, I always think about ways to make it better and can’t help but attempt to have that constant improvement. However, when you constantly add new things comes with new problems and then you would have to solve those problems. Therefore, in a way, I took a lot of time from doing additional level design to iterating various mechanics.

• Limited Time – Even though I have done what I set out to do, I would have liked to do more and probably will develop it more as I believe this game has potential, but as for the project itself I wasn’t able to give it my personal touch when considering the art style and feel as intended mostly due to the fact I focused more on implementing and tweaking mechanics but also doing school and working full time 50+ hours a week have been draining but luckily my passion for developing had powered me through even though I felt like I wanted to give it more.

• Collisions – This project, uses a grid system that doesn’t mesh well with collisions; therefore, I spent a lot of time implementing my projectile to attempt to restart the level when it encounters the player. I was unaware of this issue and for some reason, the projectile would restart the level before it encountered the player. I could have used an event designed by the team who created the baseline for this project, however, my projectile did not move in a tile-based way it moved in the direction that the player is currently and that could change at any point. Therefore, I troubleshooted and found that adding the collision event directly to the player had done the job well.

• Crazy Bots – One thing I oversaw was that sometimes the patrolling bots that move in random directions block the players' way when navigating the level. The way the bots are set up is that they move every time the player moves almost like it's turn-based. There have been instances when the bots block an area, and I must move around a few times for them to be out of the way. I need to improve this issue by blocking the area from them to enter but this issue hurt immersion and the levels flow.

• Docile Bots – When initially implementing the bots there had to be specific scenarios for the bots to kill the player where the player and the bot would have to occupy the same space for the player to get eliminated. I wanted more than that I wanted the bots to eliminate the player each time they saw the player in front of them and I knew from previous experience that collisions would not be effective here, so I would have to spend time troubleshooting and ended up using a tile checker that checks whether the player is the tile in front of the bot and if they are they then eliminate him. This works well; however, the check is too slow, and the player can dodge out of the way before the bot even sees that the player is there which wasn’t the direction I was going for.