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.

Asterogue's pre-release gameplay trailer

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.

The best team money can't buy

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.

Blocking out our modular enemy designs

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.

Keep everyone on the same page

Business can get messy, especially if your team members have differing assumptions about how they will be compensated for their work.  Before a single line of code was written, we made the call to release Asterogue for free and signed contracts providing permission for the free release of all of our work by any member of the team as part of the Asterogue game, with a caveat that we could renegotiate contracts should we decide upon a commercial release later. This meant that there was never any question of dividing up profits and that no unscrupulous member of the team could hold their work ransom to delay release of the game.

Another practice that helped us hugely was following the tenets of Agile development.  Although there has been some backlash amongst developers against the more prescriptive requirements of Scrum and other flavors of Agile, it is undeniable that the general structure that it provided was vital to our success.  Daily standups helped enforce our mandate that we all convene upon a single location to work, kept us all abreast of how development was progressing, and motivated every member to make consistent, quantifiable progress.  Biweekly sprints allowed us to measure progress and decide when to cut content, and releases every couple of months gave us a constant deadline to shoot towards.

The Real Human Scrum board

On a more technical note, we made sure to apply especially strict standards to our coding team.  A code bible was drawn up during pre-production, combining a general style guide with UML class diagrams and standardized rules for inter-system communication.  We followed this up with a system of code reviews to make sure that all code was stable and consistent before committing it to version control.  We had a coding team of 10 programmers of varying skill and familiarity with Unity, which could have been a recipe for a bug-ridden, poorly documented, and unmaintainable codebase.  However, by following our code bible and review process, everyone was able to contribute substantial work while maintaining a healthy codebase throughout development.

Develop with your platform in mind

Asterogue was planned from the start to be a mobile-only title.  This allowed us to make design decisions that would best serve a mobile game from the beginning of the project.  Our controls are the most obvious example, as we based the entire movement, combat, and equipment systems around a number of touch-based gestures.  These controls changed how the game played and necessitated tuning it in a way that we might not have been able to do had we supported other play styles.  Other features such as the length of levels, our quick play battle mode, and the ability to stash your new equipment at the end of every level were also affected by our decision to focus on mobile.

Additionally, targeting mobile from the outset meant that we prioritized getting the game running on actual devices and testing it on hardware throughout development.  This allowed us to catch performance bottlenecks, control issues, and hardware-specific bugs much earlier than we might have done had we left porting to mobile until the end of development.

What Went Wrong

This doesn't look good...

Make time to test

It should already be readily apparent that our focus during Asterogue's development was to get as much done in as short a time as possible.  This meant making all our key design and engine decisions early, keeping the team focused, and keeping our heads down for six months until release.  Unfortunately, what it did not mean was taking the time to properly playtest the game during development.

We certainly playtested as much as we felt that we could — a preview build that we carried around GDC revealed a large number of major flaws in our controls and gameplay flow that we might not have caught in time otherwise — but the fact was that we had a limited amount of time, limited access to playtesters, and a limited variety of hardware to test on.  Worse, we did not start formally tracking bugs until very late in development, at which point we had to triage and only address the bugs that we felt we absolutely had to fix to be able to release.

We had a lot to fix following launch

We were still making code changes the day before we uploaded our first build to Google Play, and predictably this meant that the bug reports that came in from our early adopters revealed a number of issues that we had never even seen before.  It would take months of patching before we had sorted out all of the various edge cases, Heisenbugs, and device-specific issues that cropped up throughout our user base.

Take time to build visibility

We did everything that we could think of to promote Asterogue both during development and after its launch.  We went live with a website and blog early in development, and we did our best to post video updates showcasing the game's current state every week. We maintained our Facebook, Twitter, and IndieDB accounts, we submitted the game to festivals and local indie showcases, we emailed journalists we thought might be interested in the game, and we wandered around conventions with test builds to foist upon strangers.  Half of the reason we pushed publicity as hard as we did was to simply have the experience of attempting to publicize a game, and it's a good thing, too, because it's likely that the experience is all that we got out of it.

A developer update just a couple of weeks from launch

