From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Glossary.png This article is a glossary!

This article lists agreed upon terms to ease communication. Glossary articles are primarily targeted at the developers of PARPG; either developers of a specific department or the whole team in general.

This is the general project glossary. It contains all important terms that are relevant for contributors regardless of the field they're contributing to. Department-specific terms should reside at the glossary articles of the different development departments.


What should be part of this glossary?

  • Hard to explain terms that benefit from being defined in a concise manner, e.g. ingame assets.
  • Custom terms that are somewhat unique to PARPG and have a different meaning otherwhise, e.g. proposal.

What shouldn't be part of this glossary?

  • Very simple yet hard to define terms. You can't really explain terms like code and assets in a short, comprehensive and yet unambiguous way.
  • Trivial terms. This is a developer glossary so we shouldn't cater to players in this regard.
  • Terminology that is mainly relevant to one specific development department. Define these terms in department-specific glossaries.

Common terms for all departments

Asset pipeline

Asset pipeline
The asset pipeline is a collection of tools and documentation how to create raw assets for PARPG and how to transform these raw assets into ingame assets that are used in the game.
Ingame assets
Ingame assets are the ingame versions of our assets. E.g. rendered graphics, transcoded lossy music & sound effects, rendered diagrammes, etc. These assets are stored in trunk alongside the code.
Raw assets
Raw assets are the source versions of our assets. E.g. 3D models and textures, lossless (PCM, WAV, or FLAC) music & sound effects, SVG graphics, etc. These assets are not stored in trunk itself, as they're not needed to run the game. Instead they reside in a separate media branch as they're occupying a large amount of space.

Common articles

Common articles
Common articles are a standard set of wiki articles that every department has. While these articles exist for every department, their content varies from case to case.
Current tasks
Current tasks are wiki articles that contain a list of tasks that the developers of a specific department are currently looking into or working on. These lists are meant as an easy way to let the other developers of the team know who's currently working on what.
How-tos are set of wiki articles that explain how to contribute to the project and how to use the most important projects tools (Subversion, Trac, Wiki).
Idea dump
Idea dumps are utilized by the different departments to keep their department starting pages clean. The idea dumps can be used to dump notes at the wiki and flesh out work in progress articles.

Development process

Pre production
Post production


The PARPG project is split up in several departments. Each department focuses on different tasks of the game development process. The departments maintain separate current tasks lists, have a department philosophy and department-specific workflows and guidelines how to produce content (which can be assets, code and/or documentation, depending on the department).
Department starting page
Every department has a starting page at the wiki. This starting page contains direct links to the most important department-specific wiki articles.
Everything we produce that is neither code nor an asset. Documentation (usually) resides at the project wiki. Some departments might use the term content over documentation in their specific field of work, e.g. writing content instead of writing documentation. That's because is some fields content sounds more intuitive than documentation. This doesn't change the fact that the content of these departments is just masked documentation.
Infrastructure proposal
Infrastructure proposals are suggestions how to improve the project (infra)structure; this also includes the code toolchain and tools for code documentation.
Subversion is a revision control software utilized by the PARPG team. It is commonly used in all kind of software development projects. Every development department maintains a department-specific article how Subversion is utilized in their field of work.
Tickets reside in Trac and are used for a number of purposes: filing bug reports, requesting new features or new asset pipeline tools.
Trac is a project management software we're using. It's similar to a bug tracker but offers additional features such as a Subversion repository browser, visualized DIFFs and a milestone planning tool. Every development department maintains a department-specific article how Trac is utilized in their field of work.
Our project wiki. This is where most of the project documentation resides.


Community member
Community members mainly contribute to PARPG development by providing feedback and tossing around ideas.
Contributors support PARPG development by sending in code and asset patches or spread the word about the project.
Developers have build up trust in the community and have gained write access to our version control repository (see Subversion). They're contributing to PARPG on a regular basis.
Lead developer
While most developers are primarily interested in working on the game itself, lead developers are willing to help coordinating the project. They set the direction in their field of expertise, they monitor the workflows of their departments and apply changes where necessary to ensure a smooth ride for the other developers in their field of work. They're leading by example.


Creative vision
The creative vision of PARPG includes the core game philosophy of all creative fields: gameplay, art direction, audio design, writing philosophy.
Department philosophy
Philosophies are guidelines how specific departments approach their work. They set a direction for development, define good practices and explain why these good practices are used.


Feature proposal
Feature proposals are suggestions for features that the PARPG engine should support. They reside at the wiki and can be based on initial feature requests. Ususally developers and lead developers flesh out these substantial articles to explore the pros and cons of an engine feature as basis for later implementation.
Feature request
Feature requests are suggestions for features that the PARPG engine should support. They reside as Tickets in Trac and can be used as basis to flesh out a more substantial feature proposal. Community members and contributors usually prefer to file tickets for feature requests instead of fleshing out a detailed feature proposal.
New style meeting
New style meetings are quite the opposite of old style meetings. New style meetings are used to reach agreement on proposals that were fleshed out in advance. As new style meetings are based on substantial research done in the proposals, they are more productive than their old style counterparts.
Old style meeting
Old style meetings gave us nightmares so we decided to get rid of them. These meetings were badly prepared, unstructured and often didn't lead to agreements or any substantial result. Therefore we decided to rather have new style meetings in the future.
Proposals are suggestions about introducing substantial larger changes to the game, the project and/or its infrastructure. As substantial changes will greatly influence the project, they can't be implemented on the fly but need to be fleshed out in detail first, to get a better idea of the pros and cons of these proposals. While some proposal types are utilized by all development departments, others are department-specific. For details, check out How to work with proposals.
Tool proposal
Tool proposals are suggestions for development tools that would improve our asset pipeline. These kind of tools are usually requested by the other development departments. The programming department evaluates the tool proposals and transforms them into code proposals. The code proposals document how to implement the suggested tools.
Tool request
Tool requests are suggestions for development tools that would improve our asset pipeline. They reside as Tickets in Trac and can be used as basis to flesh out a more substantial tool proposal. Community members and contributors usually prefer to file tickets for tool requests instead of fleshing out a detailed tool proposal.
A workflow describes the translation process from mere ideas to the implementation of agreed upon (game) concepts.
Personal tools