Wireless Connectivity – We found that using Sony’s default game state for establishing Ad hoc games wasn’t as stable inside our codebase as we had hoped for. Most of the problems that we encountered were not apparent until we started getting feedback from Sony on communication interruptions that they were encountering at their testing facilities -- that we couldn’t reproduce.

Making the adjustments to handle more robust communications error checking was a bit of a stab in the dark because we weren’t ever sure of the results until we received updated feedback from Sony on these changes.

It’s challenging to fix bugs when you can’t reproduce them in-house. We had been warned, and had spent a considerable amount of time on the Sony PSP developer boards trying to anticipate the scenarios under which Sony was going to test the Ad hoc communications. In the end, we made the communications more robust to handle a wider range of possible communication interruptions that we never encountered at our studio.

Source Code – During the planning phases of the project, we wanted to get Crazy Taxi up and running before tackling the sequel. It took several months and was completed on schedule. When we turned our attention to getting the CT2 source code up and running we encountered unexpected problems that inevitably created delays in our schedule.

In retrospect we should have spent time up front to do due diligence on the CT2 source code; if we had, we would have been aware of these issues months earlier. But as they say, hindsight is 20/20. The net result was a hit to our schedule and a small adjustment to our budget. In the future we will handle this differently, by purchasing longer licenses for software development packages as well as increasing the amount of time to properly evaluate any codebase we use.

Communication – Yes, we knew from day one that this would be key to our success. In the end, it is still tough to execute when you are dealing with teams working together but separated by half the globe and a different language. We planned on code integration between multiplayer and single player right after first playable. While that went pretty much as planned, we were not prepared for the problems that came with bug assignment. In case of Crazy Taxi, many bugs were not distinctly multiplayer or single player.

That being the case, how did we decide who was responsible for fixing a bug? Would that fix impact the multiplayer/single player game? Many bugfixes worked for fixing immediate issues but would impact work being done by the other team -- when changes made were not clearly documented. Although the bug information was coming in steadily, it became a full time task to manage that data and disseminate it to appropriate team members either in Budapest or Redwood City. It became another layer to bug management that demanded a lot of communication.