CAGD 377: Mobile Game Development
--------------------------------------------------------
377 Merge Dasher Sprint 6
This sprint we focused even more on player feedback. Because of the progress we made last sprint we have MUCH more positive feedback in this sprint for how our game feels. For starters, we got the gear system to work so now our car is fully customizable with the gear you collect on the road! The feedback from our new playtest during this sprint was a lot more positive and more insightful, so we know what to touch up on before our full release.
I worked on a lot more bug fixing and UI changes, which I'll probably continue to work on throughout the rest of the development period. I changed a lot of the buttons and the display to line up on as many devices as possible since it's kind of hard to get working in Unity.
First off, making the UI more user-friendly was a huge step forward since a lot of players skipped entire parts of the game because of how hard it was to navigate (or just cause they wanted to immediately press play again) This was partly because of how hard it was to read some of our buttons, but also due to the way they were positioned on the screen. It incentivized them to just click the first button they see, which was the play again screen. People also ignored the tutorial which caused them to get confused when they started playing, so I'm gonna be changing that around.
I also found a good base speed for our car that we can play with which feels more responsive and fair to the player. This still needs some implementation but now that we have a feel for where it needs to be it will feel a lot better in the final version
I also worked on making sure that the players will be completely incentivized to learn how the game works, giving them a proper explanation of how the game works. So, I'll have to make a few more scenes and play with our scene management so that it makes more sense to them.
However, the big thing I did which I regrettably wasn't keeping track of on Trello was constantly updating the versions for our game when we made these big changes and testing them myself and among other people to get their feedback. A lot of the in-person feedback I got from people wasn't amazing like I had hoped but after constantly testing for these changes the fun factor started to kick in with our testers which brought a lot of hope back into our team.
Next sprint we'll probably be focusing more on some quality-of-life changes, making sure that our game is feeling good and not trying to break it by adding anything too new. The only big asset we want to add is sound, which looks like it shouldn't be too bad to add. Personally, I'm gonna focus on refining the player experience with what we have in the game right now, meaning changes to UI, tutorials, and making the game more concise.
I'm looking forward to making these last few changes and seeing how our game turns out. The development process definitely didn't go how we wanted it to and I think we could have done some things differently but if we can get a fun game out at the end of the day that's what matters and I'm proud of us for getting it there.
--------------------------------------------------------
377 Merge Dasher Sprint 5
This sprint was a bit of turbulent one, with all the things we had to work on for our game in combination with the feedback we got on our test, I wanted to do my best to go in with my head held high and get as much as I can done to make the game fun. I was doing my best to coordinate with my groupmates about what needed to get done, since our feedback on playtests was mostly negative
So, the work this sprint consisted of A LOT of readjustment. Particularly in the playtest we got lots of feedback about the game feeling hard to play and not fully available. So my biggest tasks were to add colliders to the levels to allow our programmer to instantiate the obstacles easier, and readjust the positions of the obstacles to make them more fair and fun to navigate. I also spent a lot of time meticulously adding spawn points for power-up pickups in each chunk so that the player can collect the needed parts to upgrade their gear. Another thing I did was make sure that
I also spent a lot of time doing producer things and making sure the build was up and running properly by changing how the scenes interact with each other and making sure they line up. This helped a lot so that we could actually test how our game works as a build.
I also was the main person conducting playtests for our game and getting feedback from different types of players, some whom were casual gamers, some who are in CAGD, and some who had barely touched video games in their lives. They gave us a good amount of feedback for the new systems we implemented like the merge system, collection system, and different menus. I think we can still make a few adjustments so hopefully
I want to spend this sprint review talking about some of the things I wish I had done differently during the production process. I think I would've rather focused on trying to make sure that the game itself was fun from the very beginning instead of trying to produce assets and features that might have not worked out in the first place. I think I could have inserted myself into these discussions with my teammates better and given my input about why things might not work out the way they think but became somewhat complacent in how the game was being developed despite me being the producer, so I feel like I might have failed in that department. Though I'm not too hurt by it, and I think that if I'm in a lead position like this in the future I'll know how to handle it better and argue for cutting things and diverting production efforts to making sure that our core gameplay loop was fun and making changes if needed
In no way do I think we have a bad game on our hands, but I think that the potential we had as a collective was not fully realized because of the way we structured our production efforts and I feel I am partly to blame. These next few weeks I'm going to do my best to try and steer course as best I can and make sure that our game feels FUN to play even if some things are gonna be missing that we wish we had. As a team, I think we understand what needs to happen going forward so that we can make the game as fun as possible.
--------------------------------------------------------
377 Merge Dasher Sprint 4
This sprint I tried to focus on hashing out a few more smaller elements in our game before our new build and refine the mechanics based on the feedback we got from our playtest.
First I started with a few of the easier cards. I created a model and a UV in Maya for an Ice obstacle that would act as unique obstacle for the snow biome we wanted to have, however we haven't implemented those features yet. I then textured it in Painter and made it a prefab in Unity.
The other big task I worked on was making sure that the level chunks from the previous playtest weren't completely unfair. I realized that a lot of the players didn't want the obstacles to be super difficult to maneuver but would prefer an easier experience. Ultimately I think even after this new playtest we had they still need adjusting along with the speed of the car.
I also created a couple more of them before the next sprint just in case, but I think after the results of this sprint I'll have to continue to adjust them rather than make new ones.
And because I was the lead I had to deal with the publishing of the app on the store, which I still couldn't get right until after the playtest day of class. My description of the app wasn't long enough or detailed enough so it rejected my upload which caused us to miss it. It was a lot more frustrating to set up this time around because of the extra steps we needed to fill out to make sure our game could be recognized in the store. It took a few hours beforehand for me to figure it out but not until class did it tell me that my build was not fully uploaded. I felt really bad for not having known that before but I persisted and still was able to get enough playtests for meaningful feedback afterwards.
The feedback this time around was still quite poor. The mechanics in our game were not refined enough and I think I messed up by not including some of the mechanics in our build that I thought I did. The level generation also felt unfair still and the moving truck obstacle got in the way a lot so it'll have to be used sparingly. The players also couldn't deliver food or feel the feedback from it, so that will have to be added onto. Lastly players couldn't access the menus all the way so restarting the game was impossible if you had selected the garage, which transferred you to a scene with no way out.
Then in the last couple of days of this sprint, I came down with a cold so I was unable to make it to sprint review. But based on the feedback I got on our game I think that I'll have to really put in the work this next sprint to make sure that our game is running properly and feels fun to play since it has been really frustrating (I feel this as a player, so I don't take it personally).
I'm glad that people are being honest with our game when they play it so that we know what we need to improve. I feel that last sprint I was focusing on tasks that didn't really matter as much since we thought we'd want more features, but it is more important now to fix what we have before we even think about adding more.
I will have to negotiate cards with my teammates still but I feel good about what we might accomplish next sprint if we aren't worrying about new features and are just focused on what we have and achieving those goals.
--------------------------------------------------------
377 Merge Dasher Sprint 3
This sprint was focused on getting our build/app in for our player feedback and getting a basic version of our game in for testing. The biggest stressor for me this sprint was trying to get the app uploaded and having lots of technical difficulties with playtesting since I am hardware-limited (old ass phone)
I'm not an Android user, which means that learning anything related to Android is going to be completely new, even some of the basic things like what each Android version is or what an API level is. So I had to learn about that and then realize that the phone I got as a hand-me-down from a family member was quite fricking old. So old, in fact, that I don't think I'm able to download my game for testing and only able to test it in Unity remotely through the play button inside the engine. I had some of my personal playtesters do that but also had some of them download the app via email invites.
Trying to make sure that our API level was correct, creating multiple versions for last-minute updates and changes, and making sure that the build worked the way we wanted was super stressful and my team was trying their best to help me out while I was figuring that out so I have to thank them for not letting me just go alone about it. However, it was also frustrating for me trying to get playtesters since I couldn't just go out with my phone and ask people I knew to test the game since it can't download the testing app. I might try to look more into it but I also am not sure there is an answer other than my phone being too old which would be really unfortunate.
Aside from that super stressful chunk of work, I was working on a couple of things before and after the playtesting. I made sure to finish my house models and textures before the playtest so that we could at the very least see how they look in the game. I also worked on about 6 different level chunks before the test and 3 more after the test. I also spent some time readjusting the ones that I created after the sprint so that they were less frustrating to play against based on our player feedback.
I also worked on creating the houses that we are going to use to have players deliver the food we want them to. We're likely going to have it set up where you have to deliver certain types of food to certain houses. I did all the work for creating the house itself and setting up the systems in unity so that my programmer can create his own script for it. I also made two different digital textures so that We could put different ones together and give some visual contrast
Overall this sprint wasn't quite as productive as the previous for me, but I put in quite a lot of hours trying to figure out technical difficulties and get the game's build running and up on the play store. That part took a lot of effort and lots of late nights and several hours that felt like I was pulling my hair, but eventually I got it to work just in time. However, when it came to testing I couldn't be quite as successful as my other groupmates since I had to email the invite to my testers and have them download it. While I could get some decent feedback it didn't help that I couldn't just hand them the game and they had to go through a process to try and test the game.
--------------------------------------------------------
377 Merge Dasher Sprint 2
During this sprint we were focused on setting up the basic components of the game so that we could be ready for our first playtest as soon as possible. I took on more modeling & texturing work this sprint to ensure that we had enough assets for our first playtest next sprint.
The first assets I started making were the roads. I wanted to make sure the dimensions for the road were accurate to how we wanted it in the game. I made sure that the road was 4 lanes because that's how it was drawn out by my designer and had 2 sides that were larger for houses to be on and maybe to have extra foliage on as well.
The next assets I started on were the obstacles that we are gonna place throughout the game. The 3 I started with were a cone, a jersey block, and an oil spill. I wanted each of the obstacles to have a different appearance and be pretty obvious to avoid. I made sure that the colors especially were accurate and that the overall shape of the objects was true to life. With the oil spill in particular I made sure to make it very reflective so that when it appears in-game you can tell it's oil and not something friendly.
The next set of assets I worked on after each of those was the 3 types of food that we had set up which were burgers, pizza, and Chinese. The models for these items were a bit of a challenge, especially the pizza box which has a slight lift to it to try and show that dimension as opposed to just being a box. However, the hardest part of this was definitely the textures. Trying to get all the different foods to have different textures for their paper material AND unique designs presented a challenge that I didn't fully expect to take place. I ended up hand-drawing the burger onto the bag which took a very long time to make sure it looked somewhat like a burger. I also tried to come up with a generic logo for the pizza box to show that it IS in fact a pizza box, which I think I did an ok job at. The best one I think is the Chinese takeout box. I took the pagoda image (which is a free-use image) made an alpha stamp out of it in Photoshop and used it on the box inside Painter. In the end, it wound up looking really nice even though the model isn't anything special. Overall pretty happy with how they turned out.
The final part of my workload this sprint was designing the house that the player would drop off the food at. I referenced lots of different low-poly house designs so that I could make a design that was simple and easy for us to have multiple textures of. I made it so that the house had slanted roofs and two subsections that were surrounded by a foundation/barrier. I also made it so that there was a front door and 2 different windows that would be visible to the player to indicate that yes, this is indeed a house.
Sadly I wasn't able to get the texture for the house in before the sprint ended. I don't think it'll be too long before I get that done though. We want the texture to be pretty vibrant and simple almost like Crossy Road, a game that we are referencing for our own as another endless runner in terms of gameplay and aesthetics (to a certain extent)
Overall this sprint went a lot smoother than the last one for me personally and since my team and I have learned what we needed to do to get the game playable, we are ready to keep going and maintain our pace until the end (assuming we don't have more problems). I'm excited to see how our playtest goes and figure out what we can add to improve our game even further.
-----------------------------------------------------------------------------
377 Merge Dasher Sprint 1
In Merge Dasher you play as an ex-Formula 1 Racer turned delivery driver trying to get your car back to it's former glory by collecting parts and getting enough money. I am taking on the role of the Lead/Producer of the team, trying to organize workflows for all of us and collaborate with the designer for the vision of the game.
This sprint was primarily focused on getting on the same page as my designer and trying to formulate Trello cards for the game and figure out who will work on what. From what I understand, our vision for the game is going to be based off games that are endless runners like Jetpack Joyride and Subway Surfers.
I personally didn't have a lot of cards this sprint because I wanted to collaborate with our designer and get the ideas he had down and set in stone so that I can properly make cards for all of us to take on in future sprints and get everything organized as well as we possibly can early on.
I was also sick for about a week of this sprint, making it hard for me to do as much work as I wish I could've, although I would say my workload was far from nothing. I set up organization in Unity, pitched ideas, actively collaborated with the designer to get on the same page about ideas and created a LOT of cards in our backlog that will help us get started, but likely with many more cards to go. `
I also was the one taking care of most of the feedback on our paper playtest, creating the google sheet that gave us lots of quality feedback about what players wanted. The biggest reassurance to us was the fact that people liked the endless runner, which is going to be the main gameplay loop of our game. One thing that does need to be tweaked though is the merge mechanic, since the way we had it set up in our paper playtest was virtually impossible to try and test on paper. I think that in future sprints, once we get our core gameplay down, we will have to readjust our merge mechanic and make it more engaging.
The lead position is something brand new to me, so I'm trying to figure out how to do work in this position since it is quite different than not being a lead (big surprise). I feel that this sprint did prove how hard it is for me as a lead to balance managing other people's workload AND your own. I'm ready to take on the challenge after this first sprint, but it is nerve racking
We were lucky with trying to set up unity for android in that we didn't encounter too many issues and it seems that the production of our game will go smoothly. We do have 2 different phones to test our game on so we can see the differences in trying to scale the resolution for both devices and just seeing how the game plays on both.
I created a basic runway in unity using primitives to try and get a picture for how our game would work in the top-down style we have planned for it. I wanted to test how the game would look on different devices and it seems to look pretty good, but I worry that the resolution differences in different androids might affect how we decide to develop the game and might be an extra hurdle that will make it harder for us to do what we want to do.
Comments
Post a Comment