Riptide Override: Postmortem
Sprint 7 has concluded, and the game has officially been fully published on the Google Playstore! I'll be going over what happened during the last sprint, significant events that took place during development, the road bumps we encountered, as well as our overall workflow throughout the process.
Sprint 7 went pretty smoothly; we had a large amount of bug fixes as well as finishing up the final mechanics in the game. These primarily included mechanics for the Boss Battle, as well as the Loading Scenes. I added 5 new loading scenes to the game, these would take place after beating a puzzle, being a transitional scene before entering the next level. This resolved the occasional 1-2 second freeze that would occur on some devices during a scene switch. It also gave the player time to catch their breath after beating the timed puzzles. Each of the loading scenes are animated, and follows the submarine rotating and hovering around a spinning environment. The models of the environment are identical for all scenes, butt he details and color pallet change accordingly to foreshadow the next level.
I re-did and improved all the models present in the boss level. The most noticeable change would be the improved mandibles on the boss model itself. These far more accurately blend in to the rest of his color scheme, as well as look for more aggressive and lethal compared to the original set. I also lightly animated the lava in the scene to rise and fall, as well as gave the boss some fire like particles emanating from the mouth. Background objects have been improved, as well as changed in material so the fade in easier letting the player more easily focus on the projectile threats.
I redid the tail model, and also the animation, making it hopefully appear for more smooth relative to the first iteration. There is also now a center column for the boss to wrap its body around, making its eel like form seem far more natural in the environment. Note that the prefabricated projectiles I had made earlier have been implemented by our programmer, Marco.
Regarding those projectiles, You can also see that I was able to fix the particle trail so that they actually switch direction once the projectile gets reflected back, instead of unrealistically spraying in the same direction despite the velocity of the the prefab being inverted.
While I was working on the particles, I figured I would also improve the one I made for the submarine multiple sprints ago. Visually the particles always looked fine, the issue was that they would simply go directly behind the player, and would not be affected at all by the vertical velocity and direction that the player was going. Meaning if the player was rising or falling, the particles would simply be ejected parallel to the rest of the model, as can be seen in the gifs of previous sprint. I was able tor resolve this my making the particles gravity and inertia act relative to the world space, instead of being alone in the particle engine. Now particles well go in the correct direction based on player movement.
In this image the player is falling, and the particles display that movement and momentum accordingly.
After previously completing audio creation for the soundtrack for level 1 and 3, I started and finished the track for the boss fight. This incorporated two separate songs that I edited and overlaid on top of each other. It took a good deal of time and effort to get them playing at a similar pace, but I was incredibly happy with the end result.
Finally I made the "Win Scene". This can only be seen after completing the boss, and how no level select to manually skip to it. We use simply have a text UI stating that you had won the game, which felt very anticlimactic, especially after the addition of the boss battle. I made a altered version of the boss battle as well as a additional 6th loading scene for the player to pop into. It is simple, but has some nice upbeat 80s music, some rainbow particles from both a scrapped volcano system and the player, as well a dead version of the boss. These scene takes no normal player inputs, and loops infinity until the player hits the Main Menu button.
This concludes the majority of my non bug fix related work for Sprint 7. I was only able to complete 8 points, as this sprint was shorter then all the previous ones, but I was still happy with the individual work I was able to complete
For the postmortem, lets start with what went right. Communication is essential when working with a team, and was especially important for us since we only met in person for 4 hours a week, during class. The first thing I did as lead, before even arranging the Trello page, was set up a Discord server.
This is where all communication outside of class took place. I originally set up two separate set meeting times every week for us to communicate, but this would later be bumped up to 3-4 meetings a week as higher demands in development of the game became apparent. Normally taking place on Wednesdays and Sundays
Because of this, we spent roughly a total of 10 hours working together every week, alongside the time we spent doing our individual work. I believe this was critical to the success of our game, and the efficiency of our progress. We were the only group that came to class with a playable prototype when it was requested. By having constant and consistent meetings, any time a issue became apparent, or someone got stuck, we were quickly able to identify it and resolve the issue.
As a social and avid PC gamer, I almost always have Discord running during my free time. This meant that any of my groupmates could @ me to get their Trello cards almost instantly verified, normally under 10 minutes. This prevented anyone from being blocked, and also allowed them to redo the card if I rejected it, while the work was still fresh in their head. If the work was not of higher priority, they would not @ me; and the card would be verified when I normally check Trello every morning and afternoon. Cards and points were broken down to the smallest components that they could, meaning the majority of our cards could be completed in under a hour. I think this helped greatly with production, as individual tasks would be straightforward and not considerable time consuming.
For example, here is a summary of the 1 point cards that would encompass the entry of a individual level, in order of completion:
Reference, Blockout, Terrain Model, Background Model, Midground Props, Fauna, Lighting and Fog
Each card is worth 1 point, so a level would total to around 7; meaning a individual developer could do a entire level start to finish in single sprint.
Agile development aside, another thing I was super happy with was our UI system.
We were able to fully implement a level select system, not only is this nice for players, but it also allowed playtesters to easily jump around to any level, in any order. We also had a pause menu, that would allow the play to restart a level, unpause and go to gameplay, or head back to the main menu. Within the Main Menu, there is also a credits tab. This brings up the Form and Credits documents outside the game when clicked. The form links to a Google Form where people can give us feedback on the game. The credits link to a document stating our individual work, as well as the music (which is all royalty free) and its source.
Alright, so what went wrong during development. One of our developers was not putting out work that was not of acceptable quality, and was often breaking multiple scripts whenever making a push on the GitHub. Not only did this mean that we felt like we were down a team member, due to them not thoroughly contributing to the project, but it also meant that the myself and the other working members had to redo and fix the work of the created by this developer. This was honestly pretty devastating not only to our moral, as every single sprint multiple aspects of game would break that no one was suppose to touch, bit also significantly reduced the time we could of spent on additional content. We had to scrap 4 levels, as well as remove a variety of center piece models that were planned for implemented levels. Two entire puzzle systems were also completely scrapped.
This was rather frustrating, but we made the best out of the situation we could. I scrapped tons of ideas and cards, and modified our workflow and scope to work accordingly. The subsequent damage control we (the 3 working developers) did every sprint proved to be substantial, as if you looked out our final burndown chart, you would never expect we had any major issues.
Our velocity was beyond consistent, averaging to 30 points a sprint, making the trendline almost mirror that of points completed. The start was lower then "Perfect Velocity" due to us only completing 24 points during our first sprint. After this I did the math and figured that all members would need to do at the minimum 7 points per sprint, in order to finish our project in a realistic timeframe with our current backlog. the blue spike you see at the end is due to Sprint 7 being shorter then the others, but also because we planned on finishing early, just in case we encountered unforeseen issues.
Which spoiler alert, we did.
To figure out where things went wrong, we are going to need to look back a bit. In the Sprint 3 report I mentioned that faster devices would run the game at higher a FPS, and the movement system was tied to the FPS. Meaning that if you ran the game on a slower device then the one I set the jump force variables to, you would jump lower, as the force would only be multiplied for the of frames on screen. Well I had a easy fix, lock the FPS to 60, and adjust the variables accordingly. Google analytics said our game took less then 3% processing power on their test devices, which were phones from 2022. And since none of our classmates complained during playtests about performance issues, we did not see any problem.
Fast forward to the day after submitting the final version of our game, and guess what? a problem appeared! When someone in class was playing our game, levels were unusually hard, with some of them being impossible to beat. I watched and noted that the jump force was far lower then it should of been, and that the players and level seemed to be vibrating. I quickly came to the conclusion that the game was being run at a FPS lower then 60, maybe around 45 as visually I really could not tell a significant difference.
Now up until this point we have had everyone in the class, and 25+ people outside of it, playtest of our game. Something as obvious as performance issues on lower end devices should of popped up during that time, yet it didn't. What we learned from this is play testers can lie. As the two people who ran into these issues in class, had supposedly playtested our game at home after class, during multiple other playtest sessions. If this was true, this issue would of been immediately encountered and noted. The issue was movement mechanic not working if FPS got to low; we fixed issues caused by FPS being too high back in Sprint 3. The movement mechanic I made all the way back in Sprint 1. Meaning for 12 entire weeks, across multiple in class play sessions, and friend/family testing outside of school, somehow no one hit this issue.
Is this issue ultimately our fault? of course, we are the developers. In fact, we plan on fixing it. We are not allowed to edit the game anymore until it gets graded. Once it is, we will be redoing the movement mechanic from scratch, so it is no longer tied to FPS. This will not affect or improve our grade for the game in anyway, as we are not allowed to implement any fixes before the final round of players get to test it. Regardless, as developers, we would be disappointed if the final version our product would be functioning to a lower degree then intended, even if the issue only affects a minority of our players.
We want to look at our game, and proudly say "I made that".
That being said, this is the last, and postmortem post for the development of Riptide Override. So no other changes or progress reports will be documented here. Thank you for following progress on our development, and I hope we have created a game that you could enjoy
Dreamweavers
https://play.google.com/store/apps/details?id=com.DreamWeavers.RiptideOverride
Comments
Post a Comment