From Post-Apocalyptic RPG wiki

Revision as of 11:12, 18 September 2011 by Shevegen (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Project coordination.png This article covers project coordination information!

Project coordination includes development guidelines, milestone planning and the project's roadmap. Taking a lead role in project coordination is a key task of the project management department.

This article describes the basic steps to an imaginary feature-complete 1.0 release of PARPG. As a rule of thumb: keeping information up to date about the current milestone that we're working on has the highest priority. Information on completed milestones (especially for milestone 0, milestone 1 & techdemo 1) might be strongly outdated and/or incorrect but is stored here nevertheless for archiving purposes.

Fixme.png Please help FIXME: This article became slightly outdated and doesn't reflect the adoption of Agile concepts yet.

General remarks

Release strategy

As lesson learned from the past: we should try to release more often (and earlier) than we did in the past. Therefore every milestone at Trac should also mark a public release of the game and its tools. This includes compiling release packages for the different platforms, offering these packages for download at sourceforge and announcing the releases at our blog. Further release annoucements at other places besides the blog will be considered, taking the amount of work/gain ratio and the targeted audience of the release into account. E.g. annoucing the techdemo releases at websites like would surely help with attracting additional contributors.

Targeted audience

The next couple of milestones will be techdemos of PARPG that will focus on mainly improving the PARPG game engine and tools of the asset pipeline. At this still quite early point in development, the engine is still missing functionality and there is no agreed upon working and easy to use content creation pipeline. Therefore it does not make sense to try to just cater to potential players of the game. The techdemos will rather focus on getting engine, tools and the content pipeline to a point where it's easy to add new content into the game.

For the time being the techdemos will rather target potential contributors to PARPG, both in the field of programming as well as in the content departments (writing, graphics, maps, etc.) than to primarily cater to players.

The open source community is known to provide early feedback, especially when public release packages are available. Therefore we shouldn't be worried about putting off potential players with techdemo releases that are developer-centric. If we clearly state the purpose of the techdemo releases in the release announcements, we can avoid raising false expectations and furthermore encourage feedback by players who aren't put off by the techdemo nature of the release.

Feature focus vs. fixed release dates

Instead of aiming for specific release date for a milestone, we'll rather use a feature-centric approach. When we're close to completing a milestone, the team will sit together and flesh out the plans for the next milestone to come. We should agree upon 1-3 important features / enhancements for a milestone and focus on them instead of trying to tackle everything at once and therefore byting more than we can chew. Focusing on a small number of important features will help us to get into a development rhythm and to ship releases on a more regular basis.

In case it turns out that the planned features will result in a lot of more work than anticipated, we should prioritize them and push back lower priority features to the next milestone.

Once the targetted features are implemented, documented and tested, the milestone can be closed, the release can be shipped and planning for the next milestone can start.

Release theme

Each milestone/release should have a "theme" that it follows. As we rather want to focus on a few but important features per milestone, these features should be implemented in a more substantial and holistic way. It's tempting to focus on actual implementation of specific features and forget about other important related areas that will be vital to the success of the project. While writing code is fun, these other fields of work are equally important:

  • Discussion among the developers, requirements engineering, design and proposal drafting
  • Documentation of the written code
  • Writing unit tests for the implemented functionality if possible / desired
  • User documentation, especially in case we're talking about tools that are part of the content pipeline, as devs with no programming background will be the main users of these tools

So instead of focusing on implementing a lot of half-baked and poorly thought out features, we should rather focus on few important features and invest our time into properly fleshing them out before implementation starts, documenting the code and writing unit tests and documentation how to use these tools and features.

Recruitment strategy

For now, we'll try to rather have a small and focused team than a large and therefore hard to handle one. The current team in place is capable to complete the techdemo 2 milestone. Once techdemo 2 has been released, that we can try to find another Python programmer who can strengthen the programming department, taking into account that the next couple of techdemo releases will focus on the PARPG engine and content pipeline tools.

Once we got specific tools ready to testing, we can try to find developers for the specific fields. E.g. trying to recruit a writer once there is a GUI tool for dialog creation / editing.

Next milestones to tackle

Techdemo 2 (current milestone)

Main goals

The goal of this milestone is to document the existing dialog engine and remove some of its complexities. To do so, the dialog data format will be adjusted to feature explicit keywords to reduce the amount of magic that the dialog parser does under the hood. Furthermore we'll implement support for primary stats for player and non-player characters. This includes a (console) interface to query these stats, modify them and save back the changes to the file format in which the data is stored.

The planned features of techdemo 2 won't rely upon a large number of new assets to the be created. If there is the need for new assets for testing purposes, we can create programmer art for the time being as this will be sufficent for testing purposes. This can be replaced with more polished assets later in development.

Targetted audience

The release will mainly cater to developers who consider to contribute to PARPG as Python programmers. The dialog engine related changes are a first step towards a GUI for dialog creation at a later point to attract writers for PARPG in the long run.

Recruitment of additional developers

We'll rather focus on finding a development rhythm for the team instead of getting more developers involved. Once we're close to completing the techdemo 2 milestone, we can try to find another Python programmer who could help with the tasks of the techdemo 3 milestone that lies in front of us.


No scheduled release date. Techdemo 2 should be shipped once the two key tasks (documenting and improving the dialog engine and implementing support for primary characters stats) have been taken care of.

List of tasks

Techdemo 2

Techdemo 3 (next milestone)

Planning for techdemo 3 will begin once we're close to shipping the techdemo 2 release. Here's a quick and dirty copy & paste of tasks that were originally scheduled for techdemo 2 but have been pushed back to rather focus on a few but quite important aspects. We can use this list as a starting point to decide which features / tasks should actually go into techdemo 3 and which ones should be pushed further back.

Milestone n

  • Create a feature-complete PARPG 1.0 release.
  • Deadline: can't be specified at the moment. It's likely that we'll need to work on such a game at least for several years even if things work out way better than imagined. This kind of project is a long-term undertaking!
  • Next step: enjoy the free time :-)

