Introduction
Team Puppetineering is a CMU Entertainment Technology Center (ETC) project team with the goal of creating a virtual puppeteering experience. Our team was formed in January 2011, and spent 15 weeks creating the experience, which included defining the goals, research, and development of the system.
Our client was the ETC and the deliverable for them was a short interactive experience for the first annual Building Virtual Worlds Festival. We ended up building a virtual puppet using Quasi the robot. Quasi has gone to represent the ETC on several occasions and so the ETC thought it would be great to use him as our character.
What went right
1. Team work
The team came together to create a great experience. Never was there a problem with ego or people outright refusing to contribute to the project. The great teamwork within the team allowed us to move forward faster than if we didn’t have this type of synergy. Similarly, because of the great teamwork, when we needed to work extra hard, everyone pitched in to make the project successful. This made working on the project a pleasant experience.
2. Goal and Scope
The goal of the project was clear from the beginning and we managed our time to meet the goal. The scope was not too outrageous or too simple. Having a clear and manageable goal from the onset of the project allowed us to utilize our time well and made it easy for us to know when we needed to put in extra hours.
3. Research
We spent time doing the research that needed to be done in order to understand how to create a good scripted experience. Going to Disney’s California Adventure was invaluable. We went to see Turtle Talk with Crush four times in a row and gained some great insights into what makes that interaction work so well. We also met up with and spoke to the people who created the original Quasi and they gave some great insight into what makes him work as well as papers and documents to help with understanding Quasi’s character.
4. Iterations
Our product went through several iterations and even now I’m sure there are things that we could have done to make it better. We got to this level of polish only by iterating over and over and over. One thing we learned was that being able to iterate, test and iterate again on a daily basis was essential to making the product work as well as it does. Every day there needed to be a build of the project that worked and there was and people would be able to talk about it and point out things that could make it better.
5. Well defined roles
From the onset, we defined our roles pretty well. We have our lead programmer, our modeler/animator, our texture artist and our sound designer/programmer. We kept these roles constant throughout the duration of our project and made sure that each member was responsible for their own part as well as making sure other parts were as good as they could be. Again, the daily feedback allowed us to be open about each other’s work as everyone was working together to create something great.
What could have done better
1. Not knowing pipeline
We went through several changes and updates to the pipeline that we should have tested earlier. Our team was not very experienced with animating and we were constantly going back and forth with the rig and the model and trying to make it all work in Unity3D. Looking back, it would have been better to concentrate on getting very rough animations done early on and finding these issues earlier. There would have been more time to polish the animations and get them working.
2. Goal oriented project
Our project was focused on making the product. We almost focused too much on making the product, as we didn’t consider expanding the product or making it easier to add and change things. We were almost over-focused on creating the product and reaching the goal. In the future, we may try to finish earlier or start having conversations about what we could do with this earlier in the semester.
3. Failed to submit research paper
We were working on a research paper that would help other people figure out how to create great interactions. A paper like this would have helped us create a better product and hopefully would have helped us avoid some of the pitfalls that we encountered during the project. Failing to create this paper wasn’t horrible, but it means that future teams that wish to recreate a similar experience may end up running into the same hurdles as we did.
4. Research phase was too long
We did a lot of research for this project and even halfway into the project we had a few unanswered questions that would require us to investigate further. We also did a lot of research on the experience. Though the trip to Disneyland was invaluable, it would have helped us more if we were able to go earlier in the life cycle of the project.
5. Didn’t play with product on a daily basis soon enough
We eventually got to the point in the project when we were able to play with the product on a daily basis. What was important was that every day we were able to make suggestions and changes to the product. For us, we didn’t get into this groove until later and it would have only been helpful to us if we started testing as soon as possible.
Conclusion
We were lucky that we had almost free reign of what we were able to do. In the end we chose to meet the projects goals. In hindsight though, we could have created a more customizable solution and utilized our time more efficiently. Moving forward, the big takeaway is to iterate as soon as we can so that we will be able to find the problems sooner and get more done.
Data Box
Elapsed Time: 15 weeks
Team members: 4
Platform: Windows
SDKs: Unity3D, FMOD