Postmortem
Gushing Gators was definitely a strange experience, both because the class was forgotten within all the revamps going on in the major and because we weren't really taught android development on Unity at all. If I were to describe it as plain as possible, it is where we come to class two days a week to learn about game development off a google doc presented to us while we spend our time at home working on the mobile game and various assignments based off the in-class documents. Even though the process of making a proper mobile game was way different than the things we were actually learning in class, I believe our game, for the most part, turned out to be a cool little game that wouldn't be bad to show off on the CADG company website.
 |
| Level 7 which I created for the game |
For the things that went right for me, I believe that I was able to get my portion of the work done and more. I originally was tasked to make the grid system work on my side, so I made both the walls and tiles customizable, some breakable, keys + locks, hazardous liquid functionality, pause system, freezing functionality (when you are dragging a tile), and the win / lose condition. I also took it upon my self to make all the player UI work, so this would include buttons in the pause / condition menus (resume, next level, main menu, etc.) and the level selection screen layout + functionality.
As for what went wrong for me, I think the hardest thing for me in this project was the motivation. Being a group of four, we unfortunately did not have the manpower you would expect from a team of this size, especially since we were originally only supposed to form teams of 3. I was able to slightly mitigate this issue by working with my producer. However, one thing that I know that will prevent this issue in the future is by cutting the roots of this problem by addressing them at the start. This way, we could start off the project with a realistic scope of what we are able to accomplish with what we have, rather then guess and try to reach for something that we most likely won't be able to get close to.
For the things that went right for the team, we were able to communicate for the most part. We all were able to understand the tasks assigned / split between us, and we were able to communicate whenever we had a group assignment due that not all of us had to work on. Another thing that I would like to expand upon was how I was able to work with my producer to get work done. We had to make up for the lack of work being done in the group, so my producer and I took it upon ourselves to assign ourselves more cards of higher priority, while we assigned the others lesser tasks that wouldn't slow down or block the development of the priority features of the game. This turned out to be a big success, especially since this was a problem that arose during the early sprints where we had to get the liquid working with the grid system. After implementing this strategy of assigning more important tasks to us two while assigning the others minor tasks, we were able to work towards where we are at today, which is a functional game with most of the features we set out to complete on this project.
As for what went wrong for the team, we basically had group members that just did not push out the work expected of them. To deal with this during our development, my producer and I made sure to only be working on priority features and bug fixing to ensure our development speeds were as efficient as possible.
The main thing that I want to do differently the next time I create a match - 3 system in any game is definitely build the system to be customizable from the start. While developing, I realized that randomly generated grids and system-generated grids were not at all what my designer imagined when creating levels. Instead, I should have detected blocks / tiles placed in the scene and added them to the system. This would have also made level creation so much easier because to create levels in what I have created, you have to create elements in arrays and edit their values on the inspector (which is not intuitive at all because you only see numbers, not the actual game itself).
 |
| Edit values for level 7, showcasing the chaotic mess that is the level creation |
Overall, this project has been a rough experience but I have learned a lot. I've learned now what it is like to work with heavier workloads, and I definitely feel like I am ready to start working in CADG 470 and 495, where workloads are supposedly even more challenging.
Blog Post 6
For this Sprint, I added some features here and there but mainly focused on getting all the features in the game up and working. I did not make a level editor for my designer, but instead settled for a way to edit the walls instead so that we could all make levels at a slightly slower pace.
For the walls, I made three arrays that represented the left, right, and bottom walls. The reason why I made the bottom editable was so that we are able to make space for the pipes to gather all the gator-rade. Anyways, the x values in these arrays are which wall tile is being edited, so the left and right walls would represent the y position of the wall, while the bottom wall would represent the x position from left to right. The y values in these arrays are the type of wall they will turn into on wall generation. These values are represented alone:
 |
| Number associated for the type of wall. |
The fan and locked types are self explanatory as they represent their respective names, but I will explain the wall, blank and brown types. I left blank as 0 since it is the default starting value when creating an element in the array so it is easier to just create a wall, and leave it as is and move to the next element. -1 is for walls because it is the only negative number in the wall type list, so it is easier to just check if an element is negative or doesn't exist when generating walls normally. The brown walls are the brown background tiles, which give a nice look when hooked up to the end pipes.
 |
| Arrays for the left, right, and bottom walls |
The other feature I implemented this sprint was the key and lock instances. The locks are lock blocks which are destroyed when a key is touched by water. Keys can be destroyed by bombs, and are picked up when touched by gator-rade. We decided to keep the feature of having keys destroyed by bombs because it forces the player to make smarter decisions with the bombs, rather than just simply breaking a line of tiles down with it.
 |