Completed milestones

Milestone 0 (completed)

The planning stage. In this first phase of development the basic project vision was written down. The initial concept was more a project vision - a vision how to properly manage an open source project - than a fully fleshed out game vision. There are some basic decisions (Python as programming language, open source license for code and assets, choice and consequence, Fallout-inspired) and some basic proposals (turn-based combat, party interaction, FIFE as engine of choice) but the vast majority of the decisions that we will need to make has not been set in stone in this phase.

The main reason is simple: I'm coming from a project management background and although I have a basic understanding of the whole process of developing a RPG, I'm by far no means an expert in any of them. Therefore I would like to leave all decisions that are not mentioned above to the relevant departments: programming, graphics, audio, writing & game mechanics. Experienced developers who have a track record in these fields have a far better basis to make informed decisions in these regards than I have. The key design elements that I have mind are outlined at a separate article.

The planning stage will be also used to set up the basic infrastructure that is needed to properly operate such a project: sourcecode and asset version control, issue tracking, forums, wiki and an irc channel. Furthermore it's a good idea to have a public blog to communicate with the community. The idea of setting up all of these things in the planning stage is two-fold. First these things will be needed anyway once we've assembled a team. So by setting it up early there will be no unnecessary delays. Furthermore developers are of course sceptic about projects that basically consist of just a short written down idea. So having a somewhat fleshed out concept that is publically available and the infrastructure in place I can prove at least to a certain degree that I'm willing and capable of fullfilling my project management tasks.

The basic concept has been fleshed out now and we can therefore tackle the next step at this point.

List of tasks

Milestone 0

Milestone 1 (completed)

General remarks

The recruitment and concept stage. In this second phase of the project we will be looking for additional developers who would like to join the effort. We're confident hoping that the outlined concept, the experienced of the involved developers and the set up infrastructure are promising enough to attract more dedicated developers for the various development departments. Dedicated in this context means that we would like to find people who have prior experience in the relevant field and feel capable of being responsible for the department and making informed decisions.

A list of basic proposals and questions for each department was written down in the planning stage. Now in the concept phase it's time to actually look into these proposals and questions in detail. The responsible developers should be able to flesh out concepts in more detail, answer open questions and suggest how to proceed in this specific field.

We won't need to fill all possible positions that might be needed to create a full scale game right away. It should be sufficent to get started with development to have at least one experienced developer working in the programming, graphics, writing and project management fields. We already found dedicated developers who take care of graphics, game mechanics and project management-related tasks, so the focus of recruitment in this phase will lie on finding developers for the programming and writing departments.

It's hard to say how the next steps will look in detail because it will vastly depend on which positions we will be able to fill in this phase. The process might for example differ in case a programmer joins right away but we don't have luck in finding a writer for the project. The first steps for each department can be outlined nevertheless.

Programming department

The programming department will focus on examining the Technical framework proposal. The decision to use Python as programming language of choice (and C++ in case we would like to implement something time-critical) for PARPG is set in stone simply because it seems like a good choice for the reasons outlined in the technical framework article and that it is pretty much impossible to recruit programmers without having an actual programming language specified. We've agreed to evaluate the FIFE game engine for PARPG and started to base PARPG on the FIFE techdemo Rio de hola, modifying it in small steps to turn it into a custom game. The latest version of the game can be found in our public Subversion repository, where you can Download it from.

Writing department

The first task for the writing department will be to take a close look at the setting draft. So far we've agreed on a post nuclear winter setting while the plot will play in Scandinavia. Besides that it's up to your creativity to turn these basic guidelines into a sophisticated storyline for PARPG, working in close cooperation with the setting writers.

