Project Olympia was an EA Maxis client project at the Silicon Valley Campus. While discussing the project requirements with them we learned that they had very few expectations for the final deliverable. However, they asked that we take inspiration from the project that they were working on at the time. They also requested a game with polish. Beyond this, there were very few limitations. And, while VR had been the suggested platform initially, they ultimately left this decision up to our team.
The first few weeks of the project was spent ideating and pitching concepts to our client. We began by drawing on the aspects we liked most from the Maxis experience that our client shared with us. We then brainstormed ideas, discussed what excited us as a group, and then fleshed out those concepts. At the two-week mark we shared three concepts with our client, and used their responses to help direct our final concept for the semester.
The concept we selected focused on creating characters that could be manipulated, molded, and deformed. We imagined them being slime or goo creatures and planned for the guests to have a lot of fun control over them. We were interested in the technical challenge behind this project. Our team was looking for opportunities to learn; with two programmers (new to graphics programming) and an avid technical artist we were interested in building our skill sets. The other three team members were very design focused, and slime seemed like a great opportunity to explore a wacky world full of interesting creative opportunities.
We were still interested in going the VR route, and molding and deforming in VR felt particularly powerful.The characters we could create from slime also seemed full of potential, with interesting opportunities for how they might interact with each other, the player, and the game world. Our goal was to create a game in which guests could play with and create slime creatures.
The Good
Over the course of the semester we found our groove as a team and enjoyed the discoveries we made about our world. There was a lot of good that developed in our dynamic. As already described, challenge was very important to our goals as a group. Even after all the major road-blocks we have encounter, the pay-off feels worthwhile. Although we have had to hack our way through fluid simulation, soft body physics, leap motion gesture controls, and strange NavMesh problems, as a team we have come away as a more creative, nimble team. Making the most of the available tools is an important skill. Beyond that, finding resources and seeking outside consultation contributed to our success. Accepting a challenge and continuing to push towards a goal despite the problems we faced was one of the best things we did.
Further, despite accepting the challenge, we also remained prepared for failure. We always had a back up plan as we worked on challenging technology. We developed the pieces of our game in parallel to keep from being left empty handed if one piece of the experience did not pan out. While our development across fluid simulation and character interaction was not always spread evenly, we kept moving forward with both. This was a good move on our part, as it never felt like we were completely dead in the water when one aspect of the project was moving slowly. It gave us the confidence to continuing with our challenges, even if the outcomes seemed unpromising. Although the fact that we developed in parallel meant that we faced some difficulties integrating all of the pieces back into one experience, it did allow us to take some important risks.
Another key choice we made in our preparation for softs was deciding to focus on polishing moment-to-moment gameplay and clarifying interactions. Leap Motion was very challenging as a platform. Many of the gestural controls that Leap Motion provides had to be refined or rewritten as we continued to polish. NavMesh was another uphill battle which we dealt with frequently. This meant holding off on implementing more until we had resolved our major bugs. And, it was a wise choice to do so. We needed to reach a point of stability before introducing more pieces. Further, the experience benefited from those updates and it allowed us to have something more playtest-able. The choice to slow down, and find stability was important.
The Not So Good
All that said, even though the challenges were good ones, they did come at a price. The fluid simulation plugin that we used, NVIDIA Flex, is a tech demo. While it looks very interesting and can do some pretty compelling things, it is not designed with VR in mind. It also built for looks rather than ease of use. While we managed to harness Flex to a degree, there was a lot that we were never able to control. Simple things like collision detection were for the most part inaccessible because of the computing power it would take. This meant we had to use quite a few hacks in order to change things about the fluid at run time. Using a tech demo was definitely a risk, and moving forward we would think twice before commiting to something so complex. Although we may not regret using Flex, it is important to recognize that it meant a significant portion of time was devoted to solving technical problems when we could have spent more time developing gameplay. Since a key requirement was polished play we should have balanced our energy more. Thinking carefully about where we wanted to focus our efforts might have kept us more aligned throughout with our high level goal.
Another aspect of this was that it took longer than expected for us to ramp up our game development and begin exploring gameplay. Even after halves we were struggling to forge ahead. We spent additional time returning to the design phase as well as and proving out the technology. We could have started earlier on making things. It was only after we built out our game that it became clear what was working from a gameplay perspective. Fail fast. As much as this point is hammered home throughout Building Virtual Worlds class, and throughout our time at the ETC, it remains a challenge to act on that lesson. If we had begun trying out gameplay sooner, we would likely have a product that flows more at this point.
And, the most solid design work doesn’t happen in blue-sky, it happens through playtest and iteration. We could have trusted more in that process and removed some of the pressure from ourselves to design the game to completion. We spent quite a bit of time fleshing out things which could never be implemented. In part this was a struggle to figure out how to scope ourselves. It was difficult to know how much we could commit to, and, as we are working at a more relaxed pace this semester, we could have been more prepared to descope. The other piece of this was expecting too much of our initial designs. We were concerned about it not being enough, or lacking robustness, or being the wrong direction. At the end of the project, our product looks very much like some of the designs planned during our first discussions. Not being afraid to go with our gut, might have eased our journey to where we are today.
& The Lesson
This semester we committed to challenges which paid off in many regards. Challenge helped us grow as a team and has allowed us to make our world and its creatures become a little more alive. Trying our hand at these complex problems came with a big risk-reward factor. But, for the most part we planned ways to mitigate those risks. We needed to remain focused however, on the one project requirement, which was polished gameplay. Choosing where to put the most energy over the course of a project is important, and it should reflect the project’s goal. Committing to a challenge is good, but as much as possible that challenge should align with the focus of the project.
Towards the end of the semester we began to find our groove and were able to make leaps and strides as we integrated the many pieces of our project. Giving ourselves the time to pull these pieces together, to build and rebuild, was important. At times, the going was slow and it felt like we were taking two-steps back and one-step forward. Having space to refine and stabilize helped lead us to reach a point of forward momentum. Beginning that process sooner could have allowed for a more steady trajectory. Building piece by piece was useful for our pipeline initially, however, the longer we waited to integrate those pieces, the more rework they needed later. Starting simple and ensuring the core functionality is rock solid, could allow for more steady progress.
The other benefit of that approach is having more time to iterate on design. While we did a significant amount of designing up front, much of that work had to be set aside as we began to understand the volume of work that we were capable of doing as a team. Focusing our energy earlier on putting pen to page, or in our case asset to scene, could have allowed us more space to explore design and iteration during the second phase of development.
While we continue to be excited with the work we have done and are happy to find ourselves with the world we have created, there were times were we could have eased the process for ourselves. Ensuring that the project challenges were aligned with the ultimate product goal is key to a successful project. As is leaving plenty of space for iteration and just making something. Trusting in that process can feel vulnerable but ultimately it makes for a cleaner experience with better design and more polished gameplay.