Blog Post Postmortem
December 15, 2024
Sprint 5 was a really confusing sprint because it was different from the other sprints. It wasn't slow like the first sprint, and it wasn't focused on pumping content like the 2nd, 3rd, and 4th sprint. It was focused solely on polishing and making sure the build works for playtesters to play. If you would like try the prototype, please download it from this google drive link.
 |
| A section I worked on in the third level of the Prototype |
Even though the Sprint was mainly focusing on polish, I decided to work on a couple quick features such as the null zone and image boxes. Some key things I worked on were reset zones and making players stick onto moving platforms. I also helped my programmer with moving platforms and did a tiny bit of level building for my lead designer.
Image boxes were implemented in order to show players how to visually do things. I found that in prior playtests, some players did not like to read giant layers of texts which explained the mechanics thoroughly. This was especially the case for the heavy bounce mechanic, which was hard to condense in a palatable amount of words. So to combat this, image boxes simply require the player to run into the image boxes in order to figure out complex mechanics such as climbing sticky walls and heavy bouncing.
 |
| Image boxes containing my cousins face and a slightly angry clown. |
Null zones were purple surfaces which disabled players from using any states. The purpose of these null zones were to ensure that players would not use mechanics, such as the heavy bounce, to easily skip parts of puzzles by jumping over walls or high surfaces. These zones still be allow the player to jump normally though.
 |
| Player turns grey when in the null zone, indicating that they cannot switch states. |
Reset Zones were linked to checkpoints and basically reset all the positions and states of boxes, buttons, moving platforms, fans, and doors. The main purpose of these was to provide the player a way to avoid soft-locking themselves, such as finding a place they could not jump out from or getting a box stuck in a corner. The player is also teleported back to the checkpoint as well to ensure that they do not abuse the checkpoint system to solve puzzles.
 |
| What resetting looks like: |
Last feature I worked on by myself before helping my teammates was being able to stick onto sticky moving platforms. Initially, players would only freeze in air while the platform moved away since the code didn't support sticking to moving objects yet. To fix this, I parented the player character to the platform so that it could move along with it and turned on physic sync to make the movement with the wall seem seamless. I also had to change the way the script stored the sticky contact point so that it stored the local position instead of the world position. If I did not, the player would jump off walls based on where it initially landed on the platform instead of where it currently was at, which would make the player jump off the wall to an unexpected direction.
 |
| Sticking to a moving platform and detaching. |
As for what went right during development, I believe our team had a decent and effective way of communicating our ideas and statuses to each other. We had a discord group chat and basically asked all our questions to each other there, asking if we needed to call for some problem solving, reminding each other of due dates, and asking for Trello board updates / clarifications. We also had an easy time getting along with each other, sorting out any communication issues we had immediately if we had any. For example, anytime any of us knew we didn't have time to work on something, we would simply let the group know and why. This allowed us to keep a good relationship with one another during our development journey, which I believe was a key part to why our team chemistry flowed so well.
One problem that happened during our development kind of coincidental because it is that our communication is too simple. We had a lot of merge conflicts because we never really checked into what scripts we were working on. This was also the main reason why our first Sprint was so slow. We were all too scared to work on the game because we had one big script containing most of the games code and didn't really know how to chip in our work all at the same time. Also, we had a couple rough merge conflict nights during our days of development which lost us a couple days worth of work. Although we are satisfied with what we put out, we probably could have created a better product if not for the merge conflicts we faced along the way.
 |
| A recent merge conflict that probably lost us a couple hours of work |
I think if I were to be a producer / flex again for any project, I would have a much better idea of how to handle the beginning and ending stages of agile development. Now I know that a key point of a successful agile development team is figuring out a system where we check in and check out scripts so that we know exactly what scripts are being worked on. I think I would also create a discord server so that we can set up multiple different channels to discuss or showcase various topics. This would be so that it is easier to find common links such as the design documents / prototype downloads. It also would be easier to invite playtesters to be able to have them interact with the whole team.
All in all, I have learned a lot about working in my first game development team. There are many upsides to working in a team, such as increased production, variety of ideas, and fun. There are also downsides such as tough communication at times, but I think I was very fortunate to be able to work with such a well-rounded and balanced team. It is an exhilarating process, and I definitely am looking forward to working with more hard-working teams in the future!
 |
