- ARPDAUPosted 12 years ago
- What’s an impressive conversion rate? And other stats updatesPosted 12 years ago
- Your quick guide to metricsPosted 13 years ago
Going agile, and stumbling on the way
This is a guest post from Josh Samuels of Raindrop Games.
Let’s go agile! All the cool companies do it!
After 3½ years in development, we submitted our first game, Arrival: Village Kasike, to Apple’s App Store for iPhone, iPad, and iPod Touch. From the start, I was interested in taking an agile approach. I’ve completed many web projects and found it matches the way I think and manage projects. I have little patience with reading or writing long documents but find playing with ideas in small code experiments holds my interest while I work through the details.
Although I am a fan of how productive an agile approach can be, I still struggled with following this pattern for the development of Arrival: Village Kasike.
Doing things the hard way
We started in mid-2009 with some game ideas about the people of the Caribbean prior to
European settlements. We met with some interested parties at the GDC in 2009 and, excited with the prospect of third-party backing, came up with a concept.
We decided to get a jump on development and sought out team members. Next we found many people but had no money, which made retention difficult; we focused on finding students needing to build up a portfolio. As our team grew, we did our best to immediately find tasks for new members.
We had a general sense of what would be needed and created minimal documentation, mostly to-do lists. For the art team we did not have concept art nor did we make this a priority. Through a long process of trial and error, we were eventually able to define the desired art style. We followed the same pattern with game design and programming. We did not experiment with game mechanics; they were defined by a designer and then built by an engineer.
While the art team was busy building assets, we were trying to get a small engineering team up to speed with our game engine. Progress was slow and we never prioritized small playtests to try our ideas for core game mechanics.
We should have used concept art to document a consistent style for the art team. Instead artists needed to submit many revisions of their work until they got the correct look and feel. Proving which game mechanics work through experimentation would have prevented us from building out systems later discarded. With neither, we were flying blind until a feature or art piece was close to completed. With high turnover, we spent a large amount of time getting new team members up to speed and chasing down people who didn’t respond to status requests.
Are we there yet?
We did follow some agile principles late in development. Once we had the core functionality in place, we conducted play tests. Our first session, which was informally watching a friend play, showed that he got bored after a few minutes. He didn’t have much to do or anything guiding him to do it. This test session led us to add new gameplay and more tutorials. Rather than diving in and adding some new gameplay, we started by exploring our gameplay ideas with small experiments. Two programmers each tried a different idea, farming and fishing. We built a few iterations of these ideas and used this process to pick which would make it in the final game. Minimal versions of these mini games demonstrated how the gameplay would work and how much effort would be needed to complete each one.
Our next testing sessions showed that people didn’t understand how to play, regardless of
the tutorials we put in place. We broke up our game into levels and added integrated tutorials during the early levels. We used an iterative process to build clearer tutorials and check these against our playtesters. After a few rounds of iteration, our playtesters were able to play to the end of the game. This was a big step forward, but most villages were starving by the end. We followed the same process to balance Arrival: Village Kasike’s difficulty and flow; we changed our variables and tweaked overall systems until play testers not only finished the game, but didn’t want to stop playing!
There was one particular session which stands out in my memory. I was tired, having been
working late on the game, and was hoping the test session would last for about an hour. I was a bit concerned that the tester didn’t understand how to succeed in our farming mini-game but that didn’t seem to bother her, she kept wanting to play. After about 3 hours of playing I pointed out that she had reached the last level of the game and from there on out it was open-ended. She nodded and kept playing. Another 20 minutes passed and I mentioned that she could stop whenever she wanted, the test was done. It took a little more encouragement but I finally got her to stop playing. She looked at the time and was shocked. “But it felt like I was only playing for an hour!” This is when I knew we nailed it. This was confirmed in additional test sessions and soon after we submitted Arrival: Village Kasike to Apple.
In the end, we followed an iterative process to add new mini games, refine our game flow, and tune the balance.
What worked
Here are key areas that would have helped during development of Arrival: Village Kasike:
Iteration
A version of iteration exists for every discipline and is essential. Iteration is probably the biggest factor in making agile work, programming and asset creation is done in short, iterative cycles.
Clearly defined mechanics
Start development with core mechanics you have tested. Then build a game around that. We picked an interesting idea and a game genre and ran with it. It took a very long time for us to mold our mechanics to the game idea and it should have been the other way around.
Planning
It is a misconception that agile does not involve planning. Planning certainly can be approached in a number of ways, but is still required.
Project management
Managing a project properly takes work. Agile does not change that. Be prepared to put in the necessary time or embrace chaos! Management is especially hard when you are tempted to dive into development due to a tight timeline. Rushing the process will waste far more time in the long run than is saved initially.
Testing
Test for defects, quality, balance, fun, game flow, and anything else you consider important. Test regularly throughout the development process, not at the end. Fix defects early rather than allowing them to linger and degrade the project’s stability and quality.
There’s always next time…
Working under a tight deadline with regularly fluctuating team members made using a structured development process very difficult. I was pulled in many directions which added to my reluctance to take the time needed to plan and organize on a regular basis.
I am grateful that we found a group of dedicated and talented people who stuck around through all of our missteps to finish Arrival: Village Kasike. I like to think we learned from our mistakes and will do much better next time.
Related Posts
