Student Postmortem: ETC's The Winds of Orbis

By Seth Sivak [06.19.08]

 The Winds of Orbis: An Active-Adventure was a semester-long project by seven students at Carnegie Mellon University's Entertainment Technology Center. One of the unique aspects of the ETC is that student teams are allowed to pitch potential projects, and this is where Active-Adventure started.

The goal of the project was to create an exercise game for kids ages 7 to 12 that utilized the Nintendo Wii remote and a dance pad. We wanted to build a game that would have intuitive controls, an immersive world and an in-depth story so that the players forgot they were even exercising.

The team really felt that the project was a success. We were able to create a full tutorial level that involved several different types of gameplay and a touch of our greater story. The game has been tested with close to 300 children with raving success and the project has been pitched again to continue in the fall semester.

What Went Right
1. Friends do what's best for the project. From the beginning, we knew how critical it would be to unite hard working and dedicated students from a wide range of backgrounds to work on the game. Luckily, we got together a team of seven of us, all of whom were passionate about the nature of the project from the start.

It's true that each individual team member has strong personal talent, but the cumulative effort of all seven has led to something greater than we could ever imagine on our own. Expectations and roles were clearly communicated from day one. For example, two of the artists on our team were very strong at character modeling, but we were in need of an animator and environmental artist. Despite their ability to excel in an area that they may have preferred to work in, they understood where the team needed their efforts focused for the semester. The result was incredible contributions.

Each team member would send a nightly email noting what they did that day, what they planned to do the next day, and any problems or concerns they were having. Along with bimonthly scrum meetings, this helped keep everyone focused and accountable for individual tasks.

Finally, we are all really are great friends, which helped us work together to design the game. The entire team had a hand in the design and because we were all working together, the best ideas were the ones that made it into the game.

2. Designed for movement. We developed on the PC using a Bluetooth adapter and a managed Wiimote library that allowed us to utilize most of the features the Wiimote has to offer. The dance pad was run through PyGame and is USB compatible. These two pieces of hardware presented a serious challenge to the team because we knew that the controls would be the most important part of our game.

The controls for any game are vitally important, but in an exercise game they take on a whole new level of significance. To find the control scheme that would work right for us, we researched all sorts of different Wii games and dance games. It was important to make players feel like they were controlling the characters accurately so their interactions with the world feel important.

The dance pad has never been used for much more than dancing and rhythm games. It was important that we design the interaction to reflect an adventure game and that we immediately break the notion that our game is anything like Dance Dance Revolution.

We decided to reorient the dance pad in a diamond shape and clearly give the player a place to stand. This idea of having a "home" on the dance pad makes the players feel comfortable with the controls early. From there we put all the combat related steps on the front of the dance pad and all the movement related steps on the back.

 Nintendo created something amazing with the Wiimote. Gamers and non-gamers alike have found remote both intuitive and fun. We wanted to use it to our full advantage, but not the point of having the game feel gimmicky, which is a complaint about some of the games for the Wii. We decided to use the handheld controller sparingly and to attempt to make the motions feel as intuitive as possible.

In the end, we all agreed that the controls were the main reason The Winds of Orbis is so easy to pick up, helping the young players feel comfortable immediately. During our play test sessions, we were constantly surprised by how quickly the children mastered the more complex moves and how easily they remembered the actions they need to do. We never once had anyone complain that they were exercising, and to us that is the ultimate success.

3. Iterations focused on one aspect. Throughout the project, the team remained open to experimentation. Because we were essentially doing research on the feasibility of Active-Adventures, it would be important to try as many different gameplay mechanics as possible -- but we really didn't have the time to do it all.

We knew early on that in order to create a fun gameplay experience, it would be important to select only a few design ideas and follow them through really well.

The core dynamic was going to be a combat system, which would give us the best chance of creating active movements that would appeal directly to our core audience. During the first third of the semester, we focused only on combat and making it as fun as possible; then we continued to refine it until the end.

Focusing on just combat really helped the team to prioritize and share a common goal. We spent countless hours developing combat mechanics. We tried several different ways of inputting the combat moves, as well as combo-style systems. The final implementation is a very intuitive and fun mechanic. It's built around three simple punches, though players love to explore different ways of using them and enjoyed the variety of the different interactions.