| Lock block disappearing when keys are touched by the liquids |
I also improved the fans in the game. Before the changes, the fans were able to affect all liquids through walls and had always affected the entire line it was on. I have now added a raycast system that checks for how far the fan can see before getting blocked by tiles, and changes it's hitbox accordingly. Some playtesters also said that since the game was in orthographic view, they couldn't tell that the fans were fans, so my producer went ahead and made particles. So I went ahead and made the particle's area of effect also represent how far the fan's hitbox goes, and we had a lot of positive feedback for that.
 |
| Fan particles representing area of effect and updating when tiles are broken |
One bug that we faced however was that sometimes the fan hitbox wouldn't update when blocks next to it were cleared in a vertical fashion. I have not been able to identify the issue, because the raycasts are called after the blocks have been deleted and updated in the tile array.
Lastly, I made a level using the new wall generation system I implemented to make sure it was usable for my designers. I added the new key and lock features, as well as the fans with the new and improved particle and hitbox system. I also made sure you were able to change the amount of moves and bombs you were able to utilize, and it worked out pretty well! One thing I wanted to showcase in this level was how to strategize the usage of bombs, as I wanted the bombs to be used for either getting the key or for opening up the end area of the level. Overall, this sprint went pretty smoothly, and it was fun working with my producer to get the main gears of the game finally running!
 |
| Level 5 layout |
Blog Post 5
In Sprint 5, we had a mini playtest where we mainly just tested for button functionality and appearance. The main feature I worked on was the bomb powerup as well as the automatic wall generation, which I am blocked on and will explain.
As for how the bomb powerup works, it is a button located on the bottom left of the screen. The text shows what type of powerup it is, as well as how many uses are left of that powerup. For the bomb powerup, players are allowed to drag the bomb from the bomb button onto any tile on the grid besides the wall or blocked tiles. By placing down the bomb onto the grid and onto a valid block, the bomb breaks all breakable blocks in a cross shape in its place. So the affected blocks would be the tile it is placed on, as well as one block from each direction (up, down, left, right).
 |
| Bomb powerup in action |
I took a lot of time for this powerup because I wanted to create a framework to be able to support more powerups in the future. To do this, I decided to use a delegate system to be able to handle multiple different powerup buttons. I also decided to keep all of the powerup system because of two main reasons: to make it easier for my level designers to change the powerup values in one place, and to reuse code / functions within the same script. As for the second reason, I assumed that we could add more bomb-like powerups that destroyed blocks, so it would be easy to reshape the bomb function as needed.
Also during the beginning of the sprint, I experimented with the auto-generation of walls. I completed the task up until I came to the part where I had to choose which part of the bottom section of the walls to keep empty. The first thing that came to mind was to add a separate array to track which part of the bottom side of the walls should be left out during the wall generation. It would not be hard to implement, but the problem was that there would be too many things for my level designers to look at while tweaking the values, which is especially tedious since the mobile simulator on Unity 2022.3.7f requires you to continuously swap back and forth between the computer and mobile simulator. There was also the fact that I would have to include a way for the bathtub to be generated, so in the end I decided to mark the task as blocked until I started working on the level editor for the other developers on my team.
 |
| Circle represents the bottom row, which needs to be customizable so that the designers can choose where to add holes to the bottom. |
One last major feature I worked on was the addition of the fan hazard, which pushes liquids towards the direction it is facing. The distance and power is adjustable, and the direction is based off of the rotation of the fan object. The fan can go through walls, so in the future I or someone else will have to work with raycasts in order to detect if any blocks are in front of area of effect. There are also no visual effects to showcase the area of effect, so that is also something we can implement in the future.
 |
| Fan located on the left side of the wall, pushes through solid blocks however. |
For the next sprint, I plan to finally start working on the level editor. Now that we have the main features of the game up and running, all that is left is to add more levels in the game to showcase all the mechanics our game has to offer. And to add more levels more efficiently, we need a level editor however late it may be.
Blog Post 4
In Sprint 4, I was able to get the general menus down as well as the liquid system finalized. Our team's progress was stalled due to FPS lag with Unity as well as it's emulator not working properly, but we were able to pump out some work nonetheless.
For the liquid system, I was able to get both the Peak and Powerade up and running. These liquid systems were designed to be able to switch to any of the three liquids, Gator-rade, Powerade, and Peak. They also change their game-object tags accordingly, and continuously check to see if any other liquid is touching it currently to ensure responsive liquid behaviors. Currently, both the hazardous liquids Peak and Powerade can only interact with Gatorade, but I might also make it interact with each other because I think it can make an interesting feature for our level designs.
Peak, represented by the black balls, is a hazardous liquid that converts Gator-rade into itself. I've also added an extra feature, to the request of my designer, to make sure that it has a 1 second delay before activating. This is to make sure that when a group of Gator-rade touches it, it doesn't convert the entire group to it immediately and instead steadily takes over all touching substances.
 |
