1 / 7

Design Philosophy Development Approach Technical Arrrchitecture

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

nizana
Download Presentation

Design Philosophy Development Approach Technical Arrrchitecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

More Related