Battleplan

The plan can be stated very simply: Code First, then Document!

In order to cope with the many critiques and ideas that people have for game servers, we will take the approach of encouraging any and all such individuals to write White Papers to fully outline their theories or observations. (Fringe benefit is, it helps with documentation!) No guarantee that we'll use every idea submitted as White Papers, but we certainly will read them all.

For the schedule, we'll likewise keep it simple: It is our policy not to pre-announce release dates. There are simply too many variables affecting when something can be delivered, and until someone pays us to do it full time, none of us can give STAGE full priority.

Currently in Testing: STAGE-0.0.3
Under Development: STAGE-0.0.4

STAGE-0.0.0 (RELEASED)

Starting from the E4 documents, we'll quickly throw together a whitepaper encompassing theory, requirements, design, battleplan, etc. We'll define an approach to take for modularity and define a concept for the core architecture, which should at the least identify the following: modularity, database, entities, atlas interaction, and account management. This will be STAGE-0.0.0. (DONE)
We'll ask for whitepapers on the topic of game architecture, and if we get none we'll use the reference architecture, from the WhitePaper. (DONE)

STAGE-0.0.1 (TAGGED)

Next we'll place all focus on the code, and forget about documentation for a while. We'll create Thor and put together a separate modularity system. We'll lay out the basic classes for the other parts, but it'll all be stub, stub, stub. It'll look like a server but won't do *anything*. We'll fill it full of NOTEs and TODOs, so that people will see what needs doing next. (DONE)
Some basic doc files (README, AUTHORS, etc.) will be prepared. (DONE)
We'll tag this version, but there's little reason to release it, so we won't. (DONE)

STAGE-0.0.2 (RELEASED)

We'll take the latest version of Atlas-C++ available at this point and integrate it into the server. We know it will evolve, but just want to get the server to the point where we can connect to it, for now. We'll spend some time reorganizing the code, and flesh out the stubbed functions enough to be able to run the server and connect to it via telnet. (DONE)
We'll ask for whitepapers defining player account systems at this point. We'll shoot for one that is well defined and simple. The others we'll keep in our back pocket for later. (DONE)
An INSTALL guide should be produced as part of this release. (DONE)

STAGE-0.0.3 (TAGGED)

Account management (Mercury) will be the next step. We should be able to create new player accounts and attach them to one or more Entities. In order to achieve this, we'll need to ensure Echo is roughly implemented in the system. We'll also ensure that Galileo is present, so we can start logging error messages we run into. We'll need a very rudimentary version of Shepherd, so that we can connect clients to entities. The entities don't need to be able to do anything yet. It's okay for Entities to be created directly by Mercury, rather than through proper channels. The objective of this release is to get STAGE able to handle connections. (DONE)
From this point on, we'll always tag and release each version. (DONE)
Since collision detection is going to be a biggie, we'll encourage people to begin work on researching this now, and get at least one preliminary whitepaper published in the chopping block. (DONE)
To get any further past this point, we're going to need to have what we've done so far, documented. We will update and expound on the architecture document, and produce design documents detailing the as-is design of two of the engines. (DONE)
We should begin a peer review of at least one class. (DONE)
STAGE version 0.0.3 will use Atlas-C++ version 0.4.2 (DONE)

STAGE-0.0.4

With Thor and Mercury connected up to clients via Atlas, we now have enough to create a basic duty chat server. And indeed that is the goal for this step. STAGE-0.0.4 will be targeted to providing basic "Out Of Game" chat serving capabilities. We'll try to have a simple online roleplaying session as a PR stunt, so we can claim to have used STAGE for gaming already. We require the following features implemented:

Talk to other people logged into the server (DONE)
Emote via /me (DONE)
Connect via a text client and one graphical client (DONE)
At least one client supports cut and paste in some fashion (DONE)
Personal logging either through client or server (DONE)
Get list of other players currently logged on (DONE)
Get a listing of all entities existing in the game server --[Lee: probably not possible]
Receive indications of when people log on and off (DONE)
Can store comments persistently in your player account on server

