CAGD 377 - Postmortem

 We have reached the end of the Project, and with it, we have our last version of the game Slippin Away. This project was my first ever project for mobile development, which also came with various challenges that I was unaware of at the beginning of the project. I was thrilled to have an amazing, flexible team that would adapt to all the production hurdles.


At the beginning of Slippin Away, there wasn’t an exact idea for the project, so it took some time to develop the base design idea for the game and determine how we wanted to target it. With the prototype, we figured out what the game mechanics would look like.



The prototype was to test the basic mechanics and make sure that the game concept was fun; this mechanic testing was done in Sprint #1, and it needed for the player to be able to drag the screen, making the character launch and also stick to any surface it lands on. We were ready to begin the production process after having this prototype and getting excellent data on the playtest.


Some things went right during the production side of the game, including keeping the whole team on schedule and communicating with the team. We had various meetings to catch up and prioritize the features needed for the end of the sprint; this allowed the whole team to be on the same page. Another thing that kept the project going was how, during each end of sprint, the whole team could see the game's progress, test it, and report any bugs or unwanted behavior that the game might have. 


Various challenges were faced during the development of Slippin Away, the first of which was mobile development. Before this project, I did not have experience developing a mobile game, so there were various factors that I didn’t consider when making the game. The first feature I didn’t think was the screen orientation and size. Because this is not a computer game, an extra setup will be required for the UI to adjust to all the devices we support; after one of our meetings early on, the team decided that it was going to be best to have a portrait and this would allow the level design also to have a vertical focus. 


Another challenge that was presented was the logic behind the puzzle of the game; at the beginning, we had a simple connection puzzle; however, the feedback that we got was that it felt more like a task than a puzzle, so we decided to add various elements to make the puzzle more challenging. One of the most fun and challenging mechanics implemented in the cable puzzle was to make it so that the cables bent on the corners of the objects. This feature was complex because there was no reference for approaching the problem, so I had to develop it from scratch. This is how that feature turned out:


With this feature completed, the next challenge we needed to add was that they would start retracting to their original position if the cables collided. This also presented a challenge because it would mean that wires would need to be checked if they were colliding. Overall, both of these features proved challenging because, besides solving the problem, I had to keep them optimized so they wouldn’t affect the device's performance.


Another big problem I found during the second half of the development process was how the levels could have been further optimized, and some of them were using about 1800 game objects, which I realized was not the best to keep the game’s performance suitable for mobile devices. With this in mind, I started researching possible solutions. I came across Unity’s grid system, which allowed the level designer to build levels like a canvas and have a smoother level design with optimized collision. This level design tool would effectively increase the game performance significantly.



Something that I would change for future projects would be preparing for developing games and having the target platform in mind before starting the development. In Slippin Away, because I didn’t prepare for the game to be on Android, it meant that we would have some troubles with the configuration to publish on the Google Play store and optimizing the levels to keep the game smooth for all of our supported devices.


Slippin Away was a great project that showed me the various platforms and structures that games need depending on multiple factors, including the target platform and audience. Something else practiced in this project was the effective use of Agile Scrum, which allowed the project to flow smoothly and allowed us to calculate our team’s velocity to improve. There were various hurdles faced during the development of Slippin Away. Still, I think they all made me learn that there are different perspectives a problem could be approached from and that it might requiere more than a single iteration to get the most effective solution to a problem. Overall, Slippin Away was a great project that allowed me to see the pipeline for developing mobile games and what parameters to keep in mind.

Comments

Post a Comment

Popular posts from this blog

CAGD 373 - Pirate Game Assets Final

Image
  Game Walkthrough:      The goal of this project was to recreate a location from Sea Of Thieves. My team decided to work on an outpost with a stationary sloop and a tavern. We needed to make the mountains similar and add many assets that would be interesting for the player to look at, like the barrels and the lamposts. Also, we needed some interactivity, like cannon shooting and quests. My role on this project was the programmer in charge of implementing all the systems regarding the gameplay. So I managed to make the player movement, interaction with barrels, shootable cannons, a quest system, the final battle, money systems, a high score leaderboard table, and many other small systems within the scene. I also tackled Unity-related tasks like generating a new water shader and sculpting the terrain. One of the problems I faced was dealing with the inventory system since that took a whole sprint on its own, and I did not have any prior experience designing one. I tac...
Read more

CAGD 470 - Locked in Sprint #1

Image
  In CAGD 470 (Video Game Production), I was recruited into a group that wanted to make a first-person horror game in which a player is in a laboratory and trying to escape. At the same time, some monsters roam around, making the player’s journey difficult. The game will have various rooms and puzzles that will challenge the player. In the game's vision, enemies would roam the laboratory. The player would have to gather various items that will help them on their journey to escape the lab. After getting an idea of the game, many key points and features came to my attention, including the player controller, enemy AI, Inventory System, and Crafting System. All those were going to be heavy tasks for this project. After discussing with the other members in the group, we concluded that the hardest feature to develop would be enemy AI since it needed to include multiple behaviors and enemy types, and we all had previous experience programming enemy AI. I took on the task of learning how t...
Read more

CAGD 495 - Stumble Sprint #3

Image
  Starting Sprint #3 for Stumble, there were various things that I wanted to get done; personally, I wanted to implement the core game loop and get started on the arena for the game. During the sprint kickoff, there were various priorities that the designer and producer wanted me to get done at the beginning of the sprint, which were modifying the player controller further and changing some keys; these changes were based on the playtests conducted at the end of the previous sprint. It was mentioned to me that during this sprint, we were going to have an animator & rigger for the team, so I wanted to get animations in the game. So, the first thing I started working on was the priorities and adjusting the player controller. I started working on a delay for the diving mechanic. The biggest problem during the playtest was that players were unable to cancel the dive and dive midair again; if you were quick enough, you would get boosted forward just by tapping space quickly. I adde...
Read more