1. Money. Large Animal does not have deep pockets; in order to build our original titles, we've had to stash away the profits made from building web games for clients on a work-for-hire basis. As a result, it was nearly impossible for us to give the amount of sustained focus to RocketBowl that the game really needed. Our efforts were deeply fragmented, as most of the team would need to go off and build a game for LEGO or Cartoon Network to pay the bills. Despite what the number at the end of this article would suggest, we never had a "real" budget for RocketBowl since, officially speaking, we couldn't actually afford to make the game at all. We simply didn't have the money to bring in additional programmers, modelers, or other specialists.

	RocketBowl

2. Too little planning. We jumped into production on RocketBowl too quickly, without a pre-production and planning phase. Prior to this project, no one at Large Animal had developed a game of this scope using a 3D engine. There was a lot of learning to do. Rather than setting aside an explicit pre-production phase in which to explore the technology, identify areas of risk, and figure out solutions, we just forged ahead and started making the game, learning as we went. As a result, we didn't always know the toolset as intimately as one would like. While working on the recently released expansion pack for RocketBowl, we uncovered a useful feature of the Torque level editor that we'd never found before. And we realized late in the schedule that we should have centralized all of the editable data in the game so that the designers could make changes without consulting the programming lead. If we'd had a dedicated exploration phase, we would have saved ourselves time in the long run.

In addition to the very real limitation of not having the financial resources to completely focus on RocketBowl, there were other obstacles that we created for ourselves by not approaching this project in as structured a way as we do our client work. For example, whereas all of our client projects begin with a design doc, a code plan, a timeline, and a set of deadlines, RocketBowl had only the most minimal documentation. Also, we never created a full prototype of the application interfaces, so that we could see how the experience flowed (or not!) for the user. As a result, we ended up making adjustments once the "real" interface was in place - adjustments that were more expensive as a result.

RocketBowl never had a clearly defined budget. Consequently, the entire project seemed to lack definition; it was hard to know if we were on track because there were no tracks to speak of. It wasn't until the last four months of development, when we were finally able to bring on an associate producer, that the project started to look more like a "real" game project, with an actively updated task list and a roadmap to release.

3. A Completely New Technology. The production time on RocketBowl was at least doubled as a result of our lack of experience with the Torque engine, or for that matter, with any 3D technology. We'd built dozens of 2D games using Flash and Shockwave, and even some 3D games using Director, but had never worked with a C++ 3D game engine. When we started the project in the summer of 2003, Torque had some rough edges (for example, some of the documentation was lacking at the time) which, because we were so new to this area of technology to start with, had a big impact on our work.

We were also naïve about how much additional QA attention a 3D game requires. Even though we applied more QA energy to this project than any other project we'd previously worked on, it still wasn't enough. Video and sound card issues that we hadn't encountered or foreseen reared their ugly heads post-launch, necessitating patches and new builds for all of our distribution partners. We didn't have a full-time QA person on RocketBowl until the last few weeks before launch and that wasn't quite enough.

4. Trimming the File Size. In the downloadable world, it's important to keep your games small, lest your risk intimidating potential customers with a lengthy download time. After all, there are plenty of other free trials to download if yours is taking too long. We knew this, but in the midst of an ad hoc project, it fell through the cracks. It wasn't until a few months before we shipped that we got serious about file size and began scrutinizing every file to see where we could trim the fat. When it came to making assets smaller, a little utility called PNG Gauntlet came through in a big way.

5. Gameplay. There were a number of areas in which the gameplay could have been improved as well. For example, we've always felt, even from the very first prototype, that each RocketBowl level is highly replayable. Each "frame" of each course is different, and there are a wide variety of approaches to any given frame. In real world bowling the "level" is always exactly the same and holds an endless appeal for countless players. What we failed to consider is how the progression of level unlocking would affect the player's impression of the game's replayability. Since the levels in the game are unlocked according to performance on the previous level (or in the case of tournaments, require a cash entry fee), players would play the game long enough to unlock all the levels, consider the game "beaten", and email us complaining that it was too short. The free expansion pack that we just released is in part a response to those complaints.

We didn't really dig into the fictional context of the game until the eleventh hour, and it shows. In the end, our presentation of the backstory of the game was boiled down to a single title screen. There are also great NPC characters in the game, created by our art director Brad MacDonald, but they were introduced late in the process, when we were reluctant to change the flow of the application too drastically. As a result, the characters don't occupy as prominent position in the game as they deserve.

There are other aspects of the game design that I feel could still use some improvement. For example, in the game you can aim away from the pins for the frame you are on and knock down pins that are off in the distance (a "Wild Shot"). Effectively, Wild Shots earn you a free throw. However, that payoff isn't really enough to justify the use of Wild Shots as an on-going strategy. Our scoring system is pretty faithful to real-world bowling. We attempted to integrated Wild Shots into the scoring system in a variety of different ways, but I feel that we never quite struck upon the right approach. At the very least, we should have rewarded the player with some game cash.

Conclusion

Working on RocketBowl really helped us grow as a company. Not only did we tackle a big technology challenge, but we saw firsthand what happens when a production process is not clearly defined.

Given the exposure the game has gotten, the technology expertise it gained us, and the myriad lessons it taught us about game production, RocketBowl has been a huge success for Large Animal. And while it hasn't made us rich beyond our dreams, it has been a commercial success as well. It's outsold all of our previous titles combined, has been downloaded over 750,000 times, and has found a loyal group of fans.

	Developer: Large Animal Games URL: http://www.rocketbowl.net Target platform: Pentium 733 with 128MB, Windows based OS. Length of development cycle: 18 Months Budget: $150,000 Internal team members: 4 External contractors: 2 Development workstations: 1.5GHz to 2.7GHz PC's running Windows XP Pro Development tools: Torque, Visual C++ 6, Hammer, MilkShape, PNG Gauntlet Number of Ball Bag Jokes Made: 1,439 Size of project source materials: 539MB (uncompressed) Size of final product: 13.9MB Release Date: November 9th 2004

______________________________________________________