Dime Battleplan

Contains the overal strategy that is used to achieve the goals set in the concept document. Contains a high level plan of the client developement up to version 1.0, and what general features should be implemented for each milestone. Contains a more detailed plan for the next few iterations. Updated whenever required features are implemented.

A battleplan defines the high level strategy for reaching the goals set in the concept document. It defines what functionality should be in every version up to 1.0, and can suggest some goals to pursue after that. It also defines a bit more specific goals for the next few iterations, and should be updated whenever those goals are met, to decide when the version number of the client can be increased. The Battleplan is laid out as a series of milestones. Each milestone usually increases the minor version number, and generates some deliverable.

Version History

Draft 2001-11-16 nikal Initial battle plan.
Draft 2001-11-16 zzorn Merged in comments from the Battleplan Discussion.
Reviewed 2001-11-16 zzorn Merged in comments from the Battleplan Review.
Reviewed 2002-01-19 nikal & zzorn Revised the first few iterations so there were clearer goals to work for.

Introduction

General notes about the battleplan, what is required of it, how is it affected by the battleplans or implementation state of other products, how is needed effort and estimated number of dedicated develpers balanced, any special deadlines we want to have something running for (trade shows, etc), and the overal goals and strategy used when creating this battleplan.

Milestone 1

Implements version 0.1

Version 0.1 should be able to connect to STAGE or Cyphesis, and do Out Of Game chat. It should also support lists of people present, emotes, etc. Should have working packages for the most popular linux distributions, some installer or easily installable package for windows, and preferably also a working binary for Mac or some other platform.

Version 0.0.1

The purpose of the first iteration is to set down the initial framework and build process, to serve as a starting point for subsequent work.

The basic Dime Application will be written. It will have it's own main loop.[DONE]
Register at least one test service with the service manager, start them before the main loop, and stop them after the main loop. Write out notes to the console about stopping and starting services, and the success of starting them.
The dime application will pop up an SDL window and the main loop will run until "ESC" is pressed. The Application will then stop all running services and exit.
The release must compile and run in both Windows(MingW, and MSVC), and Linux(gcc) based on compile scripts that we write.
Build Scripts for binaries, document, perhaps also initial work on automatically building rpm and deb packages.

Version 0.0.2

The main goal of the second iteration is to create an usable framework API and documentation for it, to make it easy for new developers to implement new components and services.

Basic functionality of the framework classes(Services, Components, DataModel*) should be more or less usable in iteration 0.0.2. We should also have documents explaining the architecture and API.
An example service, and component, will be written which create and use things in the data model. This can serve as a tutorial for newbies who want to write services/components.
We can use 0.0.2 as a review point of the build scripts we sat up in 0.0.1.
Preliminary Isometric GameView will be used in the pop up window
Work will be done to get CS able to be displayed on an SDL window also.
Initial work on scripting

Version 0.0.3

The main goal for this iteration is to create several services and components, to find problems and improvement ideas for the framework API.

Initial implementations of the most important and simplest services will be done in order to review the Services API/architecture.
Initial implementations of some simple components will be done in order to review the Component API/Architecture.
Initial work on GUI to allow a ComponentView class that represents the visual UI for a component will be done.
Pick up more developers, and find suitable services, components, and framework parts for them to work on.

Version 0.0.4

The main goal for this iteration is stable framework classes.

Service API/architecture will be modified to reflect the review done in 0.0.3, and all services will be rewritten to reflect the API changes.
Component API/architecture will be modififed to reflect the review done in 0.0.3, and all components will be rewritten to reflect the API changes.
Work will be started to create the GameView(2D and 3D) classes and display them as a UI component which may or may not use the entire SDL surface.
Simple scripting should now be possible.

Version 0.0.5

The main goal for 0.0.5 is to be able to connect to a server, and log in. Focus is on network, communication with servers, and atlas.

Support functions in a service for finding a game server through the meta server, and logging in.
Implementation of services to establish connection to a server, and handling atlas messages.
Working Atlas debug panel, with ability to view incoming messages, and manually compose messages for sending.
Server information and selection Panel created from components or as a single component.

Version 0.0.6

The main goal for 0.0.6 is to be able to participate in Out Of Game chat on a STAGE and/or cyphesis server.

Having the chat panel listen to the relevant messages, and sending back new messages.
A very simple GameView showing the different rooms (and persons in each room, if that data is available?). Or alternatively, a tab system in the chat panel to switch between channels?
Optional work on logging in simultaneously with multiple characters?
Optionally connecting to an Acorn/Mason server and displaying terrain and perhaps entities in the 2D ISO GameView.
Beginnings of sound module, should do beeps in chat, and optionally special signal when users nick is adressed.
Support python, lua, and/or some other existing scripting language, and provide a scripting API for accessing the data model, and for managing components and connections between scripts, components, and the data model.

Version 0.0.7

The main goal for 0.0.7 is to have a stable and usable client that can be used to participate in STAGE meetings, and for Out Of Game chat. Focus is on stability, usability, portability, and good packages.

Add some small features needed to improve usability, such as nick completition, good default colors and perhaps saving of user color settings, logging, etc.
Add some interface features implemented with scripting, to test it (this could be combined with the above point).
Establish the standard layout to be used in Dime for the Data Model.
Good packaging for all supported platforms.
Fixing existing bugs.
A neat default theme.
User documentation, installation instructions.

Version 0.1.0

When the client has been tested for some time, it is promoted to 0.1 and released officially on freshmeat. Downloadable packages should be available on victor and other relevant places.

FAQ
Polished documentation.
Bug fixes
Announcement to freshmeat, CB, etc.

Milestone 2

Implements version 0.2

Acorn

Milestone 3

Integrate Yup as a 3D GameView

Milestone 4

Basic Mason support

Milestone 5

Full Mason support, information object editing, scripting (Python and/or Lua?).

Version 1.0

Requirements for the 1.0 version

Future Versions

Some ideas for where to steer the developement after an 1.0 version.

New features.
Stability.
Performance.
Security.
Maintenance.

Conclusion

General comments about the battleplan, summary of central ideas.

Current Issue: February 2003, Recent Issues: January 2003, November 2002, October 2002