Design and Development Process

From Meridian 59 - Open Source Wiki
Jump to: navigation, search

This is a work in progress, intended to be a guideline of the process to follow from design to implementation of a concept into the game.

Design process outline

General comments (Delerium): this is an Open Source, volunteer project made up of a few core members and a larger number of interested people who often don't have enough time or experience to contribute significantly to the code. The purpose of creating a streamlined design process is to ensure only polished content makes it to the live server, while being simple, flexible and intuitive enough that the very process itself isn't a massive obstacle standing in the way of both groups of volunteers making contributions.

Design Document

As we're involving both the volunteers and also players in the design process, design documents need to be easy to follow from a non-technical standpoint (i.e. light on the code) and need to describe the proposed change in detail while remaining concise enough so that players will actually read them. As designers may not always be developers (or have the time to code a design) a Design Document might be a request or template for another contributor to code; in this case technical details can be left out and the design should be titled [REQUEST].

Design Document Headings


This is a general description of what the design plans to implement, what it aims to fix or improve, or where the new content would fit into the game and why it is needed. This information needs to be written so that it can be understood by both contributors and players alike; that is without discussing underlying game infrastructure or code. A broad outline of how the design is implemented can be placed here if necessary but any more detail should be in Methodology. If a player has a question about why the design is being suggested, or what it will do in-game, the Description should be able to answer this question. This section should try to stay under two pages unless absolutely necessary, otherwise players are unlikely to read it.


This replaces Prototypes, Variables and Pseudocode from the initial Design Document proposal, however should contain less code. This is where more detail about the design implementation should be placed, and can include more detailed information than the Description. Since we have all our code on GitHub, we can use links to specific commits, or even an individual line in a commit if necessary rather than duplicate information here. Any technical questions that could be asked in the forums should be answered by this section.

Gameplay Effects

This section should give a brief description of what effect this change may have on gameplay, for instance how PvP may change, what effect there will be on character building speed, any economic effects etc. This is probably the most important focus point of design, and should be explored with care. There's no length requirement on this section, but the expected changes should be listed in full, and the assumptions behind those changes should be detailed. This is where most argument and discussion focuses, so try to anticipate criticisms that might be brought up.

Potential conflicts

This is where any conflicts with existing game systems can be listed, and this section can also be updated based on feedback from the forums.

Potential Flaws

Any issues this design may cause, or any part that is not quite polished can be listed here. This section can be updated based on feedback from the forums, or flaws listed at the initial posting of the design document can be removed as they are addressed.


Links to the forum post(s), GitHub pull request(s) and Github milestone should be placed here.


Local Testing

As we have a limited team (and no paid testers!) all code absolutely must be tested by the developer on his own computer prior to making a pull request on GitHub (this applies to all pull requests, including one-line bug fixes). This should ideally mean there are zero errors being thrown on the local server, and no bugs remaining. Notable exceptions here are large systems requiring multiple players to test during development, and content intended to be showcased to players. This is the most important step in the actual coding, as this is where the majority of bugs and errors should be removed from the design prior to 104 testing, the purpose of which is to allow multiple testers access to (ideally bug-free) designs and to determine any merge conflicts between all designs in a milestone.

Pull Request

Pull requests should be submitted as soon as the code for the design is ready, provided local testing shows no issues. Code review can occur concurrently with discussion of the design itself and code suggestions/bugs should ideally be discussed in the pull request comments on GitHub.


Following on from that, the discussion regarding the design should be centrally located (forums are ideal for this) and all objections/responses should be raised there. Additional discussion can of course occur in IRC and game broadcasts, but players should be encouraged to make 'official' objections or support known on the forum. It is important to note here that everyone has their own idea on how any particular system should be implemented and it is impossible to please everyone with one design; this needs to be kept in mind when reading any objection. If the objection requests an equivalent (but different) design, the onus is on the objector to create his own design document and code his own pull request.

Public Testing

Testing on 104 can occur as soon as pull requests are submitted to a milestone. Testing feedback should be posted on the forums, in the thread for the Design Document. Testing results can also be recorded on the Patch Testing page on the Wiki. As stated above, this testing shouldn't be exposing large amounts of bugs or errors and if this happens, the pull request should be removed from the milestone pending the developer testing the content more thoroughly on his own computer. All developers who submit content to a milestone should attempt to try out all designs submitted to the same milestone and record their results on the Patch Testing page (and post in the forum thread if possible).


Generally a design and its associated pull requests should be put into the next available milestone, which will be #.#.#.x for bug fixes, #.#.x.# for minor additions and #.x.#.# for major changes. In the absence of a Lead Designer position, and the unlikeliness of this being filled, milestones themselves can be an object of discussion on the forums if necessary, with a thread created for each update (non-bug fix) milestone. This will allow more discussion on the actual content of updates and provide a place to post running patch notes (in addition to the Wiki) as the milestone is built.


Implementation of the milestone should follow at least two of the team verifying that the design works correctly and is bug-free (at least as much as a small group of testers can guarantee). As discussion of any design and milestone will be on-going from the initial posting of the design, advance warning to the server is likely not necessary apart from the usual '10 minutes to get safe message'. We can attempt to set a day of the week/month to implement updates but given this is a hobby project, contributors free time will not always line up exactly with any calendar we create for this.

Post-implementation review

This is something we haven't been doing formally, beyond asking players how they are receiving the changes and using server statistics to determine whether changes work as expected. An idea here is to have a forum thread discussing the update after it has been implemented so any issues with individual designs can be raised.