Blog Post 4 - Zomb-Merge

 Blog Post 4 - Zomb-Merge

My name is Kyle Ramser and I am currently taking Mobile Game Development at CSU - Chico. I have been a part of a team that is working on the mobile game Zomb-Merge, and I am currently acting as the designer on this project. Our team just finished the 4th sprint of our 7 sprint process and had our second digital playtest within the class, allowing our classmates to critique and give feedback on how our game is coming along so far. This sprint was more productive for me than the last one, and I was able to get our +1 design into play, which was my main goal for these past few weeks.

To start off, I will bring up the issues I encountered during this sprint. For a large portion of the sprint, I was blocked on a lot of my cards and was unable to complete my cards such as adding a losing screen, adding a victory and switching cities state, and most importantly adding an attack function to the 2048 style puzzle. Without a scoring system, there was no way for me to add in any lose, win, or attack changes, so I completed my other cards while my programmer finished up the scoring system. While it was unfortunate that I couldn’t do these specific cards during this time, I was able to get the texturing of our main zombies completed and was able to work in a pause function that stopped the game from running once the player opened the menu. I had planned to add the pause menu last sprint, but with complications and a bit of miscommunication with the team, I was unable to add it in, so I was relieved to finally be able to put the pause menu that I had created last sprint to full use, making the button actually pause the functions of the game until the resume button is pressed.

As for the attack, lose, and win conditions, once the scoring system was completed by my programmer, I was able to go into the project and add all of these pieces, which made our game much more complete and finished. Now that I have added all of these, as well as playtested the game repeatedly to make sure that they work, when attempting to battle a city with a lower damage counter than the city’s health, you will be sent to a separate scene with a “you lose” menu, and will be given the option to return to the main menu or try playing again, which will put you in the main menu or game scene respectively. As for the attack function, which is a huge part of our game as a whole, I broke out of my shell a bit and did some programming, and now after a city is defeated, if your total score value is higher than the required city health, the game state changes from city one to two, and then two to three and so on. In adding these booleans and scripting in the ability to battle by hitting the attack button, all we need is to add in the swapping cities animations, which will be queued by these booleans being true or false, and balance the amount of health that each city has so that it is challenging, but not frustrating. I am planning to find these correct values by running multiple playtests with players and figuring out at what point they become bored and at what point they become frustrated. Now that all of the scripting is set up and the variables are public, it will be easy to insert a value that is consistently proven to put the players in a flow state.

So overall, I think that I improved a lot compared to the previous sprints. I was able to break out of my shell as a level designer and dip into a bit of programming, and it ended up working out great. I think that after this sprint our game is in a better position than ever, and not only is it further along, but the scripting and UI that I was able to implement will set the whole team up for an easier job next sprint. I am hoping to take this improvement and momentum into the next sprint, where I plan to implement functioning health bars, switching city animations, and a tutorial menu so that the player can get invested and really enjoy the game.