Zomb-Merge

Here is the link to download and play Zomb-Merge

-----------------------------------------------------------------------------------------------------------------------------

Sprint 7

The one thing that went right was getting the blocks to move when you swiped on the screen and having them merge when two of the same values were swiped into each other. This needed to go the way we were hoping for because the swipe and merge is the main feature of the game and if this didn't work then we would be a disaster. Even having the cube move one space at a time when you swiped would make the game feel clunky and unfun to play, so when I was able to get the swipe and merge working it was almost like getting the hardest thing done first. It made it easy once I got the values all set up because I could then make them a list that anyone in the group could add on to and it was so much easier than adding in a whole bunch of different if statements in the code. This also allowed us to go back and change the color of them later if we wanted to as well as it was made in a way where we could have changed it from the basic cubes to the models of zombies, but we decided against that. 

One of the most frustrating things that was happening during the entire development process was the fact that I was trying to get the cubes to visually slide over slowly so people could more easily see them moving, but this was something that I was unable to do in the second sprint then it just became something I was working on at the end of every sprint on my own time because it was making me so frustrated not being able to figure it out. The main reason why I was trying so hard to do it on my own was to test my problem-solving skills. By the end of the third sprint, it became more of a wish item and the longer I waited and the less important it was to have it in the game the more I would forget about going to office hours and asking for help. In the end, my team decided to settle on a line trail and players didn't seem to have a problem figuring out where the cubes were going, they were leaving feedback saying that they would like to have it, but it isn't changing the fun level of the game. 

Another thing that was giving me issues but I wasn't told until the last day of work before the game was published was when you upgraded the cubes the first time they would start spawning in 4’s and 8’ as opposed to the usual 2’s and 4’s so if you still had any 2’s on the board there was a chance that they would remain there the whole game. I didn't think about it when I was going through and my group had about two days to tell me this, but it wasn't brought up until the last minute, so I tried my best to figure it out, but I was unsuccessful and not wanting to break the game right before publish date I left it as is.

Something that I am proud of is the attack system as a whole. The only part of that system that I didn't do were the animations of how the cities move when you defeat them but the rest of it and the upgrade system were a bit of a challenge. One thing about the attack is that you can either choose to attack or if you run out of open spaces on your board you will auto-attack and lose half the board. Originally you just lost but then the designer decided it would be better if you were able to auto attack but that meant that some of the board had to be wiped for it to not auto attack on repeat. Having the board wiped was the second most difficult part I think because it did not want to work it would either make you lose, or the game would crash and so it took me almost a full day just sitting down figuring that out, but that work paid off.

What I would change if I had to do this development process over aging would be getting a better idea of what we are making and what work we are doing. There were times when two or more people would have such similar cards that they were basically doing the same thing and so we would waste a lot of time because one of our things would just get thrown out because the other did it already and it works a little better. On the other hand, if I was to redo all of it, I would have to keep the mindset we had during the last 3 sprints as I feel as if we were riding high because we were all so excited to finally have published our work we've been doing all semester long.

-----------------------------------------------------------------------------------------------------------------------------

Sprint 6

This sprint was probably the most productive for the whole group and it is cool how much the game has changed in one sprint. Personally, this one was all about getting our upgrade system up and running as this is one of the main features that will be setting us apart from other swipe and merge games. This system was a little different in all of our minds. Hence, it was a little difficult trying to find a starting point as everyone wanted it to function differently, so keeping everyone happy while also making sure it made sense and worked properly. At first, we were going to subtract from your score, but the designer wanted it to be a different resource called brains and not have it overlap with the score. What he wanted was for the brains to go up when you merge but have it been 50% of what you would get for score and then you would use this to have the blocks spawn in with a higher number on them. Ultimately what I did to keep it a little simpler for the players is I made it so they get one brain every time they merge, and they need a certain number of brains, it is set to 25 but it might go up to balance the game out more, to upgrade the new spawning blocks.

