From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Established workflow.png This article covers an established workflow.

Established workflows have been discussed among and agreed upon by the development department(s). They should serve as documentation how these workflows are successfully utilized in the project.

The workflow article explains how the transformation process from mere ideas to implemented game concepts happens. Furthermore it covers how the decision making process on the team works.


One workflow that fits all?

The workflow outlined here is simply an example how the process should look for most development departments. The truth is: there is no silver bullet in terms of workflow. Each department has slightly different needs and therefore every department should agree upon a workflow that works best for them and document it. The example workflowed outlined here is simply meant as a starting point for each department to get inspired.

Example workflow

Workflow diagram

While workflows differ from department to department, there are five basic steps that pretty much apply everywhere. The departments base their workflows on these five steps and modify them where it suits their needs.

Brainstorming stage

Pretty much everything in PARPG starts with initial brainstorming.

When a developer feels the need to introduce any kind of new concept, he brings up the topic at the IRC channel or the forums. Regardless if it's a new NPC, a tool for the asset pipeline or a new unit testing software: bring up the concept at IRC or the forums and wait for some initial feedback. That often helps to make sure you run in the right direction.

Proposal stage

After you got some initial feedback from the other developers, it's time to start writing it down. Each department tackles this in a different way. Some departments might use an idea dump article, where work in progress concepts are stored or linked to until they're fleshed out in more detail. Other departments might not use such an idea dump and rather recommend their developers to flesh out their concepts on their personal talk page. Most departments utilize Mediawiki templates to tag work in progress concepts. Regardless where you actually flesh it out: take your time and make sure you've covered the topic in enough detail that it's ready for review by the other developers.

Review stage

Once you feel comfortable with your fleshed out proposal, it's ready for review by the other developers. Usually the other developers of your department and some key developers from other departments will take a close look and provide feedback on it. Don't take any feedback personally: the other developers are mainly interested in helping you create a great proposal. Revise the proposal based on the feedback given by the other developers.

Scheduling stage

Once a proposal has been actually reviewed and approved by the other developers, it's ready for implementation! Now the concept is scheduled to find its way into the game. Some concepts might sit in scheduling stage a bit longer than others. That mainly depends on the current priorities of the departments and how soon they can look into implementing these concepts.

Implementation stage

Scheduled concepts are waiting to get implemented into the game down the line. Once they're implemented, playtesting can take place and additional tweaking can be applied based on the playtesting feedback.

Decision making

The following points are meant as a preferred order of decision making. That means if an agreement can be reached with methods listed at the top, there is no need to resort to methods listed below:

  1. Discussion among the developers of the specific department.
  2. Additional consultation by developers of the other departments if needed.
  3. Final decision by key developers of the relevant department in case all kind of feedback was already taken into account and reaching an agreement seems not possible. This is meant to be a rare case and not the standard prodecure of decision making. Maturity and professionalism should help us to decide about the vast majority of aspects based on rational discussion rather than decisionism.


  • Discussion will help us to understand the topic better. Pros and cons of each concept will become clearer.
  • While it's often impossible to agree on a complicated topic right away, it's often possible to agree on smaller, less wide agreements. These small steps will lead the discussion into a direction until we can hopefully agree on larger terms as well.
  • Reached agreements shouldn't be questioned again later without good reason. Otherwhise there is the potential pitfall of endless discussion that paralyses the team.
Personal tools