Content with Hours:
Playtests and crunch time! This week was the busiest yet,
another game I’m working on, RGB went into crunch time, so I spent the weekend
until early Tuesday working on bugfixes and integration for a beta. That
being said, I still managed to get a few things done for Alien Arcade this week
Firstly were the playtests; I organized with the other
section’s Team Lumpy Labs to host a joint playtest for both of our games at the
motion base. Due to a few miscommunications however, we weren’t able to get
enough playtests done, and so I scheduled for another one (with a fair amount
of help from Joe Cory and David!) to get more playtests and find motion base bugs
(3 hrs)
Secondly, I did a bit of sprucing up on our sell
presentation to reflect our latest build, and added a few more slides and talking
points (1 hr)
Finally, I made a few quick fixes on bugs we found from
the motion base and tried to make the instructions for a few of the games a bit
more coherent (1 hr)
Content Positive:
- Got a lot of feedback
from the playtests
- Fixed a few minor bugs
Content Negative:
- Didn’t have much time
to work on the project due to RGB
Total Time Spent: 5 Hours
Personal
Post Mortem
Overall,
this project proved incredibly draining. Most of the team and I were able to keep up
with the project in the beginning, however the constant barrage of documentation,
playtest requirements, and pressure to polish and add content while still keeping up with other
classes took its toll on the team. Towards the end of
development things started becoming strained between a few members due to the
stress but we still tried our best to put out a decent game.
What Went Right
1. Teamwork
As our team grew, we realized early on that we would need to change the structure of our team hierarch. To that end, I retained position of project leader, with John leading the programming team, and Angela taking charge of the art team. This proved to be a more efficient structure, especially for the artists as members were always clear on to whom they needed to speak to in order to get a task complete or a feature/art implemented. This also helped to ensure we did not repeat the mistake of the last cycle whereby members were unclear as to who was supposed to complete certain tasks resulting in the same work being done more than once.
2. Content Generation
Despite time constraints and a few extenuating circumstances, the team actually managed to create more content than expected for this cycle. Halfway through the term our goal was to finish the project with roughly 16-20 mini-games; however we managed to finish with 22! One of the main reasons for this was having a dedicated programmer for functionality this cycle. Last cycle, functionality was done mostly by David and I. As a result, their ability to complete games was slightly hampered, and bug-fixes would be solved inefficiently as both programmers would occasionally work on the same problem unbeknownst to them. For this cycle, functionality was left entirely to John, who managed to complete all his tasks and still have time to implement a mini-game or two. Additionally, our larger team size allowed us to work on more mini-games simultaneously, naturally resulting in more games being created.
3. Documentation
In the previous cycle, most of the documentation was handled by David. For this cycle however, we managed to get more people on documentation, and so much more documentation could be done on a more detailed level. Due to the democratic process in which work was split up, not only did we ensure that no one member was overworked, but that each member got to work on something they actually had experience in or personally wanted to oversee. This proved to take a huge weight off the team’s shoulders (especially David’s) as we had the benefit of having more fair and even workloads while still being secure in the knowledge that all tasks would get done by the appropriate deadline.
What Went Wrong
1. Playtests
Playtesting was a more significant part of this cycle, with a much higher volume of playtests required for the game this time around. Due to the nature of booking the motion base as well as the necessity of 2 Xbox controllers and at least 2 players, gathering playtests for Alien Arcade has always proven difficult. While we managed to scrape up enough testers to meet quotas, each playtest cycle proved challenging to say the least.
2. Time Estimation
As a fair amount of our team members were in their senior year, enrolled in multiple production classes, or both, many members suffered from large workloads for this quarter. As a result, underestimating the time taken for one of our numerous deadlines would cause a serious setback, requiring no small amount of work to catch up and get back on track. As we are still fairly new to game development, these underestimations happened frequently enough to become a recurring problem throughout the project.
3. Clarity
One recurring complaint we received about the game was a lack of clarity for a few of the games. Due to the hectic pace of the game and our large library of mini-games, creating consistent, clear and concise instructions for each mini-game proved a persistent issue for the game. While the game now features a significantly more readable and consistent HUD complete with concise controls and instructions, we were still never quite able to figure out how to reach the level of clarity we wanted for every game within the project.
Lessons learned
• Documentation can be very helpful in keeping track of goals and progress
• Setting aside time to test games is just as important as setting aside time to develop them.
• Team synergy can have a significant impact on morale
• Increasing team sizes eases workloads, but can make team management significantly more complicated
No comments:
Post a Comment