Taking time to focus on a single part of the gameplay can seriously benefit the overall experience.

4. Ten play test sessions, new blood each time. As soon as we entered production, we had numerous play tests scheduled -- one before we even had anything playable! The schedule motivated us to get a prototype up and running quickly.

The first demo lacked any art but did a terrific job of giving us (and our earliest play testers) a feel for the concept. This was crucial: Because the Wiimote and dance pad had not been combined in an Active-Adventure before, we needed to see if we could design a user interface that had the potential to be fun.

Throughout the three-month development cycle, we conducted approximately 10 play tests with more than 300 kids. For each session, preliminary data was gathered (age, sex, game preferences) and a post-play interview was conducted. We compiled all the feedback and made changes to the prototype as necessary. Using new testers for each build was important to ensure that each tester was new to the experience.

Play testing early and often kept the blinders off of our team. We discovered things we never would have seen on our own. It was also one of the most rewarding times for the team because it gave us a chance to see the children laughing and smiling while playing our game, which further motivated us to make a great game.

5. World of feedback. The world of Orbis, where the game takes place, was built around the idea of the player making an impact on the environment. To encourage the sort of active play and athletic movements required to effectively play the game, we adopted a philosophy of "juicy feedback." The idea of juicy feedback is to have the player do something relatively small in the real world, but have that action make a large impact in the game world. For example, when the player punches in the real world it does not take much force, but the in game character can knockdown entire walls with a single blow.

The art style and the general feel of the game draw the player into the experience. We worked very hard to create characters and a story that made sense, given the active nature of the game. Children loved the animalistic nature of the main characters and the cartoon-style animations, enhanced by our bouncy physics system.

One of the biggest problems that people, children especially, have with exercise is that they receive little to no feedback. It's difficult to gauge the impact of a workout (unless you're on a high tech exercise machine), and often people feel that they are not seeing the results they want for the effort they put in. We worked hard to give feedback to the player so that Orbis is a fun and rewarding place to be active in.

 What Went Wrong
1. Quantitative workout data. We are attempting to create a new genre -- games in which players get a workout while exploring, fighting, and solving puzzles (more game-like than exergaming). One of our goals was to solicit the help of a local medical expert to get data on the workout potential of our game. The problem we faced was that we did not have anything testable to give him or her until the semester was almost over.

To our credit, a meeting was scheduled with doctors at The University of Pittsburgh Medical Center before the semester even began. While they applauded the thought of using video games in a novel way to lose weight, they admittedly had trouble providing us with specific advice. Still, we did have access to a few experts in exercise physiology, and they corresponded with us throughout the semester.

Unfortunately, because of the large amount of game development and play testing we conducted, we never found time to actually transport our game to a medical lab to test it empirically. This handicapped us with respect to providing indisputable evidence that Active-Adventures helps kids lose weight and stay fit. In the near future, we hope to partner with the medical center and complete these tests. The entire team is excited to see the results, as they will likely impact future development.

2. Scope and cramming. Scope is always an issue in game development, and as much as we all got along, all seven of us came into the semester with different perspectives on how the first Active-Adventure would be built. To make things more difficult, most of the ideas were phenomenal. How would we decide what to focus on? Or would we simply start rapidly building, including as many ideas as possible?

We wanted to create several levels with a large amount of varied gameplay. This became our list of the "coolest things" in the game. It was impossible to cover the entire list in a single semester, and a challenge to actually try to prioritize the list.

To alleviate this problem, we tried to reuse work we had done before and also attempted to streamline our pipeline as much as possible. For example, we efficiently made the environment art and enemy art assets modular. This allowed us to create unique enemies and areas in a resourceful way.

At the end of the semester, we had to give a presentation about the project as part of our class assessment. We learned a valuable lesson: before a final presentation, perfect and polish what you have rather than add new features. By the end, we pilfered all our time adding features instead of focusing on important tasks, such as rehearsing our presentation. While one of the features was admittedly cool-looking (although not truly complete), another took dozens of hours to implement and wasn't even included in the final presentation.