Another thing that I did was make it so the horde on screen would visually grow as you upgrade so that you can see that you are getting stronger. The lead started this at the end of the last sprint but whatever he had conflicted with the way the designer and I’s projects were set up as it would break when we tried to use his script but would work perfectly fine for him. He ended up just abandoning it and passed it over to me as he started on something much more difficult but just as important. After I looked at it some more, I was able to figure out the problem and fix it for us, now every time you go to upgrade your horde will also grow. We are hoping this gives the players a sense of growth when they use the upgrade feature.

        Something else that I did was add some sort of visual feedback to the city for when you are attacking as players were getting confused when they would start an attack. How they were confused as they would tap on the attack button and the horde would move over but then there would be a few second breaks before the attack started and then they would get bored during the attack, so what I did was lower the amount of time before the attack then I put a particle effect on the city to show it burning and that you were doing damage.

Lastly, during the sprint, I ended up doing the work too little for it to be given a card but was a definite quality of life change for the game. I went through and added a number to the blocks so that players know the value of them and not just the color. We kept getting feedback from play testers that they knew the blocks were increasing and that they had to match the colors, but they were unsure of what the colors meant so we decided to give them a visual number so that players could more easily know what the blocks were for. I also asked my team if we would want to switch the blocks out for visual models of the zombies but still have a color and number attached to them, all that would change is the fact that they are no longer blocks rather they are zombie models, but my team said that their play testers think that it would be too much and that they liked the blocks.

-----------------------------------------------------------------------------------------------------------------------------

Sprint 5

  During this sprint, my main objective was to get the attack button working and coded properly so that when I handed it off to my team, they could figure out what numbers they might want to insert for the zombie horde damage, health, and city’s health, as well as figure out how long they would like to attack for. I even put headers, tooltips, as well as clamps on some of the numbers so that the team would know how much each value should be. It was a little difficult at first because the game was trying to run the same function three times even though in the code it was only being called once.

Next what I did was get the horde to move over when you pushed the attack button so that you could attack to begin with. Something else that I added to it was to make the health bars move with the horde. It was really good that I did that because how they were placed earlier they did have a possibility to not look right on some of the foldable devices or anything that had a really weird screen size. What would happen is that the health bars would be in this really weird spot on the screen and not above the city and the horde. So what I did was just make the text and health bar a child to the city or zombie horde and it won't break when the actual cities and zombies get added in. I did move a certain timer, and the health bars will not start to move until the zombie horde makes it over to the city, so it looks like they are attacking.

Something else I did for the attack system was to make it so that the player could win or lose during the attack if they do or don't have enough damage. The health bars will also move quicker if the player has significantly faster if their damage is extremely high compared to the health of the city. Messing with all these health bars and how they will look on the screen was cool because I have never done a health bar system, so this was some good practice.

        In the game currently, the damage to the horde is all dependent on how long the attack lasts for I had to make it so that when you attack it stops the timer. This was very important because if I didn't do this then it would keep going and then the player would still lose because the zombie horde health was depleted. Luckily to fix this it was just a simple check that needed to be done and all it had to do was during the attack pay attention to the health of both the city and the horde and stop the attack when the city health was depleted or go to the lose screen if the hordes health is depleted.

We got a few playtests and most of those play testers wanted to see betterer see the block movement and how they are currently moving around the board. What that means for me is I get to try and figure out how to make it so you can visually see them moving rather than just teleporting around. This was something that I was not looking forward to doing because I was struggling earlier. I might end up a little behind on points this sprint just because I am not figuring this out, but I do believe that it will be worth it is what the players want.

-----------------------------------------------------------------------------------------------------------------------------

