CAGD 377 - Mobile Game Development
Blog Post 3
As of making this post, my groupmates and I have officially completed production on Baby Wars. while we are sad that it ended so quickly, we are very excited to see our game finished and for the amazing experience that we got along the way. In the last two sprints of development, we added a lot of art to the game and fully refined our mechanics.
Thinking back on it, we started and ended this development happy, things have been smooth overall and our teamwork and communication made everything fun and easy. We have never had trouble telling each other about obstacles we are having or ideas about improvements for the game. I do strongly believe that if we didn't have this openness, Baby Wars would have suffered and the quality of the game would not match that of how it is now. I am glad that my team was so open, and I hope that my future groups will have the same level of communication as this one.
I had a nice variety of tasks for these sprints, getting more into coding than with the other blog posts. Some of the things that I did included adding the slow, freeze, and frostbite baby, updating spawning to include more enemies at different spawn rates, having slows and stuns wear off, having enemies turn red and blue when damaged and slowed, attaching all of the sprites to the models, and having wave complete text appear and disappear after a wave is completed. Since this was the last sprint, everything had to be finished, so all of my tasks were completed, none of them incomplete or in progress. I did want to add small animations to babies when they shoot, but we didn't have enough time so it was left out.
These sprints did have obstacles, as I don't code much so it was tricky learning how to color sprites and use coroutines. The main issues I faced were getting enemies to flash red when hit, getting wave complete text to appear and disappear, and adjusting the enemy spawning.
The first problem that came was adjusting the enemy spawning. I had to change the enemy spawner because it included our broccoli and eggplant enemy, but not the carrot and brussel sprout. This was difficult just because I don't have much experience with coding enemy spawns and I write the first iteration so I didn't know where to go. The solution was simple, I just had to look through the script and understand how everything worked, then I just made two new public game objects for the carrot and brussel sprout, then changed the random number generator to include the new enemies. I made them spawn at different rates by having more numbers apply to more common enemies, with broccoli having three numbers, but brussel sprout only having one.
My next obstacle was getting the enemy to flash red when hit. This task would really help with feedback and was important to make an understandable game. Once again, this was mainly an issue because I don't code much and have never had sprites change color. At first, I wanted our artist to make red-tint sprites for this, and I would make different sprites appear at different times to show the damage. After researching, however, I realized it would be much better to make the sprites change color in Unity. This was much easier, and I was able to get it up and working without much struggle. This was a great obstacle to have because now I will have this knowledge and experience for future projects.
The last big problem I had was getting a "Wave Complete!" text to show up and disappear after the player completed a wave. This was also important for feedback, as a lot of players told us they didn't know waves ended so we needed something to tell them. This was an issue for a couple of reasons, the first of which was getting it to show up in the first place. I thought the best way was to reference it as a component of the canvas, but after asking my groupmates, I realized it's much easier to make it a public game object in the script. After that, I was able to make a coroutine to set active and inactive after a wave. The other issue was that it was blurry, and it made it difficult to read. The solution to this was just to use a TextMeshPro instead of simple text and it didn't mess with the code at all.
I actually liked the obstacles that I faced in these sprints because while not being too hard to solve, they all taught me valuable information that I can use in future projects. Overall, developing Baby Wars has taught me a lot about not just mobile development but development altogether. Making Baby Wars has been an amazing experience and I can't wait to use what I have learned in my next projects.
Blog Post 2
Since the last blog post, we have made great progress in taking Baby Wars from a rough idea to a polished plan coming to life. A lot of what we have been doing for the last two sprints is adding content and refining what we have in the game so far.
Like with previous sprints, development is continuing to run smoothly with minimal stalls and frustrations. This is partly due to the support of our team, it is much easier to develop any game with teammates who will cheer you on and lend a hand whenever you hit a snag. Thanks to this supportive dynamic and encouragement to ask for help, no obstacle lasts more than a day, which really keeps development going.
Even though we are already five sprints into the project, I still find myself learning more and more about developing a game and how mobile differs from PC development. While having a smaller time frame can make it harder to get everything done, I also feel that it is more freeing. Doing as much as you can in a small amount of time then moving on to the next project is a fun way to develop games, feeling like a long game jam. Because of this, mobile games also seem like a great way to hone your development skills, as instead of being in one genre and style for years, you can quickly experience several different genres, styles, effects, mechanics, and much more. Making small indie games gets the same experience but I also enjoy the ease of access with mobile games, being able to give them to friends and family very easily. In short, I have really enjoyed learning about the industry of mobile games and I hope to continue developing mobile games in the future.
I did have a good amount of work these past sprints, most of it being similar to previous tasks with some unique ones. I finished 10 points of work in sprint four and 8 points in sprint five, which does keep me on track for what needs to be done by the end of the semester. My tasks included making a super speed baby, pierce baby, and marksman baby for the speed tree, adding a slow mechanic, stun mechanic, knockback mechanic, and pierce mechanic for bullets, prioritizing the baby trees, adding a speedy carrot enemy, and making bullet destroy range based off of the baby instead of the world position.
My only incomplete but in-progress card is to make enemies blue when slowed. However, some tasks I plan to start for the next sprint include making enemies blink red when hit, having timers to make slows and stuns end, and finishing all the babies for the support tree.
Although development is smooth, there are still obstacles that we have to deal with, none of them were too difficult or delayed development too much but they were still nice learning experiences. The only obstacles that I encountered were making the bullet slow mechanic and getting bullet despawn range to be based on the baby.
When making the bullet slow, I first thought that the way to do it was to give the bullet a slow amount, then when it hits an enemy, the bullet will access the vegetable's speed and decrease it. This was a very difficult way to do it and that is why this was an obstacle in the first place. My way to solve this was to change how it was written, instead of making the bullet reference the enemy speed, I simply gave each veggie a new integer for slowed speed and switched the speeds when they come in contact with anything tagged "slow_bullet".
Making bullet range based on baby position was similar. Until this task, bullets would destroy at the same spot no matter where the baby was, so if the baby was up too far, the bullet would go nowhere. At first, I wanted the bullet to reference the baby's x position and use that for the range, but I didn't know how to reference the right baby or if my idea would even work. The solution that I found was to have the bullet reference its own x position when it spawns. As soon as a bullet spawns, it will record its x value in a private integer, then add a public value called "range" to it, and that makes the final destroy range. This way, bullets will have that range no matter where the baby is, and it will work if the baby is moved.
Even though these were small obstacles that lasted not even a day, they were great learning experiences. They taught me that you don't always have to code things as they would work in real life, such as giving bullets a slow that is transferred to enemies, sometimes it is easier to think of an alternate way to make the same thing. I will definitely use these lessons in the future and I hope to learn more as we continue and wrap up development for Baby Wars.
Blog Post 1
Throughout the last three sprints, I have not only learned what it is like to develop a mobile game, but also how mobile development differs from PC development, how your mindset changes, and what kinds of tasks are and aren't needed for mobile games. As well as this, I got to better learn how to work with a team and how to effectively use a team to make development faster without causing any unnecessary stalls. This is also the first group in which I am the team lead, which called for a lot of extra work and learning in the beginning. With assigning tasks, checking up on groupmates, and overall keeping the team together and focused, the team lead has many more responsibilities than the other group members. While it is tough being responsible for the team, I do feel that I am getting the hang of being lead and am looking forward to getting even better in future sprints.
So far, from the first day to now, development for our game, "Baby Wars," has been surprisingly smooth considering this is our first time making a mobile game. There have been minimal hiccups and everyone has been doing great work. The main struggle we have had so far was simply getting a playable prototype for the first electronic playtest that was do well to convey the concept of our game. After a few days of grinding, we got a game that we were proud to show and got a lot of incredible feedback from the playtest. Besides that bit of rush, Baby Wars development has been steadily moving forward and we are starting to see our idea really come to life.
While our sprints did go well so far, there were still a couple things that we dealt with that slowed down production here and there. The main issues we faced were not having a clear idea for the game and having a slow start for the electronic prototype.
Baby Wars was a simple and easy-to-understand idea, Plants vs Zombies with a merge mechanic and different units. With such a clear idea, we thought starting development would be easy, but we were wrong. Not everything was thought out and it led to us stalling production the first week to get a better idea of what Baby Wars would be. We didn't know how similar we wanted our game to be to Plants vs Zombies and we had to think not only about what to change but how to change it.
After a lot of brainstorming and discussing, we decided that this project is plus one design, so we thought it would be alright to keep a lot of the aspects of Plants vs Zombies and focus on what we knew we wanted to change. This cleared up our confusion and production has been smooth ever since.
Even with production going smoothly, we still hit the obstacle of not being on track to have a playable game by the first electronic playtest. For a while, we thought our game had everything it needed, and while it did have the core mechanics in place, it did not have enough restrictions and features to make it a playable and presentable game.
We learned the hard way that the only way to solve this problem was to work hard and grind out all the features we needed for the game. It took a lot of effort from all three of us, but by the time playtest day rolled around, we had a game that we were proud to show off, and like mentioned previously, we got tons of amazing tips and critiques that we have already used to the fullest in the back half of sprint 3.
So far, developing Baby Wars has been a great learning experience and a lot of fun. My groupmates are great to work with and I feel that I am doing my part to keep us together on the same page. These first three sprints have had their ups and downs but overall it has been awesome and I can't wait to continue production for Baby Wars in the next sprint.
Comments
Post a Comment