Get the latest Education e-news
 
  • Postmortem: Asterogue

    [02.20.14]
    - Jon Gill
  • In the fall of 2012, the members of Real Human Games were still college seniors wrapping up our degrees in Computer Science: Game Design at the University of California, Santa Cruz. We were approaching the end of a two month process of brainstorming and physical prototyping, as we were to spend the remainder of the year developing a game together as part of our degree. A final concept pitching session determined just what that game was to be; the judges had spoken, and our mobile action-roguelike Asterogue had the green light.

    Primary development on Asterogue occurred over a six month period from December 2012 to our release on Android and iOS in June 2013, during which time we made some choices that were vital to our success and others which were in hindsight quite damaging to development. While some of our experiences are applicable only to other student development teams, much of it should be relevant to any small team operating on a limited timeline.


    What Went Right

    Know your vision

    We knew from the start that we wanted to release Asterogue by June - student projects that extend beyond the graduation dates of their teams have a famously high rate of collapsing before completion - which meant that we only had six months to develop the game. To keep ourselves on a steady course, we spent our pre-production time seriously considering the scope of the project, deciding what was crucial to the core of the game and what could be considered a stretch goal. We focused on ways to get the most content out of our limited development resources as possible: maps and gear would both be procedurally recombined, but so would enemies, effects, and other traditionally hand-authored game elements.

    This came with a number of technical and design considerations that had to be obeyed: enemies had to be designed in a way such that we could scale and recombine their various bodies and legs, rooms had to scale to various shapes and sizes, and characters had to be tinted to reflect various elemental effects while remaining consistent with our overall style. We made sure to solve all of these issues during pre-production while still giving our artists lots of freedom to play with the specific designs. This kept the artists happy with their work and fed back into the gameplay design as the visual elements fell into place, an element that we'll address further in the next point.

    Build the best team you can

    We made an effort to keep our team as happy, cohesive, and productive as possible from the word go. As a student team, we knew we'd be tackling a number of issues specific to non-professional development - limited availability, diverse skill levels, and a potential lack of dedication - and we made sure to nip these in the bud.

    We found that we could combat limited availability by making the hours that we did have count. At our first meeting, we agreed that we would meet together and work on our tasks any time between 10 and 5 that we weren't in another class. While it seems rough for a group of full-time students, enforcing these hours meant we could communicate regularly while keeping our weekends and evenings free, which saved us from hating the project and each other.


    Additionally, at the start of development, we assigned rough roles based on people's abilities and stated interests - producer, combat designer, UI artist, back-end engineer, and so on - and we made sure to allow people to own those roles as much as possible. Tasks within someone's area would default to them and they would be involved in all decisions that affected their realm. By allowing our members to focus on the parts of development that interested them most, we kept investment in the project high across the entire team.


    But don't build anything you don't have to

    We went into Asterogue's development following the maxim 'never waste time developing anything that we can easily acquire somewhere else.' This isn't the right approach for all projects - some student teams in particular might value being able to say that they developed their own physics engine or skeletal animation system - but we were pressed for time and, given the choice between spending it writing engine features or adding content to our game, we chose to add content.

    We also made sure to get our base technology decisions established during preproduction, so that we would have a solid foundation of tools to fall back on throughout development. We researched various technologies, ultimately deciding on Unity as our base engine, with the SmoothMoves plugin for skeletal animation, 2D Toolkit for additional sprites, and NGUI for our interface elements. We would do all of our version control on Github, sync additional files over Google Drive, and we would use Skype's persistent chatrooms for communication outside of lab.

    Each of these decisions provided a key element of our development, got us up and running fast, and allowed us to focus our energies on the problems specific to Asterogue rather than wasting our time reinventing the wheel.

Comments

comments powered by Disqus

UBM Tech