| Peak converting all Gator-rade it touches |
Powerade, represented by the blue balls, are also hazardous liquids that deletes both the Gator-rade and itself once in contact of one another. There is currently a bug where if the Powerade is sitting on top of another Powerade that has been deleted, it does not drop and stay suspended in air. I have tried making sure that the gravity and collisions have all been properly toggled on / off, and was not able to solve the issue. The way I decided to work around it is by making sure Powerade instances do not stack on top of each other so that this situation can be avoided altogether.
 |
| Powerade deleting Gator-rade |
As for the menus, I worked on getting the level select, main menu, pause menu, and win menu all up and running.
The first thing I worked on was the main menu and level select. The main menu basically has a bunch of canvases which can all be turned on / off to show which ever screen the player wants to see. For example, if the player wanted to see the level select screen, the script would hide the main menu screen and show the level select screen. For now, the main menu has four buttons, a play button to get sent to the first level, level select for the level selection screen, help button for learning controls and objectives, and the quit button to leave the app.
 |
| Main Menu (for now) |
 |
| Level Select |
The last thing I worked on for this Sprint was the pause button in the game. I added a restart, resume, and main menu button for the game. Basically, pressing the pause button would freeze all functionality in the game as well as store the velocities of the balls so that they could continue falling as they were before the game was frozen. However, I found that spamming the pause button and unpausing would break this behavior and send the balls flying way faster than they should be. This also happens with the restart button sometimes if you click really fast, but I think I may have extra lines of code that do not really need to be there.
As for what is next, I am planning on working on power-ups as well as a level editor to make it easier for my designers to make levels.
 |
| Pause Menu |
Blog Post 3
Sprint 3 was a somewhat chaotic week, with the playtest happening in the middle as well as me getting really sick towards the end. This meant our sprint went well during the beginning, yet fell off a bit towards the end.
In this sprint, I was able to get more of the game system up and going, including the addition of a win condition, touch + mouse controls, pausing of the liquids, and restart system. I have also started working on the menu system so the player can navigate throughout the game, as well as adding liquid hazards to the game.
For the touch controls, I wanted to be able to make it usable for both mouse and touchscreen because I personally do not own an android. So by adding mouse input, I would be able to test mechanics comfortably on my PC before running more tedious tests on mobile devices. To do this, I used Unity's built in input system since it supported both touch controls and hooked it up to my old drag handling script. Since I could add both touch and mouse controls under the context of an action, such as "Press", it made implementing both controls into my code very smooth.
For the win condition, I basically made a U-shaped tub and added a box collider for the hitbox, which listened for whenever gator-rade was collected. I then set up a 'GameManager' system to keep track of all the balls on the screen, including ones that would be shot out by a gator-rade spewer. The denominator of the score would be the minimum number of gator-rade needed to reach the next level and win the game
 |
| Score getting registered when gator-rade (the balls) are collected |
Additionally, I created a system for freezing all the liquids on the screen whenever the player is dragging a tile. This is so that players can strategize which blocks need to be broken in order for liquid to flow into the right spots. I also have reused part of the code to create the restart system, storing the initial position of the liquids so that they can return to them when the level is restarted. I again plan to reuse this code when creating the pause menu in the next upcoming sprint.
 |
| Restart button as well as liquid freezing on drag |
One last little neat thing that I created before the end of the sprint was the addition of seeing the result of a swap before it goes off. This is so that players have a better idea and visualization of what will result of a swap before finalizing their move. This will become especially important when the game starts to limit the player's moves.
 |
| (Tiles switch positions before finalizing the move) |
One thing I am currently working on for the next sprint are the liquid hazards. Our team plans to implement Peak and Powerade, which each perform different things when interacting with gator-rade.
Currently, I only have the ability to switch the type of liquid to others, shown here by this GIF.
 |
| Gatorade (Yellow), Peak (Black), Powerade (blue) |
Peak, the black liquid ball, is supposed to delete both the gator-rade instance and the peak instance itself. Powerade, the blue liquid, is supposed to convert gator-rade to another instance of Powerade. Essentially, both these liquids can cause the player to lose so the player must route around them as much as they can.
Once I complete their interactions and ensure they work properly, I will begin working on the overall UI system of the game so that the player can navigate around in the game as well as receive feedback when they lose or win.
Blog Post 2
In Sprint 2, I was able to get the match-3 system fully functioning according to my designer's and producer's vision and started working on some features that will serve us during the playtest. It was a very busy week, and it definitely caught me off guard especially with how early we are in the semester. But I am slightly happy I was able to output what I was able to get done.
One of the main things I started working on was the manual placement of the blocks. Initially, these were for immovable or uninterruptable blocks, which serve as walls that block off certain points or chokeholds. I got the system up and running relatively quickly, and made sure it was suitable for the designer to use. Here you can see me tweak around with the immovable block locations and that it works during the tile grid generation:
 |