Graphics department

Outlining actual tasks for the graphics department is tricky for me. While working on FIFE I was in contact with programmers most of the time and we had a hard time to attract any artists. So I do unfortunately lack proper knowledge about the field due lack of experience in working together with artists. That basically leads two consequences:

  1. We will need somebody for the graphics department who has enough experience to not depend on too much well-grounded feedback by the rest of the team. Developers from other departments might already have prior experience in working with artists but unfortunately I do not.
  2. You got a lot of creative freedom in the graphics field :-)

The graphics artist would basically propose what the first steps for the department should be. I personally imagine that it would be useful to get in contact with the programming and writing deparment right away. The programmers can tell you how the engine will restricts the graphics field. Close contact with the writer might turn out be useful to agree on a visual style that suits the setting. As I'm lacking proper knowledge of the field I'm even more than willing to leave all kinds of actual decisions in this department to the artists. The only decision that is set in stone is that PARPG will feature isometric 2d graphics. The rest is up to you.

Additional departments

Besides the essential departments programming, graphics, writing and project management we can consider to try to recruit additional developers for other fields as well. E.g. it might be useful to find a composer or an additional game mechanics designer early. To all of the other departments the same applies as to the ones listed above: we would like to find developers who have already worked in the field and want to work in a team project now or who even gained experience working in a larger team.

The style of music might vastly depend on the setting of the game. I personally really like the eletronic ambient music featured in Fallout 1 & 2. As I have just few experience working with composers and sound engineers there are no restrictions from my side in this field.

It might be hard to find an another experienced mechanics designer as the field might suffer from the same lack of professionality as project management in hobbyist projects. Fortunately we already found somebody who takes care of game mechanics so finding another developer wouldn't be mandatory though benefits and potential drawbacks of getting more game designers involved should be discussed.


At the end of the the concept and recruitment phase we have hopefully assembled a number of somewhat experienced developers. These developers should have outlined the basic guidelines for each department by then so we could start to put all the little pieces together to turn them into an actual game. I think that four months is a reasonable timespan for the concept and recruitment phase so we can hopefully proceed to the next step over the the course of the summer.

List of tasks

Milestone 1

Techdemo 1 (completed on March 10, 2010)

General remarks

The demo stage. Now that we've outlined the basic guidelines of PARPG development we're ready to create an actual game. A lot of projects tend to suffer from aiming too high, therefore we'll try to tackle a somewhat realistic aim in this phase instead of reaching for the stars.

The demo

The idea is to create a very basic one town / location demo. The advantage of such an approach is that although the amount of work needed to complete such a demo is still easily underestimated, it gives is a good idea how much effort will be needed to create a full-featured game. Furthermore all departments can test their concepts ingame and see how they work out. We can find out more about the issues of the engine, learn what kind of assets creation toolchain gives the best visual results and how writing and mechanics work out ingame.

Creating such a demo also helps to gain experience in working on a team and to gain specific experience in your field. The advantage over creating a full-featured game right away is that a demo only needs a limited scope and amount of content. We could always expand the demo in case we feel that development is coming along well.

Recruitment of additional developers

While we'll try to find rather experienced developers for each department in the concept phase of PARPG, we might need to expand the team once the general guidelines for each department has been lined out. Accepting less-experienced developers who would like to have their first stab at a team project offers a number of advantages and drawbacks.

It might be even pretty hard to find developers in the starting phase of the project who have the necessary experience to guide development in this field. As we're recruiting from a limited pool of possible developers, the simply lack of experienced devs might make searching for less-experienced ones mandatory. The main drawback of their lack of experience is that they might feel overstrained by making informed decisions. Furthermore they'll need guidance by the more experienced developers of the department.

I think that both drawbacks are no major reason to not try to recruit somewhat less-experienced developers in the demo phase. The more experienced devs will have worked out guidelines for the different departments in the concept stage so newcomers can use this as basic orientation. Furthermore the experts can support the newcomers with feedback and guidance at least to a certain degree. However this should not become their main task on the team as they wouldn't have time to work on any key tasks themselves anymore.

Getting rid of the working title?

While working on the demo the setting and story should be worked out to the degree that we could reconsider the name of the project. PARPG is a working title that reflects just the most basic concepts that were set in stone when the project was founded: a post-apocalyptic RPG. Now that the concepts are far better fleshed out as back then, we might have better ideas how the game should be called.


We can hopefully create this one town / location demo in the timespan of about 9-12 months. We might need to reconsider the amount of planned content and features for it in case this timespan turns out to be rather unrealistic later.

Should we continue?


List of tasks

Techdemo 1, Techdemo on trac

Personal tools