Jailbreak Developer Network: Design Goals

Jailbreak 2003 is designed from scratch, heavily inspired by our experiences during development of Jailbreak III and previous versions. The following points outline the goals of our design.

Mod Design

• Usability. Jailbreak is a game type like Capture the Flag or Bombing Run and should neatly integrate with the base game. Provide intuitive in-game cues for players; don't rely on them reading a manual or playing a tutorial map. Use existing in-game facilities and adapt them as much as necessary, yet as little as reasonably possible; don't reinvent wheels.
• Compatibility. Just like the base game provides means to add third-party content like custom player models and mutators, so does Jailbreak. Compatibility must not be broken for the developers' sake.
• Extensibility. A game lives with fresh content being created for it. Jailbreak's interface for mappers and coders must be comprehensive, easy to understand and versatile.
• Modularity. Keep the core code slim. Features like release protection or llama hunt can be plugged in as Jailbreak Add-Ons.

Code Design

Code must be easy to understand and to maintain. Creating code by trial-and-error is not an option (unless there's no alternative, as for undisclosed interfaces). A bug is not fixed until it is understood. Code is not completed until it is documented.

• Code redundancy. Avoid code redundancy if you can. Carefully design a class structure. Don't be shy to put even small code parts in separate, appropriately named functions. Never copy-and-paste functions from one class in another if you could access it remotely.
• Data redundancy. Avoid data redundancy if you can. If you have to keep redundant data, select the authoritative copy carefully, stick to it and use it directly whenever you can. Never make non-authoritative redundant data authoritative for another redundant copy.
• Consistency. Use a consistent, comprehensible naming convention for class, variable and function names. Use a consistent coding style. Clean up your mess if you made one during development or debugging.
• Reuse existing facilities. Take advantage of code that already exists in the base game if you can, even if it means that you have to spend some time studying it. Don't be shy to scratch some code and rewrite it if you find a better way to implement it later.
• Know what you do. Don't create code or fix bugs solely by trial-and-error. If you don't know how or why something works (or doesn't work), spend as much time as necessary to understand it or ask somebody else who might know. Trial-and-error always means that there's one thing you didn't try that will break your code.