| Immovable blocks, shown by the grey coloring |
Later down the sprint, this also helped in adding dedicated tiles, or manually generated tiles. We decided as a team that we needed this feature because our grid generation was completely random, and that this would serve as a quick workaround for soft-locking in this upcoming playtest. To implement this feature, I converted the 'IMMOVABLE_TILES' list array to 'DESIGNATED_TILES' in order to support all manually generated blocks. The x and y values would be the position of the desired tile while the z value would act as the tile type.
 |
| How my designer would manually generate tiles in a level |
 |
| Tile Types for the 'z' value |
Another quick thing I did was implement the tiles that my modeler made in the game. It gave a sense of why setting the pivot points of objects were important for modelers because I had to tweak some values manually, which was a tedious process despite how quick it took.
I also had to tweak the match-3 system in order for it to only match in rows / columns instead of all connected tiles. The reasoning for this is because my designers and I decided that being able to break too many blocks would be problematic in situations with huge chains of tiles. With giant chains, players could unintentionally break open pathways that potentially don't want to be opened, so we decided this little feature will benefit the game going forward.
Some things I plan to work on next is seeing tiles swap in real time before the actual swap to help visualize impact, adding a win condition, and combining this match 3 system with the actual water physics.
A huge problem this Sprint was lack of time management from both me and my team members. We all had projects that we had to catch up on last second, which meant that we took a lot of the time we would usually spend on this class to work on our other projects. It was a tough wakeup call to see how little progress we had actually gotten this sprint, even though we were all so fired up at the beginning. As a programmer, I have experienced this type of situation where if one side of the group falls behind, the rest of the group also starts falling behind. I definitely will have to start stepping up to take up more beyond my plate if I want to succeed in this class.
I believe that one of the ways I could help bolster my team's workflow is by regularly checking in on other groupmates to see where they're at with their individual work. My idea of its effects is that by continuously poking at my teammates, I can keep track of when they get stuck on problems and immediately unblock them so they can continue to work without worries.
Blog Post 1
Hello, my name is Kanyon and in this semester I am working as a programmer in a team of four in the group Florida Men. We are working to develop a new single-player puzzle mobile game named Gushing Gators. It is a game where you must create waterways by matching tiles to guide precious liquids to alligators in need WHILE avoiding hazards that could contaminate your product. It is a game catered towards a casual audience, seeking to have a pleasant experience while also providing a bit of a fun challenge.
For our first sprint, our team mainly spent time working on a physical prototype of the game and getting the development software up and running. Our game plan was for me to work on the matching mechanic while having our other programmer work on the water mechanic so that we could test our main mechanic as soon as possible.
First of all to create the match-3 system, I needed a way to create an interactable grid so that I could match tiles in the first place. I basically set up a prefab for a tile, gave it a random color on creation, and arranged their positions accordingly depending on what coordinate they are supposed to be on.
 |
| Random Grid Generation |
While there weren't any problems that I initially saw while creating the grid generation, my lead designer and producer pointed out a few key problems. The biggest one was that the random grid generation could create a initial chain of 3+ matching tiles next to each other. This would not fit well within the game because any matches above 4 or more would create huge waterways that would take up too much of the grid, especially since we are going for an 8x9 grid. To add on to that, it could potentially create situations where players would either have a line straight down to the finish point or just have a hole that is too big to work with.
To deal with this, I have discussed with my team that I will work on random tile generation to help combat this issue. I plan to create a random generator that will at max have 2-3 matching tiles on placement so that there are more opportunities for the player to control the waterway they are making.
I have also implemented swapping tiles as well as the mechanic to destroy matching tiles when they meet. However, I forgot to make it so that tiles would not switch upon not finding a match, so you can technically drag any tile anywhere you deem fit. It is an unintended mechanic, but I am planning to use it as an idea when we create special tiles in the future.
 |
| Bug I ran into where spam switching would make tiles randomly disappear |
 |
| Switching tiles works, but not as intended :) |
As for the next sprint, I am planning to improve on the tile generation, add ways to customize levels with immovable blocks / hazards, add mobile controls, and help to create the first playable version for android devices.
For customizing the levels, I plan to add an array variable that my designer(s) can change on the inspector. It will be an array for 2D coordinates, so if my designer would want to add an immovable object at (0,2), then all they would have to do is add in the values in the array.
As for adding mobile controls and creating the first playable version for android devices, I think I will have to make sure that the camera is in the right spot for the player to use since players will most likely be playing with their device positioned vertically.
So far I have high hopes for this project, and although it seems like a relatively dry concept, I do believe our team can make this +1 combination of Where's my Water and Candy Crush a success!
Comments
Post a Comment