For CAGD 377 Mobile Game Development I worked with a team of three to make an idle game with a plus one mechanic of physics-based puzzle solving for android mobile. On our team we had Kade, our lead programmer, Jen, the lead artist, and me, who worked on a little bit of everything. This project was completed to include 5 different "prestige" levels and several upgrades. We had plenty of art to fill the game with to complete its look.
What Went Right?
Team Work Ethic
This team managed to pull together a really fun game with a smaller amount of people. We had lots of art content, mechanics, and functioning levels. This was mainly due to our work ethic and focus. Our team's producer did a great job delegating tasks and ensuring we were working towards something feasible and important. This meant that every sprint had lots of quality work for us to show off frequently. Every sprint we would complete a new feature, a new set of art assets, and have a good scene to show these mechanics off.
Team Adaptability
Additionally, there was a couple of instances where our team switched gears and started working towards something new. This game's pitch started out as a idle game with a plus one mechanic of turn based combat, but we finished deciding to replace the turn based combat with puzzle solving with factory optimization. This decision was made relatively late into our development cycle, about two thirds through. While this easily can mess up a team's work rate and direction, our team was entirely unaffected and this was due to our communication and willingness to cut content and act quickly.
In order to make this decision we had a long discussion about pros and cons, wants for our game, and analysis of our playtest reports. We were finding that playtests were enjoying the problems they would encounter by pushing our physics too far, rather than the actual elements we wanted them to focus on. Instead of becoming discouraged and trying to create a sense of fun that didn't exist, we expanded on these elements and simply followed the fun. This decision was made, and we quickly cut content and added new work so that we could quickly switch gears. This overall worked well, and we had a positive reflection in our playtests after this moment. That decision required a trust in the agile process as well as a dedication to finding fun, rather than trying to create it out of thin air. All of our team members had pieces of content that needed to be cut due to this, and everyone acted professionally rather than discouraged. This ultimately led us to a better outcome and allowed us to work on things players cared about, without the worry of an entirely new feature we hadn't had enough data on from playtesting.
Comprehension and Problem Solving
Towards the end of the project all team members started seeing a increase of tasks that weren't attune to their specializations. Artists started to have to work in engine, and programmers had to balance more and work on UX. This team didn't falter in the light of this. Everyone took it upon themselves to solve problems on their own, and when people needed help, members mostly were available to give a hand. This ability to work together on individual tasks that might have been out of our comfort zones allowed us to get lots of work done towards the end and achieve more than a functional game. Two days before our deadline we were mostly focused on balancing and making the game more fun, rather than intense bug-fixing and last minute solutions.
Strong Sense of Comradery
This team also grew very close with each other so that we weren't just peers but also friends. This meant we would help each other out frequently when problems would arise. Additionally our friendship meant we would frequently compliment each others work and get excited for each other. This didn't just help us complete work happily, but it also pushed our work further with the motivation it provided. This just brought a level of soul and positive energy to everything we were doing and it shows in our game.
Experimental Workflow
Our team also made sure to include random ideas each member would have for the game, meaning all of us were allowed to get excited for pieces of work and potential additions to the game. Lots of these ideas were cut, but the ones that made it in without a doubt improved the entire course of our game. For example, the first conveyor belt I built used physics in Unity to move along boxes on top of it. I told the team I actually liked that better than what we had planned, which would be a simple transform moving a box across a line. The team agreed and we stuck with it. So this openness to new ideas started what was a huge element of our final game.
What Went Wrong?
Too Much Content
This team however, did have some things to improve on, like with any project. The most clear thing was a very heavy focus on art towards the beginning of the project. We ended up creating art assets for things that wouldn't even be in the game too much. While it was helpful to knock out art, which takes so long, early in the semester, it might have been more smart to create art for things already functioning in the game that we knew for sure would be around. This adjustment was made later into the project when it had been too late. A small amount of content was cut, and the time spent on this content could have been spent in engine building fun mechanics.
In the future I would want to make sure everyone that is making art is working on things that will definitely be in the game. Lots of changes are made with agile development, especially if your goal is to make a fun game for your players. You cannot count on your plans not changing, and so art must be carefully watched. If that is difficult I would recommend artists staying in-engine building experimental functions and plugging things in towards the beginning as they wait to create content.
Time for Programming
A massive feature for this game did not make it into the final build due to the amount of time it took to plug things into the engine. The time spent to make the cut content, as said before, likely could've been used by me to help our programmer, Kade, focus on larger systems in the game, rather than bug fixing. While it was Kade's job to fix scripts and systems in our game, these fixes took up too much time at the end. If I were there to help him make levels and systems earlier in the development cycle Kade likely would've had more time to finish a mechanic that would have made our game much more fun.
In the future I want to make sure I am working on things that will definitely be in the game. If I am not I will bring it up with my producer and recommend other things for me to do. I suggest other producers do the same. Additionally, all producers should make sure finished features are "plugged in" in order for work to be verified as complete. Otherwise, a huge amount of work is build up and unfortunately lands on other people's shoulders.
Attention to Assignments
At two points in our development this team missed a deadline that could have cost us a grade. These were simple assignments that took minutes to complete, but they were critical, such as posting documents in the right places on our school's blackboard to mark an assignment as completed. These small things were known by everyone in the team but no one would speak up to remind anybody about these. There was a lack of communication and focus on these types of things, and in the future it would be helpful in the future to have producers delegate these tasks and perhaps post the class schedule somewhere clear, such as in the Discord group chat a team uses. All members should be pinged daily with reminders for what is due and when, so that things like this don't happen.
Comments