377 Mobile Game Development

Sprint 5

For this sprint review, a lot of work was done to help with feedback and work on certain parts of the game that are a little undeveloped and get somewhere with that. One example of this would be the art and UI of the game. Through playtests, one thing that stuck out was the lack of feedback that was in the game and that it would be nice to see the art take shape within the game. This is something that we focused on while working on the main gameplay as well.

One thing that I worked on alongside the UI as the main thing was reworking the level traversal system and integrating it with the new battle system within the game. Elizeo changed his battle system to allow for battles one after another and so there were a whole lot of tags and new items made to work this. I then needed to change up some of my tags and code to allow for multi platform spawning and having the code now reference the new tags.

One other aspect I worked on was creating the singleton that would encapsulate a lot of the connections between different scripts and stuff. This was really helpful for the aforementioned traversal system because instead of having a reference and having everything connected in the editor, it was done in the background through the code. The traversal and battle system could talk to each other in the background. I also added the resource gathering and totals within the script so it can also handle that. I made sure to connect this to the shop, even though nothing is able to be bought yet.

The playtests were very helpful because this showed us glaring problems like the feedback but another thing that players brought up was the idea of doing more within the battling. This meant that, even though the game is centered around just idle battling, players want the choice to be able to engage in more than just battling and they want to be the ones to be able to choose. So I went to my designer and told him about this playtest idea. We then collaborated and realized we can use the coins you earn from battling to do other aspects such as healing or other aspects. This will be adapted by the programmer because he already had this system but it got removed in the earlier sprints. 

In terms of art, this sprint was a really good solid size of models and texturing that was done but for the next sprint and especially for beta, we definitely want a large amount of models and stuff done so the players can be immersed in the world. We are really shooting for having so much done in the beta that the subsequent sprint can be focused on getting bugs fixed, polishing, and adding small features here and there. This is theoretically possible with the amount of cards we have, it just comes down to doing the work. 

Sprint 4

For this sprint review, we as a team had a meeting about the future of the game and all that we wanted to do so that we have a working piece of software at the end of the semester. This meant reorganizing our current cards and discussing the future of certain features we let go. This led to a large amount of cards assigned and completed. Therefore, it was a very beneficial and heavy sprint that resulted in a lot of things being made that will help for the long run and main features.

I took some time as the producer to set up the closed testing branch and get the game ready for the alpha build test. I also fixed up the trello board. There were points that weren’t going to be used so I just deleted them. There were also cards that needed images and broken down. 

        One of the main things I worked on was getting a working build for the alpha with all the different systems. One thing that I got ready was the menu manager and setting it up with all the scenes that were added with the sprint. It now allowed access to the shop, character equipment, and the main level. This is something that will help us later so that when we work on the individual scenes, it just leads from one to the next. 

        I then worked on the level prefab and made it so it's flexible for any future levels and it serves as a template for future levels. I also worked on getting the pause to work with the level. The idea was that the traversal system would move and then pause when a battle shows up. The flexibility came from the array I made and how the level will choose a random piece to put next.

        Our alpha playtest led to some information that we already knew but it was still helpful to have the information we got. It revealed to us that we need to work on our UI more as it is not clear sometimes what the player is looking at or who even the main player is. Another thing we found was that there are some oversights that we needed to fix. An example of this is that the health can be edited within the game by sliding it. Another one is that if you spam the attack button, it just attacks but wont spawn in the next enemy/give the prompt for spawning the enemy. Both of these bugs are game breaking and were something that we just didn’t test but thankfully it came up in this playtest. 

I also started a singleton game manager/ resource manager. It is important to the game as there are coins and values that we need for mainly the shop but it also is  the singleton for the spawn rates and information of what the player owns. This system is also helpful in getting a drop system for us. It will allow us to communicate with other scripts and tie everything together.

Sprint 3

For this sprint review, we continued our work on different components to make up the whole of our game. My partners worked on their respective items and did a good job with the things we needed to do. Some assignments got in the way for all of us which led to this sprint being a light one for us as a group but this will be changed next sprint. For me, this sprint consisted of creating a menu manager system in which the player can access different menus we have such as play and the inventory as well as creating the level movement system. 