Alternative ideas for message dispatching systems will be called for at this point. We'll select the best approach for Pegasus prior to 0.0.5 and try to get it implemented and reviewed. Event and Action handling should also be worked out prototypishly.
We will finish producing documentation to describe all of the core engines as they work currently. It is allowed for the documentation to be crufty and disorganized, but there should be a decent amount of it. We will also release a document describing the RIM system's conceptual design, and produce one prototype-style RIM.
We will have about half a dozen different areas of the system code reviewed. For each review, we will save the comments in a .review.txt file, and a description of the decisions made in a .plan.txt file. At least half of the reviews should have the recommendations fully implemented.
We should have the root stage/sys/ directory "clean" of all code files other than main.cpp and the makefile.
STAGE version 0.0.4 will use Atlas 0.5.0 (or later, TBD). We should feel like the network integration is pretty dependable.
Entity/Archetype system should have at least one strong candidate which need to be well specified on conceptual level. We will still be flexible allowing changes on implementation phase.

STAGE-0.0.5

0.0.5's objective is to finish fleshing out the architecture. We need to be wrapping up any experiments and prototyping and focusing on solidification. We will also initiate a number of endeavors to start on things that need to be achieved prior to implementation of Pong.
Pegasus, the message dispatcher, will come in at this point, allowing us to load and unload modules on command. We will, as a part of this, pin down the modularity system in code, with working examples. It doesn't need to be perfect, but we should feel pretty confident of our design approach.
A preliminary document will be produced describing how to create modules with this system, and we'll encourage whitepapers describing ideas for how we could improve upon this modularity system.
We will have two chat systems implemented at this point: An Out of Game Chat system, built into Mercury::Lobby (or whatever), plus an in game chat system that operates via a RIM.
We will come up with a standardized unit testing approach for the engines and modules. We don't need to implement this, but merely brainstorm and come up with the standards, interfaces, calling syntax, etc. We'll put our design ideas into stage/docs/unittesting.txt.
A lot of cleanup of the documentation should be done. The old E4 stuff should be integrated, rewritten, reorganized, or etc. The docs should be roughly consistent and reasonably thorough.
All of the first level subdirs (stage/sys/*) should be "clean" - no stray files, no unimplemented headers, and no unofficial "scaffolding" code. All filenames and class name syntax should follow the coding guidelines.

STAGE-0.0.6

The objective of 0.0.6 is to firm up a foundation to build Pong on top of. There are three elements we need to be focused on for this purpose: A) Code cleanup, systematizing, reviewing & ordering, B) Documentation of the design, and C) Ensuring the overall architecture is solidly set.
The Entity/Archetype system should be felt "nailed down" at this point and unlikely to change in the future. The Entity creation system should be refactored and cleaned up. It should be possible to create, log into, log out of, delete, and rename entities. During entity creation, the user will specify an Archetype to derive from. There should also be a crude, rudimentary mechanism to generate new Archetypes (it's okay for this to be buggy/kludgy at this point.)
The Account management system also must be fairly well fleshed out, with functions to rename the player, store account info persistently, retrieve a listing of account info, and get a listing of other players logged in. There must be a password system (nothing elaborate or uncrackable.)
The RIM modularity system should be fully roughed out and reduced to practice. Revision and refactoring will be delayed until post-Pong, so in this release we need to feel it to be "good enough" for at least the next four or five releases.
We'll complete a basic kinematic physics system, including simple collision detection and resolution. It should permit movement in all three dimensions. Simple collision detection and resolution (good enough for Pong) is required. Movement modes and various ways of utilizing the movement system should be implemented in RIM's, and we should have at least three different Archetypes demonstrating three different movement mechanisms.
We will have completed the first go-around of design/code reviews. Many of the recommendations should be implemented, as well.
We will comb through the documentation and verify it is internally consistent. We want to be able to focus entirely on the code for the 0.0.7-0.1.0 series, so we do not want to include too much info in the design docs, lest it become outdated, but we do want to be sure to cover all the basics.
Finally, we will implement a system-wide standard unit testing approach. Each subsystem must have a perl script called unittest.pl that allows us to build and run various kinds of tests on the subsystem. We don't have to implement any of the particular tests, we merely need to have the mechanism in place to allow people to do this.

STAGE-0.0.7

0.0.7 is a major milestone. The code at this point should be very solid and stable. We should not have anymore system level architectural developments in the works. We will focus on testing, polishing, and documenting what we've done. STAGE still need not do much beyond just chat, but at this point it needs to do chat quite well.
At this point, Thor, Echo, Mercury, Pegasus, and Shepherd will be fully fleshed out, well reviewed, and documented. STAGE-0.0.7 will mark the completion of at least first-cut implementation of all the subsystems needed for the core.
We will produce a user's guide for this version. It should be kept rather top-level, so that we can extend it later. It will be done in LaTeX and produced into HTML, Text, and PDF formats. It should cover installation, customization via RIM's, using the logging system, operation of STAGE as a daemon, connecting with clients, and other basic server usage topics.
The architecture and design documentation will be converted to LaTeX, and produced into Text, HTML, and PDF. It will be made available from the website as well as within the code distribution.
We will review and update the INSTALL guide, README, and other such docs.
We will update the architecture documentation to describe exactly how it all hangs together. The docs should all be in LaTeX at this point, and should be very clean and consistent. We should have a doc build system that allows us to generate HTML, text, or PDF versions of the docs.

STAGE-0.0.8 "RimDungeon 1.0"

At this point we finally have enough to complete a reimplementation of RimDungeon. So we'll take a brief divergence to do this. This will be our first chance to really test out the modularity system, so we shall. And that means we may change the modularity system at this point, to optimize it a bit. STAGE-0.0.8 will implement a game of RimDungeon.

STAGE-0.0.9 "RimDungeon 2.0"

We will focus on creating an improved version of RimDungeon, using the lessons we learned in the prior release, on the theory that often you don't really know how to do something until you've done it once already. This version should also include a much richer feature set and go well beyond being merely "playable".
As a secondary objective, we will focus on making STAGE very easy to compile and install.

STAGE-0.1.0

The Version 0.1.0 release will follow directly from 0.9.0 and will be primarily a stabilization/bug-fixing release, so that as we break things in the 0.1.1+ releases we will have a solid codebase to point people at. However, it's main purpose is going to be "reflective" - that is, reviewing, analyzing, and judging how we've done so far. The next version is going to break into the code and initiate some major refactoring, so we need to take some time to think about what we want to do.
First, we will begin a new cycle of thorough design reviews, to consider different ideas for fixing ineligant areas of the code. What refactoring do we wish to accomplish?
Second, we will recruit others to proofread and critique the documentation, and thereby generate a todo list for that.
Third, we will consider how RimDungeon was implemented in STAGE, and what the ramifications will be for implementing Mason, and brainstorm ideas that would make this simpler.
Fourth, we will review any whitepapers, concepts, or suggestions that we had to delay during the last few iterations, and consider folding them into the STAGE-0.1.x series.
Fifth, we will do a series of tests - specifically performance profiling and platform compatibility tests. This will establish for ourselves a set of standardized performance tests we can continue using henceforth, and provide us with a solid baseline to do benchmarking against.
Finally, once we've gathered sufficient ideas, we'll lay out the next ten steps or so for development.

Key:

IMPLEMENTED: The required features have been implemented on this item
TAGGED: The work has been verified and CVS has a release tag
PACKAGED: The code has been tarballed or zipped up for download
RELEASED: The work has been completed, packaged, and announced at Freshmeat