The day of the final, we felt rushed and hectic as opposed to calm and collected. As a result, some minor issues arose that threw us off our game. An important texture was missing from the demo and much of the verbal delivery was rushed or unsure. While our ambition was admirable, we would have allocated most of our time to polish and perfecting our existing demo before finals.

3. Details. Everyone on the Active-Adventures team was relatively new to game development and thus had difficulty judging how long it would take to implement certain features. We ended up spending large amounts of time working on features that in hindsight weren't highly important to the overall game. This hindered our overall progress, especially in regard to a section of a level we call bullrush.

Toward the middle of the level, there is a bridge that the player crosses by sprinting to the other side. We wanted the players to run in place for this part of the game, but in order for them to not think about how much exercise they were actually doing, the level needed to be amazing.

The time we spent developing this particular mechanic swelled, and other important features continued to slip lower on the priority list. It seemed like every problem we solved with the bullrush would create several new ones.

As a lesson for the team, we all wished we had had the experience to better gauge how much time it takes to build different aspects of the game.

 4. Rapid prototyping. As mentioned, we had a rule among the team that every feature could be redesigned if someone came up with a better idea. This became a large issue as our game continued to grow because it was incredibly difficult for us to build the game and design new features simultaneously. We ran into a number of headaches, especially on the programming side, where better design earlier on would have made all of our lives much easier. It's obvious that this sort of problem is common in the industry because ideas change all the time; we just felt that having more design laid out earlier would have helped.

We got into trouble when we started changing the way we did collision detection so that the player could pick up and throw objects around the world. We did not design our collision system to handle this sort mechanic, so it was difficult to force it to work. We ran into problems with the collision system on several more occasions when we added in climbing and increased the speed of the bullrush.

The goal of this project was to create a proof of concept, so it's reasonable to say that if we were to develop a complete game, this problem would likely become a smaller issue.

While having the freedom to change design ideas after the groundwork has been laid is an awesome ability, it comes at a very high cost. It will be important in the future to always be thinking about the next mechanic or related mechanics that could be put in later on so that we all have a better understanding of how to build the game.

5. Sound.
We lacked a true sound designer on our team, and while we were lucky enough to have an excellent composer, most of his time was spent producing.

All the sound effects and music were put into the game in the last two weeks of production, which was very challenging. We were not prepared to handle debugging all the sounds, and we truly underestimated the amount of work it would take.

One example of this was with the footsteps of the main character. We had serious performance hits due to the way we implemented the footsteps the first time and therefore needed to remove them altogether. When we had a chance to try and put them back in with a new system, it was during the final week of work before the presentation. We ran into similar issues with the dialogue sections. They were implemented so late that we really struggled to get all the testing done to ensure they worked correctly.

Overall, the sounds in the game came out very well, but it would have been much easier had we started earlier in the semester. Sound is a very important part of any game and it is often simply pushed aside for later. The entire team learned the importance of getting sound in early simply to give time for testing, but to also to get feedback from play testers.

We Can Work it Out

One of the major goals of the Active-Adventure project is to bring the idea of a new genre to the industry and inspire more studios to create active games that are not sports or dance related. We hope that this game shows just a taste of the potential for active games and pushes developers and gamers alike into thinking about being active.

Seth Sivak is a graduate student at Carnegie Mellon's Entertainment Technology Center and a programmer on The Winds of Orbis: An Active-Adventure. He is currently a summer intern at Walt Disney Imagineering in Glendale, Calif. More information can be found at the development team's web site.


Game: The Winds of Orbis: Active-Adventure
Development team: Seth Sivak, programmer; Zikun Fan, animator and artist; Garth
DeAngelis, producer and composer; Ryan Hipple, programmer; Sean Kwon,
character modeler and texture artist; Bard McKinley, designer and
concept artist; and Nathaniel Morgan, environmental artist

Developer: Active-Adventure, Carnegie Mellon University Entertainment Technology Center
Number of Designers: 7
Length of Production: 3 months
Final Presentation: May 9, 2008
Platform: PC (Windows only)
Software: Panda3d, Maya, Photoshop, 3ds Max, Garage Band, Microsoft Visual Studio
Hardware: Dell Precision Workstations
Machine Project Size: 80MB

Return to the web version of this article
Copyright © UBM TechWeb