Roadmap

This article describes the basic steps to an imaginary feature-complete 1.0 release of PARPG.

The promise of a plan
The plan presented here is imaginery and unrealistic. That means that I'm fully aware that creating a complete roleplaying game will be far more difficult than outlined here. However it's still useful to have a rough plan in mind that we'll try to follow in the development process to coordinate the efforts. All kind of feedback is appreciated.

Milestone 0
The planning stage. In this first phase of development I'll write down the basic concepts of the project vision that I have in mind. I want to underline that my personal concept is 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 is not 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.

If nothing goes wrong the basic concept should be fleshed out until late February / early March and we could tackle the next step then.

General remarks
The recruitment and concept stage. In this second phase of the project I want to start looking for additional developers who would like to join the effort. I'm hoping that the outlined concept, my personal experience and the set up infrastructure are promising enough to attract dedicated developers for the other development departments besides project management. Dedicated in this context means that I 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 will have been written down by me 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 departments. I can personally take care of all project-management related efforts so the focus of early recruitment will lie on finding developers for the programming, graphics creation and writing department.

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. Concerning the engine question I got a strong preference for FIFE but I'm more than willing to reconsider it in case the programming department evaluated it and came to the conclusion that there are far better-suited engines and libraries for the purpose of creating an isometric 2d roleplaying game. Whatever engine we'll choose: the next step for the programming department will be to take a closer look into the engine to find out what is well supported and what kind of functionality we would have to implement on our own.

Writing department
The first task for the writing department will be to take a close look at the setting proposal made by me. The only decision that is set in stone is that PARPG will feature a post-apocalyptic setting simply because of personal preference. When I decided to found this project I wanted to work on a game that I would enjoy playing myself. And this kind of game would be a post-apocalyptic RPG, hence the decision to make this an essential part of the PARPG concept. Besides this very basic direction for the setting you got full creative freedom to come up with whatever you think might be a creative, enjoyable frame for the game. My personal preference would be a setting similar to the desert setting that is featured in Wasteland and Fallout. I haven't worked with experienced writers yet and I know too little about the field to actually make a more detailed and informed proposal besides that. So feel free to come up with something totally different that fits into the post-apocalyptic category. I'm positive that the other departments will be open to all kind of post-apocalyptic settings that are fleshed out at least to a certain degree and show a kind of vision into which direction the project should go to.

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 a 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 have already 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 experienced mechanics designer as the field might suffer from the same lack of professionality as project management in hobbyist projects. But it should be worth a try nevertheless. Fallout's mechanics had obvious references to its pen and paper roots so I plan to recruit possible game mechanics designers from established RPG communities; pen and paper and computer RPG ones. One possible starting task of a mechanics designer would be to evaluate existing RPG rulesets and creating a draft that lists advantages and drawbacks of each one. Another option would be to create an own ruleset from scratch or to strongly modify an existing ruleset to our needs and to avoid legal issues.

Schedule
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.

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.

Schedule
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?
In case we succeeded in creating the demo version of PARPG, it'll be time to reconsider our plans for a full scale game. We should then have a solid understanding of the workflow, team interaction, our engine of choice, the asset creation pipeline and the whole creative process of creating a game. If we feel like continuing to invest time into the undertaking, we'll go on. If it feels totally unrealistic to create a full-featured game that we would enjoy ourselves (amount of features and content-wise), we can also decide to be content with what we have achieved and move on to new projects. Write a post mortem, learn from mistakes, be grateful about the gained experience, add the demo to your portfolio and having enjoyed the spent time.

Milestone x

 * 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 two additional years even if things work out way better than imagined. This kind of project will be a long-term undertaking in case we decide to try to create a full game after the one town demo.
 * Next step: enjoy the free time :-)