| Where is this image in the game? Go play our prototype to find out :) |
Blog Post 4
November 24, 2024
For Sprint 4, our progress went decently swell in the Juicy Aliens. We did not make as much progress as the last sprint, but we still did a decent amount of work. Anyways, we focused mainly on implementing changes based on the feedback we gathered during our digital prototype for our System Prototype. We focused all the gameplay on testing out on a tutorial level we created in order to see if we could teach the playtesters how to play our game more properly. Instead of immediately combining physical combos in the level like heavy > bounce, we decided to teach each mechanic separately in their own sections instead. We also went more in depth with the sticky and heavy mechanics, adding more slides and walls that the player could climb on. Overall, I'd say the system prototype playtest and development went smoothly as intended, mainly due to the fact that we completed the sufficient amount of work from the sprints beforehand.
 |
| Overview of the System Prototype |
One of the features I worked on for this sprint was adding hint boxes that popped up messages whenever you hit them. The reason why I added this was to address the problem that many players ran into in the digital prototype, which is that they never closed messages to the point where it started to clutter the screen and annoy some of the players. By adding the hint box which players could choose to touch, I figured that players who already have played the game would skip past them and continue progressing throughout the given level. However, I found that to be completely false. Both new and returning players, from what I have witnessed during playtests, always seemed to want to touch the hint boxes even when they knew what they needed to do. There was a lot of criticism around there being too much text in the hint boxes as well, since I wrote lengthy descriptions of what you needed to do in order to perform mechanics such as the Heavy > Bounce mechanic. To combat this in upcoming playtests, I decided to add 'image boxes', where when touched, it would pop up an image covering a majority of the screen that showed the player what to do. It would also automatically close the image when the player leaves the vicinity of the image box. This way, it would help players learn by example rather than having to read a lot to improve their learning experience.
 |
| Hint box functionality |
Another feature that I worked on was the ability to bounce off walls. I believe this is one of the most important things that I have worked on in this sprint since it helps new players understand the sticky mechanic much easier and faster. Initially, when jumping off sticky walls, players would jump alongside the wall since the only force pushing them off the wall was up. This meant that when players tried to re-stick to walls when jumping up, they would just slide all the way down since the player character did not have the opportunity to retrigger the OnCollisionEnter event. The event not firing off is very important when sticking to walls since it does not allow the player to stick if it does not get called. This unintended mechanic confused players a lot because from a non-programmer perspective, they would assume that they would immediately re-stick to the wall when still on the wall. This is why the ability to jump off and away from the wall is so important; it tells the player that they are moved off the wall when jumping off and that they must move back into the wall to re-stick. I believe that by having this reworked feature into the game, it will vastly improve the player's experience with the sticky state :)
 |
| Player being pushed off the sticky surface / wall when jumping |
Though this may sound a little negative, I do believe the progress done in this sprint has made me a little concerned for our upcoming last sprint. Since we've completed so much work in the beginning, I can definitely tell that our team's working pace has slowed down just a bit. This is not terrible since I believe we have the tools and capabilities to fully fulfill the requirements for the final grading rubric, but it just makes me a little worried about us taking it too easy and wasting time. My hope is strong for our final prototype, so I hope you, the reader, can play our game and enjoy it as much as we enjoyed making it. Thank you.
Blog Post 3
November 10, 2024
Sprint 3 for the Juicy Aliens tied the points finished in Sprint 2, but I believe we as a team have gotten many more important things done than in Sprint 2. This sprint, we focused on creating a working physical prototype for the playtest that we had in class and I believe it went well. Our mechanics worked as intended besides the pause menu not working, and we were able to test out all of our physical states in the prototype level mostly made by our lead designer. We had a large ramp designed to test the heavy state for longer jumps, sticky walls for sticky, and a heavy-to-bounce state switch section. The heavy-to-bounce switch was a mechanic where the player had to drop fast with the heavy state and switch to bouncy state last minute in order to achieve a higher bounce. Overall, our physical prototype was able to garner useful feedback from playtesters for us to apply to our upcoming Sprint 4, which I consider a massive success.
 |
