Puzzle Pirates Case Study Design Philosophy Development Approach

Puzzle Pirates Case Study • • Design Philosophy Development Approach Technical Arrrchitecture Implementation Notes and Challenges What went right? What went wrong? Conclusions and Recommendations

Design Philosophy • • • Fun over Realism, Simplicity MMP from the outset no single-player Clean start with no legacy code Latency tolerant Client distrusting Minimize Client-Server Transactions

Development Approach • • Small Team Get to public Alpha quickly Spiral Development Model Contained Design (hoho) Modular, Re-usable code Frequent Refactoring Divided work by Feature, not Client vs. Server Use of Java and Open-source

Technical Arrrchitecture • Built on mature distributed application framework (DObject) • Designed as a distributed system first, a game second • Client/server architecture with server maintaining canonical world view • Simultaneously developed the game and our own Narya game development library (40% of code in library, 60% game specific) • Code separated into modules and then further separated into client, server and shared code

What Went Right • It works! • Low server-side overhead, low bandwidth requirements • Cross-platform worked well: – all engineering (client and server) done on GNU/Linux (Debian) – servers running on GNU/Linux and Free. BSD – nearly all users are on Windows – some issues with Mac. OS X but it works • Very few incidents of server instability • Few incidents of hacking; none were game destabilizing

What Went Wrong • Java is still not very good for graphics and sound code: – graphics performance is difficult to profile, hard to tune, not as fast as we'd like – Java's sound support is high-latency and sometimes crashes VM – things matured a lot during our 3+ years of development but we're still going to switch to Open. GL (JOGL or LWJGL) for the next project • Testing has been poor and we've been saved from disaster only by anal programmers, luck and a tolerant user base • Tried using Java Web Start for deployment and patches, eventually had to replace it because it was neither robust nor scalable

Conclusions and Recommendations • Design the game as an MMP and incorporate the network into the design • Start with an architecture designed for distributed applications, not one designed for realtime single player games • Good development approach is at least as important as games experience • Code quality paramount in MMP development • Java great for server, good for client