• Design Philosophy

• Development Approach

• Technical Arrrchitecture

• Implementation Notes and Challenges

• What went right?

• What went wrong?

• Conclusions and Recommendations

Puzzle Pirates Case Study

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 FreeBSD– nearly all users are on Windows– some issues with MacOS 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 OpenGL (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