Development process

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Ongoing sprint.png This article covers an agile concept!

Agile concepts are currently evaluated by the development team to help us stay focused and make better progress on a more steady basis.

This article explains how the development of PARPG works from a high level perspective.


Three (semi) consecutive phases of development

Keep in mind that these phases are not strictly consecutive in most commercial projects and even less in the open source world. Furthermore not the entire project is in a specific phase of development. This can (and in reality will) actually vary from department to department and even from field of work to field of work in the departments. The programming department could be already pretty much in production phase (department philosophies have been agreed upon, coding standards are established, unit testing policies are clear) while the graphics department could be still in pre production (lack of established asset pipeline and lack of clear workflows how to utilize the asset pipeline).

Sometimes it's also necessary to take a step back and go back into pre production phase in a certain field of work. E.g. if we discover a huge problem with our asset pipeline during course of development, it pretty much means back to the drawing board for us in this specific field of work.

Pre production

  • Flesh out creative vision
  • Flesh out department philosophy
  • Flesh out workflows
  • Flesh out asset pipeline and documentation how to use it based on the creation of test content
  • Focused on building a stable fundament so that we can move into production later


  • Tweak creative vision if necessary
  • Tweak department philosophy if necessary
  • Tweak workflows
  • Tweak asset pipeline and extend documentation how to use it
  • Focused on mass producing content (code/assets/documentation) based on the guidelines fleshed out during pre production

Post production

  • Polish content
  • Extensive testing and bug fixing
  • Focused on bringing the game to a worthy 1.0 release

Four recurring phases of development

PARPG development consists of four recurring phases of development for every release we want to ship.

Milestone planning phase


  • Utilize post release feedback from the previous release to prioritize PBIs
  • Decide upon the theme of the next release
  • Pick high priority PBI from product backlog and prepare the first sprint of the milestone work phase

Proposed timeframe: 2 weeks. Two weeks should be sufficent to flesh out a first sprint to tackle in the upcoming milestone phase.

Milestone phase


Proposed timeframe 3-5 months. Depending on how many sprints we want to tackle during the milestone phase.

Release phase

The work on every project milestone ends with a public release of PARPG. Releases require a higher level of debugging and polish. Before we ship a release, we'll have to compile a release checklist to ensure that we didn't overlook any obvious problems. Here are some release checklist points as food for discussion:

  • Ensure all unit tests run without any problems on all targeted platforms
  • Ensure that all ingame assets conform to our asset conventions: naming scheme, licensing information
  • Ensure that there is an easy to use packaging script to package PARPG for the different targeted platforms; furthermore documentation HOW to package on the different platforms is essential as well
  • Document who can/wants to take care of which release tasks

If we want to release often and early, we should have a lean release pipeline: a larger degree of automatization of release tasks (e.g. compiling release packages for the different platforms) and few tasks we have to take care of manually (e.g. release public relations).

Proposed timeframe: 2 weeks. If we have a lean release pipeline and we actually used the sprints to debug sprint-related problems instead of postponing their investigation for the release phase, we should manage to handle all release tasks in 2 weeks.

Post release phase

Post release phase will be mainly filled with three activities:

  • Gather release feedback that will be valuable in the upcoming planning phase of the next (release) milestone.
  • Monitor bug reports and decide if it's necessary to actually address them and ship a fixed release package.
  • Relax. We just shipped a major release. Time to recharge the batteries a bit.

Proposed timeframe for post release phase: 2-4 weeks. 4 weeks might be necessary if we actually decide to ship a fixed release package of the previous release.

How many releases per year?

If we manage to follow the proposed timeframes for the different phases of PARPG development, we could ship a stable release of PARPG every 4-6 months.

Personal tools