Avian Apocalypse is a 2D platformer/shooter created by a team of 4 developers at SMU's Guildhall over the course of 8 weeks.
What Went Well
Shared Vision
As mentioned in the introduction, the team had only eight weeks to produce this project. That meant we did not have time for a lot of rework. To mitigate this, the team spent time in the concept phase brainstorming, testing, and whittling down our collective ideas until we came together around a common vision. Evidently, we were very bird brained at the time of the project’s conception, but we eventually coalesced around the idea of whimsical zombie shooter that was both fun and challenging at the same time. Our shared vision of the project allowed us to work in concert in our separate disciplines without stopping every five minutes for guidance. This allowed us to run smoothly from checkpoint to checkpoint with very little unintentional rework.
User Feedback
Personally, watching others play a game you spent many long nights working on is both gut wrenching and extremely gratifying at the same time. It is petrifying when you are watching a player do something completely unexpected (sometimes undesired) or when they just are not connecting with the game. However, when a smile is on their face and they connect with the game it is instant confirmation and worth it. With that said, having user feedback early was essential in finding the fun in the game. The team did a great job at capturing the feedback, filtering it, and making changes accordingly.
Most of our feedback was obtained through observed play testing session. Upfront we let the player know that they could say anything they wanted to about their experience at anytime but also warned that we wouldn't answer any gameplay related question until the end of the session. We were very candid about the fact that we wanted to know what they thought was good and, more importantly, bad about the game. This set the expectation to hear both and bucked the trend of only saying what was good. After the session, each tester completed a feedback questionnaire that prompted them to answer questions about gameplay we needed more information on. We then compiled the data to see if there were any common themes. If any common themes or glaring problems were identified we made correcting those things a priority.
Communication
Good communication between team members proved to be the most important production multiplier. Being a small team, we were able to cram all four of us into a small office. While low on privacy, it proved to be high on productivity. When one of us had questions, the subject matter expert answered those questions on the spot. Of course, we were unable to do all of our work together in the office and many times, we worked remotely. To minimize the impacts of this, we planned our heavy lifting during office hours when all hands were on deck and left the minor stuff for us to clean up on our own.
In addition, we maintained high comradery through a steady stream of poultry related jokes and deep philosophical debates like, “what came first, the Zombie Chicken or the Zombie Chicken Egg?” (By the way, the Zombie Chicken did indeed exist before the Zombie Chicken Egg in Avian Apocalypse.)
What Went Wrong
Feature Creep
In the immortal words of the great Charlton Heston in the Planet of the Apes, "You finally really did it. You maniacs! You blew it up!" As Mr. Heston implied, indeed, we did it to ourselves, we are our own worst enemies. At the beginning, we were very smugly impressed with ourselves at how well we estimated our time and the fact that we were even ahead of schedule. I am sure many seasoned producers know where this is heading. We ignored our better judgment and voluntarily elected to add more functionality and features to the game than previously planned. While we estimated well initially, our estimations on how long the additional content would take was woefully inadequate. One of the big reasons for inadequacy was the fact we did not have the time nor did we make the time needed to weigh fully the risks before committing to these features as we were in full production. This led to unexpected bugs and conflicts between new and existing systems within the game. We managed to pull it off but we were definitely feeling more pressure than we should have been.
On The Job Training
Most of us had zero experience making games before this project and only minimal experience using the tools available including the Unity Engine. Starting this project seemed the equivalent of a swim instructor throwing a first time swimmer into the deep end without floaties on. Our learning curve was steep and the time we spent researching our tools took away from production. This experience definitely left our team understanding the importance of being able to learn new tools quickly.
Many Hats and Just One Head to Wear Them
Having such a small team definitely had its perks but its biggest drawback was the amount of hats our four person team had to wear at any one time. My official title on this project was team lead with the not so sub “sub-titles” of producer, game designer, and lead level designer. Any one of those jobs could have taken all of my eight weeks and then some if done correctly but that was not an option. The experience definitely left me with a healthy appreciation for the importance of each of those roles.
Lessons Learned in no Particular Order
Test Early, Test Often
The importance of testing and user feedback through every phase of production cannot be overstated. It proved absolutely essential in getting Avian Apocalypse to a playable and, more importantly, enjoyable state. My only regret is not having more time available for playtesting.
We also learned the value of testing within our market to find the right feedback. All feedback is appreciated but not all feedback is helpful. While we did not discredit feedback from those outside our target audience, when given two drastically different opinions from our target audience and those outside, we erred on the side of our target audience.
Finding our market was also a challenging but critical part to the feedback process. We narrowed our market first buy development platform and required accessories, which was PC and the Xbox360 controller. From there, we looked at the demographic areas of overlap between the Zombie, Indie, and the 2D market. This gave us a target audience to focus our gameplay and humor around.
Expect the Unexpected
Unfortunately, none of us are all seeing or all knowing. Given more time, we could have planned more before committing to more features but optimists will be optimists. With that said, plan for the unexpected. If we had allocated additional time for debugging new feature integration upfront then we would not have been under so much pressure toward the end of production. If you over scope on anything, over scope on the amount of bugs that will need to be smashed. This allows for some wiggle room if bugs to pop up and more time to polish the game if none arise.
First Things First
One of the key ideas behind iterative design is adding value to the product quickly over successive staged deliveries. This means tackling the features and the dependencies that add the most value to the game first. This is something we were on course to do but side tracked ourselves away from those core features through the allure of bells and whistles. Had we completely finished our core features first we would have had a better idea of the amount time we had available to put towards additional features.
You May Also Like