| An overview of our prototype level, picture taken by Lead Designer |
For Sprint 3, I played a supportive yet prominent role in development, helping with code while also working on features to improve the quality of life of the game. The code I mainly helped with was with merging the code of all of the separated scripts we've been working on. We worked in various scripts in order to avoid merge conflicts with one another, and we decided to combine them so that we could create a prefab that we could put in each other's testing scenes, including the prototype level. This is important so that later on when we want to test out mechanics in our own scenes or workspaces, we can ensure that we are all working with the same player controller and that it will transfer into the official levels without any problems.
 |
| Our code from various other scripts merged together |
Another piece of code that I helped to work on was the sticky mechanic. Beforehand, the player would slide off to a random direction very slowly after "sticking" to the wall. To solve this, I basically froze all the rotations and positions of the coordinate values of the player object's Rigidbody component. This guaranteed that the player wouldn't move at all when they were stuck at the wall since the player movement was based off of its rotation (since it is a ball). I also made it so that the player could unstick by jumping to allow better control for the player. However, a lot of player during our playtest were confused since jumping alongside the same sticky section of a wall doesn't allow them to stick to the that, so we will have to address that during our next sprint by forcing them to move away from the wall somehow.
 |
| Showing that the player must move away from the wall in order to reattach again |
 |
| A level in the prototype I made for the playtesters to test out the sticky mechanic |
I also have worked on the functionality of checkpoints, indicated by slightly glowing cyan blocks floating in various areas. They detect when players enter their box collider (which can be configured), and check to see whether they have already reached the checkpoint or not. If they have not touched that checkpoint before, a message pops up showing that they have reached a new checkpoint. After setting their checkpoint, anytime the player falls off the map or touches lava, they are spawned back to their most recent checkpoint. One complaint that the checkpoints received however is that the camera snaps backwards whenever they die, which is going to be fixed in the next upcoming sprint.
 |
| Checkpoint reached message + checkpoint respawn functionality |
The last big thing I worked on is the message boxes which exist to tell the player what to do. Basically, when a player touches the hitbox of the message box prefab, a message box pops up on their screen and displays the message. The player can also close these messages by pressing the key 'F'. We used this in our prototype level to tell the player what to do next, such as 'Press Space on the keyboard to jump onto these platforms!' or so on. We did receive some complaints about there being too many message boxes, so I am thinking of implementing hint boxes that the player can press. These can be accessed by running into them in the levels so that the player can either choose to figure out the game on their own (which some of the playtesters wanted) or go through with the tutorial messages on their own.
 |
| Message box popping up once reaching an area, can be closed by pressing f |
Overall, this Sprint was a good success, and I hope it will continue throughout the rest of the sprints. We ran into some merge conflicts here and there, but thankfully we only lost a few hours worth of work so it did not slow us down that badly. In our next sprint, we plan on implementing a few more level mechanic features before closing out by polishing our existing features. Thank you for reading, and I look forward to your future successes.
Blog Post 2
October 27, 2024
Sprint 2 was definitely more successful than Sprint 1. Our team, the Juicy Aliens, were able to get a lot more work done now that we were able to do separate tasks that didn't overlap one another. I assigned 25 total cards to the team and were able to verify and complete 19 of them, a massive leap compared to our 7 cards that we did in our first sprint. The main things we were able to implement was a more polished movement system, locked door mechanics, and a basic pause GUI. Overall, we were able to output a lot more work and progress as a team and I am very proud of where we are standing at the moment.
 |
| Sprint 2 completed cards |
Even with all of these successes however, I do think that we have things to improve on in our production. First of all, I realized that not all of our tasks on the team were not moving towards making a functional prototype. This is not optimal because the main purpose of this course is to learn how to make prototypes, not a game. The things that I assigned that weren't useful for making a prototype were the tasks I was working on; the user interface. Although a GUI is useful to have when playing a game, you really only needed some words on the side of the screen to help show the player what to do when playing the game. Some images and basic images would also be helpful, but I chose to work on the functionality of the pause menu instead. This would not be terrible when making a game, but for a prototype it is definitely an extra feature that is not needed. I would compare it to spending time to plate up a $2 pack of instant man n' cheese instead of just eating it as intended. In this next sprint, I will definitely steer more of the tasks towards making a functional prototype rather than making a game.
 |
