The Okabu plan required us to make some major changes to our development process, many of which were completely new to us. These included:
Making one major change would have presented a challenge. Trying to do all four simultaneously was extremely ambitious. Riding high off the successes of Rolando, we felt like any challenge could be overcome, and that each major change to the process could be dealt with once we got started. Confidence is a wonderful thing; naivety, less so.
Not having worked on a console game previously put us at a major disadvantage during the planning stage, as although we could make estimates as to the resources needed to create Okabu based on our previous experiences (and build a schedule accordingly), the accuracy of these estimates was questionable. Working without a publisher also denied us the capacity to verify the estimates and schedule, as well as denying us a safety net if things went wrong. There are obviously fewer options to source additional capital if you are self-funding.
Every area of work ended up being much more demanding than originally envisaged. On the publishing side, this proved to be a huge amount of work -- we were aware how much Ngmoco contributed to the project on the publishing side, but it was even more work in the console space.
On the art and design side, building out a full 3D world is obviously a great deal of work. We were being very ambitious with the size of the game (four distinct worlds, six playable characters, four minigames, controllable vehicles and 12 to 16 hours of playtime). As development progressed, it became evident that we'd been optimistic in our art and design schedule, which led to a very pressured period towards the end of development.
Looking back, our biggest takeaway on the planning side is that we should have really examined the scope of the game more at an earlier stage to better balance the ambitions we had with the resources that were available. For a downloadable title, 12 to 16 hours is on the large side, and it still would have felt meaty enough if we'd cut some of the content. This would have allowed us to reallocate resources to polish the core game and given us the breathing room we needed.
2. Engine Tech
The game started life as a PC/Mac prototype, leveraging the power of great open-source libraries such as Ogre and Bullet Physics. This gave us a real head start, and allowed us to get a playable prototype up and running quickly, but as the project progressed (and we moved from preproduction to full production) we hit some major problems.
The architecture of the PS3 is obviously a world apart from the PC, and while this wouldn't have been too much of a problem if we were porting a simple 2D game, we were dealing with some quite expansive 3D environments and were targeting 60 frames per second. While Ogre had been great on PS3 (and we had some successes porting it to PS3), it became evident that we would need to leverage the SPUs to deliver the kind of experience that we were looking for.
As a result, we began exploring our options -- either optimizing Ogre for PS3 or using some additional PS3-specific tech. Fortunately Sony provides an extremely high-performance engine on PS3 in the form of PhyreEngine, and after much deliberation, we decided that our best option was to leverage the PS3-oriented power of PhyreEngine to get the performance we needed.
This shift to PhyreEngine was obviously a major undertaking, and was not something that we'd factored in during the planning stages (we'd assumed that our PC-centric engine would have been sufficient). Developing a stable, performant engine that delivered all the required features on PS3 was a lot of work.
Towards the end of the project, this really led us to reflect on the effectiveness of our initial tech plan -- most of the elements and features that we'd required and built for Okabu (physics, rendering, scripting, audio, save game support, leaderboard support, trophies) would have been very capably provided by some off-the-shelf engines.
The type of game that we were making was a pretty good fit for an existing engine (we weren't using any exotic rendering or physics techniques), and using an existing engine would have allowed us to benefit from some desired rendering and toolset features that we hadn't had the resources to implement ourselves.
While we had learned a great deal from rolling our own engine, the resources that the engine development process consumed may well have been better spent on other areas of development.
Our major takeaway on the tech side is to put more thought into the benefits of building your own tech, particularly for small teams like ours. Does rolling your own engine really makes sense, or are there existing engines that would be a good fit? For some genres and some programmer-heavy teams, building your own tech may make perfect sense, especially if you are trying to innovate with non-standard rendering (voxels, etc.) or have quite a minimal feature set.
In other cases, if you require quite a large number of systems and features that are commonplace in major engines (as we did with Okabu) or if your team is less programmer-heavy, existing engines might be a better choice. Mature, stable tools are obviously another major consideration here (which I'll go into in the tools and pipeline section).
The widespread adoption of flexible engines like Unity has opened up some really interesting opportunities, not only in the ability to reduce the tech burden on small studios, but also building a standard toolset that programmers, designers, and artists are familiar with.