Sprint 4

  This sprint has been like the others in many ways. For starters, as a group, we have been completing around the same amount of points each sprint. What I did during that time was get the attack started, fix some issues with the UI, and also make it so there is a way to lose in the game. Beginning with the attack system I made it so that every time you merge you get a certain number of damage points added to your damage per second number. After I did that Kyle then took it and plugged it in with his attack button so the player could start an attack on the city they wanted to. In the coming sprints, we will be polishing it up and making sure that it works how the designer thought it would work. At the start, I was not sure what my designer was thinking with how he wanted the damage to be tracked, whether that was taking all the numbers on the board or how I ended up doing it where you get more damage based on how many merges. 

        During the last few playtests, we have not had any UI implemented and that is because the UI was looking different on the phone than the game view in Unity, so What I did was try and figure out why that was happening. I was able to get it working with the different phones and their resolution, so it no longer matters if you are playing on a phone with a high resolution or a low resolution the UI will look the same on both. It was a little difficult to figure it out because I have only ever worked on projects meant for PC and not mobile, so it was just really easy to have those UI fit every resolution as there were only three or four that we had to worry about while mobile has a whole bunch of different resolution screens. For example, my phone has a different resolution than another group member's phone he uses for testing out our game.

        The last thing that I worked on was allowing the player to lose. To do so I had it be that when the player failed the 2048 parts of the game, they would then be met with the lose screen, then I gave it off to a group member so he could then implement the city health that he was working on. After that it was then set to lose when the city still had health by the time the attack finished then you also lost. We might change the 2048 loss to make it auto-attack instead of losing but that is still up for debate within the group.

    The main reason for being against it was because the player must be strategic on how they move the zombies around the board to get more damage so they must pay attention instead of mindlessly swiping the zombies around the board. Another reason to keep it how it currently works is because it is already hard to fail 2048, at least at the lower levels, so if you are struggling that bat at the merging part of the game then maybe you need to lose and restart so that you can get a better understanding of the game. An argument to have us change it to auto-attack is that it could be a good quality of life improvement for the players who are just mindlessly swiping. The majority of the next sprint will be set on finishing the attack feature and also trying to figure out how to get the zombie cubes to animate when swiping. The designer and producer wanted me to figure that out because we were getting a lot of player feedback where they would like to see it animate and not just move super quickly

-----------------------------------------------------------------------------------------------------------------------------

Sprint 3

    During this sprint I worked on a few things, the one that gave me the most trouble was getting the blocks to have a visual when they move. I spent many hours trying to figure out how to get the blocks to have some animation when they move so the player knows which way they are driving. I tried all sorts of different ways but could not figure it out. So, after many failed attempts to get an animation for it I asked my team if they wanted to be able to see them move or if it was okay for me to just put a trail renderer on the objects. My team did say that for now there can be a trail renderer on them but in the future, they would like me to revisit the idea of being able to see the objects move. 

    Something else that I did during the sprint was making the code work to where we can just add as many zombie types to the game as possible, all that needs to be done in the inspector is add in a number and then give that number a color for the square then it is all set. This needed to be done because when the first build was made, I accidentally only had it go to 64 and then when the player would try to merge two 64 blocks the game would then crash. So, I changed how it looks in the code and added more numbers so the player can play for much longer without crashing the game.

    Another thing that was done this sprint was adding in some sort of visual effect for the blocks, so you know when you have merged them. While I was doing it also added the visual effect to all the new blocks that would spawn in, and I was trying to remove it so it would only play on the merge blocks and not the spawn-in blocks, but I was unable to get that to work because of how merging and spawning work. So, I asked my team if they would like me to remove it off of the new blocks that spawn in or if they would like to keep that in the game as well. They ended up liking the idea that they also have an effect when they spawn so the player knows all of the blocks that spawned and merged on the board instead of just the merged blocks.

    At the end of the sprint, I had to build the game and send it to the producer to upload to Google Play so we could have play testers on hardware instead of just software. The game took longer to build than I thought but I was still able to get it to my producer at a reasonable time and then give him enough time to then upload it to Google Play at a reasonable hour. Then towards the end of the sprint after some of the adjustments had been made, I sent a second build to the producer to have him upload just to see what it all looked like on hardware. It's been important to me to have our newest version on hardware as soon as possible because when I am testing in Unity it is very slow and it looks like it isn't smooth, but when it was uploaded to Google Play for the first time, I noticed that the game is smooth on hardware. Now that we have the core gameplay done next sprint, I will be trying to get our attack system up and running as that is our plus one to the core gameplay of 2048.

-----------------------------------------------------------------------------------------------------------------------------

