Sandman’s Apprentice Post Mortem
By Marc Mixon (Producer)
Sandman's Apprentice is a top-down 2D action/puzzle game developed for the Android tablet using Unity 4. The player navigates Ollie, the apprentice, through a dream world filled with hazards, puzzles, and nightmares. This game represents the effort of four student developers over the course of eight weeks.
What Went Right:
It was a pleasure working with Rukuan Yang (programmer), Bill Hood (artist), and Lauryn Gordon (game & level designer) on this project. Even though this was our first experience making a game, everyone brought a professional attitude to the table. We built a strong sense of team identity early by creating a logo for Wood Dragon Studios and personalizing our workspace. We all shared the goal of creating the best game possible in eight weeks. The team regularly went out to eat or spent time together outside of the development room. The rapport we built during this time helped insulate our team from the stresses that often rip apart development teams, leading to delays and sometimes cancellation of the project.
During pre-production the team was divided between pursuing a top down art style vs. an isometric view. It quickly became clear that we didn't have time to pull off a polished isometric style, so we opted to go with the true top down view. This allowed our artist to put more time into the environental art. Throughout development, our art consistently received high praise from testers.
Having a small team and working in a single 10x10 room allowed everyone to communicate easily. Everyone felt free to voice their opinions and other teammembers listened. This ease of communication meant every team member had a chance to make highly visible contributions to the game. Seeing your work in the final product is a great source of pride and fosters a deep sense of personal investment in the final outcome of the project.
What Went Wrong:
Missing the first milestone
We spent a lot of time discussing the game early on when we should have been building. Without a playable prototype you end up iterating in a void. When you fall behind in developement, you never really catch up. You either cut features or add to the schedule. We ended up doing the former since the latter was out of the question.
All of us were very new to the Unity engine. We had a number of challenges getting our prefab assets to work correctly. Sprites often lost their connection to the prefab when assets were uploaded to Perforce, resulting in extensive rework.
Using the SCRUM board
We were all new to using Agile and SCRUM. We didn't use the SCRUM board to prioritize tasks. This slowed our SCRUM meetings and required frequent discussion mid-sprint. It would have been a much bigger problem had out team been larger.
What We Learned:
Design discussions need to be timeboxed by the lead. Every discussion should also produce a list of action items and the person responsible for delivery of the item.
Check to see if your problem is in the "solved" universe
We weren't the first dev team to run across the prefab problem in Unity. We tried to research and solve it ourselves instead of asking other teams how they solved it. This cost us precious time that could have otherwise been put into polishing the game.
Use SCRUM to prioritize
How you order your tasks on the board is important. It saves time during SCRUM meetings to prioritize tasks during planning, and helps identify dependicies early.
Working with other students who had a professional attitude made the development process fun. The time we spent building a team identity paid off during the stressful periods prior to milestone deadlines. We learned to begin the problem solving process by asking whether or not the problem has already been solved. The essence of what our professors drilled into our young and impressionable minds can be stated simply: Scope and Polish.
Here is a link to our gameplay footage on Youtube: https://youtu.be/0uOtH30sZms