Project plan and schedule

Here's a general sketch of things to do for our project, for now. They are in a chronological order, although we will be doing most of the stuff at the same time. Our SourceForge site lists a more detailed task list. Currently the project is doing rather well, the architecture is nearing completion, and we have entered the implementation stage. Not long till we have our first real module... But this page is already out of date, because things are moving :o)

At first we will make a prototype of our software, to get a better grasp of things. The actual version will be planned and coded after the prototype.

Architecture

At this time we should be able to flesh out our design at the general level: what kind of client/server model to have, what components should there be, and which modules they will consist of.

One person should write a good document about this, so the plan will have coherence. Others will give suggestions to him, and the planning is not ready until they approve of it. The architect should not specify details of implementation, but he should be able to give suggestions about them.

Organization

Little formal organization is necessary, a well-organized anarchy should rule for projects like this. Strict and stagnation-prone hierarchies should be avoided. Everybody can take on tasks they are most suited to, we only need good communications so we know what everybody is doing, and can maintain a consensus about what should be done. Certain responsibilities in the project can be assigned to people, the website will document them. Communication is essential for project integrity.

However, we should arrange ourselves into small teams, each taking care of a single (or a few) component(s). See P. Brooks' book The Mythical Man-month for ideas. Each team should have a 'leader' who is responsible for organizing the team's development activity, and coordinating it with the rest of the project.

Starting points

All the time, we should spend time looking at our starting point canditates (libraries/code bases). Try some hacks/ experiments/ demos with them, learn them, see if we can get our 3d models into them... Practice materials will be placed in cvs. Eventually we will choose one to serve as a basis for our project.

Class design

Step by step we take the design to more concrete levels... and return back to higher levels if need be. Once we have thought out the modules of our application, we can start designing the classes that implement them. Some UML tool might be helpful here, and we should create documentation at this point, too. (Here I assume we are using C++, which I would prefer, but which of course has not been decided.)

Art and design

At this point we should think a bit about the specific gameworld as well - what should the game look like? We should know which vehicles we are trying to create first, and have a general idea what they look like and what their capabilities are.

This is also a good task for the people interested in general game design. We need to think up an intriguing theme, ie. will it be high tech manga or some dark cyber tech setting. Once we have something to go on, the artists can get to work and make concept art, 3d models, etc.

Prototype and beyond

Once we have a clear understanding and agreement of what exactly we are about to do, we can proceed to the actual coding stages.

Once the prototype is complete, it will be evaluated and discussed by the project members. And there will be a good many hackish experiments :) Our findings will be taken into account when designing and implementing the software for real.

-Varis

Addition 31st July 2000

This is my sketch for the timetable, rest assured that it will change:

Release 1

First production (stable) release, version 1.0.0. It will be very limited in features, to avoid overconfidence and second system effect. But basically it will be just what Geome is supposed to be: extensible game framework.

Features:

• Persistent battlefield
• Teams
• Bases
• Different units and weapons
• AI units
• Module system
• Modest playability

Release 2

Usable system, nice features added. Geome should be a viable game development platform at this point. To demonstrate this, we will be making a game of our own.

Features:

• Trigger system, mission types
• Resource management, production
• Teams (clans?) with more features, roles
• AI with a little intelligence, scriptable
• Trees
• Music
• Fog of war
• OK playability
• Editor tools

Release 3

Full release. Ready for serious real use. By this time Geome should be as big as can be realistically expected of us to manage.

Features:

• Campaign
• Single player capacity
• Server, map and scenario system
• Base system with features
• Good playability
• Fully featured module system
• Organized mods&maps&extras distribution

-Varis

Addition 27th January 2001

Okay, the prototype is not yet complete, so the schedule will shift. But we are working on it. See the mailing list or contact us for details.

-Varis