As I said, we are perfectly happy with how Asterogue has performed so far.  However, outside of our mention on the Weekend Confirmed podcast (which was based on a demo we gave to Shacknews editor-in-chief Andrew Yoon at a festival — listen for us at 114:25), it's hard to draw a quantifiable connection between our publicity efforts and any of our coverage or downloads.  Our web presence has undoubtedly made the game appear more professional, but it never provided a large influx of visitors or press inquiries.  What little coverage we did receive either came from journalists whom we knew personally or who had stumbled upon the game during its brief time upon the New Releases charts on various app stores.  Similarly, our downloads spiked sharply during that period of initial visibility before falling to a fairly constant trickle, with the exception of one brief spike at the start of October that likely correlates to our Weekend Confirmed mention.

It's hard to say if we did anything wrong with publicizing the game aside from having such a short development cycle.  If we had maintained the same persistence in pursuing publicity for a longer period, it is more likely that we might have gained popularity on sites such as Reddit or gained traction with various journalists.  As it was, though, our rapid development cycle meant that we did not have a game ready to be shown until very late in the process, at which point there was not enough time for a slow burn towards coverage and recognizability, and we were left to launch a game that no one had heard of in a market that is quick to forget.

It is also worth mentioning that Let's Play videos, which are becoming very popular as an avenue of spreading information about new indie games, were essentially closed off to us from the start because of our decision to focus on mobile.  Due to the difficulty of capturing video from mobile devices, it turns out that very few video makers bother with mobile games at all.  Although several prominent Let's Players expressed interest in Asterogue, the fact that we were unable to provide a desktop version of the game meant that it saw no coverage in that community either.

Don’t rely on partners to deliver

We already mentioned how much deciding on our base technologies early helped us in developing Asterogue.  However, it very nearly shot us in the foot for one simple reason: although we had decided to develop with Unity and quickly invested a large amount of time in targeting that platform, we were relying on our school to help license the engine in a way that would allow us to release the game.  This led to a number of close scrapes and tense evenings as our development licenses had a tendency to expire right before major deadlines. As is always the case where a bureaucracy is concerned, the process ended up taking several months longer than we had expected, with the final licenses arriving in our hands only a week or two before we released the game.   

It's always worth remembering that you're taking on a huge risk when you rely on an external partner to deliver a key piece of your development.  Licenses were a comparatively small issue, for we could still develop just fine without the ability to build and release the game; the issue would have been a hundred times worse if we had been relying on someone to develop code or some other blocking technology in parallel with our own development. 

Know how many designers is enough

Simply put, there were times when trying to accept everyone's input was not as great as it sounded on paper.  It worked fine for most cases, where only a small handful of people cared enough to contribute, but sometimes an issue would crop up where everyone would want their say.  Worse, on a number of occasions only a couple of people had an opinion, but they refused to back down and accept the other's suggestion.  In these instances, it would have been better to have a lead designer step in and settle the issue earlier, allowing the team to move on to other topics.

Great is better than solid

With Asterogue, we wanted to prove that we could put out a good mobile game, a student-built title that would feel just as polished and substantial as anything put out by a professional studio.  We needed lots of content, solid controls, clean graphics, and functional tutorial, the works.  By and large, we feel that we came pretty close to that  goal.  Unfortunately, in our quest to flesh out our content and polish up our rough edges, we erred away from making any wild, out-there decisions that might distract us from creating as 'good' a game as possible.  Unfortunately, it turns out those are the same bold decisions that end up making indie games stand out, landing them on blogs and festivals as the hit new thing.  It is possible that, had we allowed ourselves a few more bumps and rough edges in order to focus on making Asterogue as stand-out and surprising as possible, we might have been able to achieve a degree of penetration unlike anything we experienced. 

Asterogue launch poster

Wrapping Up

To date, Asterogue has seen over 24,000 downloads, was reviewed on a number of mobile games blogs, was mentioned on the Weekend Confirmed podcast, and made IndieStatik's list of the top 50 free games of 2013.  More importantly, Asterogue's high level of quality for a student project has helped land jobs in the games industry for much of the team, so although Asterogue may not have been a success by commercial standards, it accomplished everything we originally set out for it to do.  We are hugely proud of everything we achieved with Asterogue and continue to support it with as much post-release content as we are able.

You can download Asterogue for free from iTunes, Google Play, and the Amazon App Store.