| The pause menu pausing the game |
Anyways, for the features I've added to the prototype in Sprint two, I created the pause menu for the game. The menu is activated when pressing the 'p' key on the keyboard, and I have made it so that when the player pauses the game, everything in the game pauses as well. There is also a resume button for when the player wants to resume the gameplay as well as a controls and quit button. The controls page displays the controls of the game, and I specifically named the button 'Help / Controls' in order to give the player the idea that they cannot change the key binds but instead view them. Since this is just a prototype, I will not add the option to change key binds from this menu. The quit button simply exits the game for the player so that the menu has a bit more functionality and purpose to it.
 |
| What the controls page looks like |
As the producer for the team, I geared the next upcoming cards of the team towards making our first digital prototype for the upcoming playtest. This time, I made sure the cards were more purposeful in making a prototype rather than assigning random cards that I thought would be nice to have in the game. For example, I assigned cards for level making that made sure all three of the physical properties were tested. So that would be high jumps for the bouncy card, long jumps for sliding as a heavy slime, and wall jumps for the sticky property. I was also thinking about making a level as a team, but from a programmer's perspective I don't think we should prioritize that just yet. We need at least a day to piece together all our work in one scene since we've all been working in separate ones to improve our workflow. I honestly have high hopes for this upcoming playtest, and higher hopes for our production efficiency in the future.
Blog Post 1
October 13, 2024
Hello my name is Kanyon Nguyen, and I am the Producer / Flex of the Juicy Aliens, creating the game Rolly Reactor. The game is being made with Unity 2022.3.7.f1, and my teammates are Chijioke Ihejerika, who is the main programmer, and Matt Gai, the Lead Designer. The game summary is:
Rolly Reactor is a 3D platformer game about a slime named Gello who is traversing the lands to escape an alien planet. Using its variety of physical states, the slippery slime jumps, slides and soars through all of the obstacles on its path to freedom!
 |
| One version of Gello, inspired by Maplestory's slimes |
So far this year, we have been through one sprint. By the end of our first sprint, we assigned 12 user stories, moved 8 of them into verify, had 1 remaining in verify, had 3 in progress, had 1 that wasn't moved, and completed 7 stories. At first we had a bit of trouble setting up the Unity project. For some reason, the version of Unity that the GitHub repository wanted to use was 2022.3.17f1 instead of 2022.3.7f1. Our team was able to resolve it in about 18 hours so our workflow was disrupted only for a bit.
 |
| Conflicting Unity version error message |
Afterwards we had a relatively smooth ride, with all of us learning how to use the Trello board and how to set up GIFs to help the producer (me) verify the completed cards. My tasks during the Sprint was to help setup the Unity project and to finish the functionality of the third person camera on the player. I eventually switched the camera task with Chijioke since he was already 80% done with it and it would finish it much more faster than I would have. I was then left with figuring out the jumping mechanics for the player which I have not finished yet. I did setup my own test scene in the Unity project to help visualize the camera functionality as well as jumping around.
 |
| The current state of my scene in the Unity project. |
The reason why I was not able to complete the jump task yet was because of one of the main problems we as a team struggled with: communication. We aren't usually able to contact each other until the last possible minute, slightly affecting the quality of our work. This is the case with the jump script I am trying to work on; we had potential changes to the movement script that require verification and discussion as a team but haven't been able to meet up with each other yet since things popped up in our schedules. We have tried contacting each other through digital means like discord calls and phone numbers, but it was not 100% reliable because there was a high chance it wouldn't immediately reach each other.
As for solving this conflict of schedules, I plan to propose specific times and dates a couple days in advance to give my teammates and I time to prepare for meetings. Although it is nice and convenient to meet up spontaneously the night before assignments are due, I don't think this is very sustainable because it limits the amount of time we can spend together as a group. The reason why I believe this is important is because we need extra time to discuss important details such as what we are planning to do in the game, what tasks we need to prioritize, group decisions, and much more. I think this plan will definitely help out our group so that we can solve or prevent bottlenecks in our development much easier in the future.
 |
| A list of tasks I made on Trello that I wanted to discuss with the team that I couldn't get to yet. |
Other than figuring out our schedules, I plan on working on the user interface of the game next. I am thinking of adding a pause screen to the game with buttons. So far, the buttons will consist of a "Resume", "Quit", and "Controls" page. I am not sure if I will be able to freeze the state of the game since currently, part of our move script is not physics based and could bypass the 'timeScale' property of the physics engine.
 |
| The current plan for the pause menu screen: |
Comments
Post a Comment