Requirements Spec

Social

Each world within the game must create one ore more social environment(s) that encourages experimentation, but leverages the masses to evaluate the gameplay quality of user-written modules.

For example, at the Market, users with enough money and experience could rent a 'stall', and could write the code for their stall, defining interactions and the 'flow', as well as the text. Users leaving the stall could be randomly asked to rate their experience (surveying only a percentage of visitors would be less intrusive).

Stalls visited most often, or rated highest could be displayed higher on the list. To allow new participants a chance, a mixture of 'new arrivals' could be infused.

Rising and falling algorithms would assist balancing the popularity of places.

Wiki nature

Initially, the creator of a game module can retain ownership and control permissions (although all source code is visible and copyleft).
However, once the module is formalized into the game, everyone with clearance can modify the code and make suggestions.
Also, if a user 'goes offline', and fails to log in for a substantial duration, his 'modules' will become public property.

Interface

A responsive, mobile-friendly, HTML5+Json interface.
Collaborative editing of the game by automatically qualified users.
Multiple levels of sandboxing, and a workflow for code approval and migration to higher security clearance.

The game's interface will exist as a single, AJAX webpage. Design should allow for a non-javascript version to exist also.

Regardless of the URL, the player should be (re)directed to their current location in the game. Players should not be able to access arbitrary URLs in the game, although an 'escape hatch' mechanism may be useful when the user is playing a beta section of the game.

Mobile devices should natively support the game. The visual layout should scale well to smaller screens, while still maintaining readability for regular computer monitors. Flash and plugins should be avoided. HTML5 can be used.

Architecture

A server-side framework must exist to perform the following actions

  • Handle all HTTP traffic, AJAX requests, etc.
  • Handle UI presentation and theming
  • Expose a data persistence API to scripts
  • Expose a UI manipulation API to scripts
  • Expose a continuation API to scripts for gathering user responses in-flow
  • Track script trust (Has a code review been performed, what are the exception statistics for it?)
  • Track the executing script
  • Determine and load script dependencies when loading a script
  • Sandbox scripts based on their trust (I.e, untrusted scripts cannot give players gold or gems, and cannot persist except to the script's own storage).
  • Serialize, and restore continuations captured within scripts.
  • Handle data persistence in a scalable manner
  • Allow creation/branching of new, isolated 'worlds' which can share code (but no data) with other worlds.
  • Expose an API for dumping a user into a different world temporarily.
  • Expose a 'translation' feature which allows strings to be 'overlaid' at runtime. This feature should allow a translated version of a world to be created without needing to change any underlying code. This feature should also allow community collaboration, and should be generic enough that it can be used to suggest textual changes to the game by arbitrary players. Source-code strings should be translated, not the concatenated results. I.e, markers need to be kept.