Sprint 2

        During this sprint, I completed the game's swipe, merge, and spawning feature. Some of these features were giving me a bit of a headache. Firstly, the swipe feature was something I had never done before, so I started at first with the new input system and tried that out to see how it worked, but I was ultimately unable to figure it out, so I ended up using the old input system. It still works great, and you can swipe the blocks, which will become zombies later on, around so that you can merge them. The hardest part about the swipe was that they could only swipe one the four-by-four grid and only move in one direction at a time, even if it detected you swiping diagonally. I had to implement a few checks on every swipe so that the blocks know when they can swipe to the next space and whether or not they can merge with the block next to them if there is any. Getting the blocks to move only in one direction at a time was a challenge at the start because I could only get them to move left and right or up and down.

        The spawning, on the other hand, was a little easier because I was able to take the code; I used to spawn in the first two blocks instantly, and then I just put a book on each spawner that would say whether or not a block can spawn on there after a swipe. The check would happen after the swipe had finished. By making the spawn check happen last, I avoided a block spawning on a spot where a block was already at or moving to. Currently, the swipe is set at two blocks for each swipe, but if I need to lower that or raise it, I can do so without worrying about breaking the rest of the code. I can also easily adjust how the spewing works, so if we want to switch it to a button that the player must press, that can also be done without much change needs to be made. It is also set to spawn in the lowest two numbers in the merge sequence, but that can also be adjusted to be the lowest number instead to make it harder for the player to soft lock and lose.

        By far, the most challenging part of this sprint was the merge. This was the most challenging part because, at least with the swipe, when the swiped blocks could go diagonally, it was an easy fix that I did not need help or have to look up. With the merge, however, I was running into quite a few problems. For example, the blocks would sometimes not merge but would go to the following number in the sequence. Then, when I finally fixed that, they would merge, but then the blocks would sit on the square they merged at instead of going to the furthest open square. That was the hardest thing for me to fix because I could not figure out why it was happening, but it did have the most straightforward fix as the problem was an issue in the order the checks and swipes were happening. The code was laid out: they would start moving to the next spot on the grid, then when they found out they could merge, they would, but then they would stop moving to the next spot. All I needed to do to fix it was making it, so they merged after they were all done moving.

-----------------------------------------------------------------------------------------------------------------------------

Sprint 1

     On this game development team, I am the only programmer and so I have a lot of responsibilities. Sadly, I have failed my team during this sprint by not completing most of the work assigned to me. I have no excuses for why I put off all my work, but it happened, and we have talked about it and it won't happen again, and I will try my best to make up for what time was lost during this last sprint. I believe that subconsciously I was stuck and did not know what to do and thought by putting it off I would be easier later, it was not, and I would have no problem finishing. Getting off of that I was able to get one of the most important things done this sprint which was getting the unity project set up and ready for us to create the game on the Google Play Store. Afterwards, I was working on our swipe to move but I was unable to finish the card before the sprint ended so it had to be put off until the next sprint.

    Next sprint what I am doing is finishing the swipe feature as well as making it so that if you swipe two of the same zombies together then they will merge and make the next tier. I have a few ideas on how I will make those things work and also what might be the best option, so it does not just break the game and allow the player to swipe zombies off the map as well as not allow the player to swipe and have two zombies that are not the same merge together. Following that I will be making the zombies spawn in at random after swiping into the empty spots. I am excited to mess with this because having things happen randomly throughout the game or prototype has always been a struggle for me because it never seems to work very well for me. I know nothing in a video game is ever truly random, but it is either I am super unlucky and the change in random behavior or random spawn is always the same or very similar or it just breaks the project, and I have to just scrap the random part.

    Some of the code I was thinking that I might have to do with the merge zombies was either I would have the zombies quickly respawn then spawn in the next tier when merged or I would have a parent object that has the different tiers as children than when the merge happens which child object that is activated would change along with the stars to reflect the zombie getting stronger.

    As a group, we were looking at our Trello board and noticed that we might need to add more cards to the game or maybe try and split the epic cards up a little more to try and make it so we will not finish the game too early. The designer and producer are discussing what could be added and I am giving a few ideas as well as they are asking me if it is possible and how difficult it would be to have that feature added into the game. I am trying to do better, and I am really excited to see how this game will turn out.