Looking back on a 6 week game development student project at SMU Guildhall. Analyzing the things that went well, things that went wrong and what was learned by our 3 person development team.
by Brian Applegate (Producer/Level Designer)
Mansion Raid is a 2D top-down Android tablet game developed by three individuals using Unity. The game was for a student class project. The entire project lasted about six weeks with each developer working on average thirteen hours per week on the project.
Mansion Raid is an exploration game in which the player must find and collect treasure by traversing a haunted mansion with very limited visibility and avoiding ghosts that are protecting the treasure. The player carries a lantern that only lights up their surrounding area. Players find gems around the mansion by completing simple rune symbol puzzles, which gives them more treasure.
Ghosts patrol along specific paths guarding objectives the player needs to reach. When the ghosts are in the dark, they are slightly visible to the player, showing up as wisps, which fade in and out. However, when the ghosts enter the light that the player is carrying, they fully appear, surprising the player. In addition, the ghosts rob the player of gems when they are in the light radius.
The team communicated the game vision well enough to work without having to ask time-consuming questions too often. The team talked through and planned the game adequately enough to achieve a shared vision of Mansion Raid. Having a shared vision allowed the team to work efficiently and create a cohesive, fun game. Without a shared vision, the team could have struggled to finish the game, let alone make it consistent.
Each member of the team was comfortable openly stating that they might need help or foresee problems. As it should be, open communication about technical difficulties allowed for foresight of problems and gave an opportunity for team members to help remove blockers before they even came into existence.
All team members had a give and take attitude for most aspects of Mansion Raid. Generally, no team members were too attached to ideas or work they were interested in. Overall, team goals were put as the highest priority over any individual goals. This helped achieve a shared vision for the game as well.
Asset organization and asset naming conventions were not followed tightly enough which led to issues later on in development. Too much time was spent searching for assets and figuring out what version of an asset needed to be implemented. An estimated 10 hours were lost searching and renaming assets.
Time estimation on tasks were highly variable throughout the project. Some small tasks took too long for what they warranted. While some large tasks took next to no time when they were estimated to take a long time. Having variable task estimation led to many game design adjustments and cutting of features.
Individual focus during team working hours was a problem throughout development. There were too many discussions about subject not relating the project. Many days, the actual task times filled out did not equate to that particular day. For example, if we met for three hours, sometimes the total task time for individuals was like one and a half to two hours. Not using the entire time towards development led to further game design adjustments, cutting of features, and extra team working hours.
Documentation is much less useful for a small three-person team. The amount of time updating particular documents proved to be too time consuming and not useful considering our team did not refer to them really ever again. With three people, the ability for every person to talk about design that is generally written in documentation and not waste the entire day is possible. Whereas with more members, it could take up an entire day for every person to get their ideas out and have each person listen.
Different specializations communicate in very different ways. Explaining things from multiple perspectives can help reduce ambiguous topics. Our team did a good job of speaking up when they did not understand something. Things that seemed clear to our programmer were not clear to our artist. Finding a balance and different ways to explain concepts quickly became a necessity and proved to be successful.
Organization of assets is important for iterative game development. Using an asset database to keep track of file locations, file naming, and file sizes can help tremendously. Also using source control to its maximum potential can save time in many different ways. An estimated ten hours of the two hundred fifty hour project was spent either searching for files or making sure team members had the correct version of a file.
Read more about:
BlogsYou May Also Like
