Get the latest Education e-news
 
  • Student Postmortem: ETC's The Winds of Orbis

    [06.19.08]
    - Seth Sivak

  •  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.

Comments

comments powered by Disqus