The main important part was creating the level movement system because it would allow the player to traverse forward and encounter enemies within their run. This was achieved by instead of having the character move, I just had the whole level move to give the player the illusion of movement. This was inspired by a subway surfer level in which it goes infinitely but we will stop it at a certain point. There is a trigger at the end of every level prefab to indicate when the next part of the level needs to be spawned. 

This system is also flexible for any of my other partners as they just need to create a level prefab and just add it to the array. The script will handle the spawning and placing levels. It also will handle deleting the levels that aren’t needed by deleting the pieces behind the player. 

I also took some time to organize our trello board and backlog. As some of the vision of the game has changed and with time restrictions, I went through and looked at what the actual important aspects of the game are that we need to focus on for the rest of our sprints. Things like getting multi character working and resource gathering work in every scene. I redid the organization of the backlog with this information and it provided a way better and cleaner timeline of the things we need to focus on for the next couple sprints.

Another thing I worked on was a menu manager system. As of right now, it just loads the scene. I am going to talk with my designer with the idea of incorporating levels by having the scene load within the scene. This might be beneficial as we might not have to focus on getting so many variables across scenes when we can just load the scene we want within the scene we’re in. This scene loading is something I am experimenting with to see how well it works with our game and its variables. 

I also had a light/kleenex playtest with my friends to test out some of our individual components to see what they thought. As we didn’t feel like our alpha build was enough for a playtest, testing the individual components was the next best thing. The main point that was brought up was the idea that these individual ideas are cool but definitely need a level of combination because it will help flow the game better and actually be fun being able to experience the game as a whole. One thing they want is the idea of automatic combat being actually automatic. Before the new iteration of combat, they experimented with the combat where you had to press a button still and while to players it wasn’t the biggest deal, they would still have liked for them to have to just watch and learn through the gameplay of what to do if they died and improve their characters.

Hello my name is Mo and as a part of my mobile game development class, we were told to create either a puzzle, idle, or merge game. The game that me and my partners are making is called Dead Water. Dead Water is an idle dungeon crawler game in which you create a team of three characters to fight through an infinite dungeon. Your team will have a time limit for how long they can stay in the dungeon. The farther your team can get the harder the enemies will get but the better rewards you will receive. 

For this first sprint, we focused a lot on getting a paper prototype in order to see if our game core mechanic and idea was actually something fun and interesting to pursue. One difficulty is that It revolved around having to configure a combat mechanic from an idle game, a mechanic that would automatically be calculated for you in the game. So this was one challenge we wanted to face right on so that we could have some sort of a working paper prototype that is similar enough to the digital prototype and not two completely separate things.

We first started with creating a rule sheet so that we could break down our game into different components in order to make our paper prototype. We created a token based system in which players would take different cut out pieces of paper representing different items. We then started to create different procedures and rules within the paper. These rules and procedures then became the different systems we created. Things like the aforementioned combat, as well as resource gathering, choosing characters, selecting a map tile, etc. I worked closely with our designer to create the rule sheet and the cards and tokens used within the game. 

I think this is where a big blunder started because creating a rule sheet in turn sort of led to a snowball effect happening. With the rule sheet, we started to define our whole game rather than taking a second to focus on the thing we need to look at the most. This behavior of making the whole game led to a rule sheet that was very dense and very long. It revolved around the combat system, sure, but the procedures surrounding it also led to an influx of too many things that would need to be accounted for. We had too much and an example would be the idea of having different character tokens and having to move those and other tokens in the game when we could have simplified it to a huge degree. We also just had the player do so much like when they got an item and how they thought like different weapons do different damages but in reality they don't.

This was very much shown within our playtest. The playtest was very much an eye opening experience to show that we had packed too much within our playtest and it needed to be trimmed down. The playtest was very very long and it took players forever to set certain items up. Our rule sheet being so dense and non labeled led to a low/poor readability for our rules and the things the players needed to do. They also felt it was too intimidating to begin with and would be lost or not know what to do. Some players did feel that as they started to get a handle on things and figure out what the process was, they slowly started to get it and enter a state where they were calculating automatically, a system close to our digital game.