Re: [glob2-devel] Thats it, we need a plan

[Martin Voelkle]

> This is it. I'm starting to get bored. I have nothing to do at nights.
> I think *we* need a plan, a real plan, a project plan, a roadmap, and
> all that other bullshit everyone seems to be avoiding.
>
> I think its about time we sum up everything we want done before 1.0.
> Everything. On this thread. And don't just toss this away like I know
> a bunch of lazy people on the project will. *Everything*. Be specific.
> Don't say "Fix map editor". That doesn't help. If we knew what needed
> fixing, it would probably be already done, or atleast in progress. We
> need to know whats wrong, and what should be done about it. List
> anything and everything for 1.0. The important part of this list is
> that we know when we have achieved everything, rather than being in a
> state of semi confusion with nct suggesting things none of us know how
> to do every so often.
>
> That being said, I'll start off the system with the following:
>     - Buildings should be able to be priorotized. Priorities should be
> fully enforced, if a building being constructed is given a higher
> priority, units won't go to Inns and work their regardless, the
> building has a higher priority, and the units *must* go there if
> possible. For several buildings in the same priority level, normal
> prioritizing rules apply. There should be three priority levels, low,
> medium, and high. New buildings start with medium priority. Priority
> should be adjustable from the side menu, a likely placement is right
> underneath the "number of workers" bar. Flags should also have
> priorities. All buildings should have seperate priorities. The
> difference should be noticable.
>
>     - Multiple selection of buildings. This is an important one.
> Multiple buildings should be selectable. You should be able to do it
> two ways. The first is if you hold shift and click on multiple
> buildings, they are selected. The second way is if you hold the mosue
> button down when there isn't anything under the mouse pointer, you
> should be able to drag a box to a new location. All buildings that
> have all four corners within the box should get selected. When
> multiple selection is active, the right hand menu changes slightly. It
> should say how many buildings are selected. If there are buildings of
> different times, common options should be shown, (yes, this means
> labelling building option groups for the gui and doing it in an
> abstract fashion). As for the values of the options, if the buildings
> are all different, no value should be shown. However, if the values
> are all the same for a prticular option, that value should be shown.
> When changing an option, all selected buildings are affected.
>
> I hope you all of something to contribute, so we know what needs to be
> done. Long paragraphs like this are what I'm after. All of these
> things can be discussed, but its important to come to a concensus
> quickly, so we know what to do, rather than ponder on what the game
> should feel like. Not knowing exactly what is to be implemented is a
> key thing that slows me down, I don't know how other developers feel.
> But serioussly all, if we want to advance this project, we need to
> decide where to go, as a group, or else we might as well be going in
> circles.

>        PS: I'm not trying to be mellow-dramatic

If you do it without trying, try to avoid doing it.
Maybe you should ask yourself this question: what does 1.0 mean for you?

IMHO, it's about getting the quality of the game to a point where we
can say it's stable.
That implies pretty much bug squashing and reworking the map editor. I
know these are completely fuzzy goals, but face it: the map editor is
unusable. It's not about fixing it like this or like that, it's about
RE-doing its UI.

You seem to have good ideas, but from my POV, they don't seem to bring
us any closer to a 1.0 release. That shouldn't stop you, there is no
harm in doing new stuff. Branch, and merge when it's done. But I
really think that wishlist items should be out of a 1.0 roadmap.

This is what sucks with CVS: branching is not as easy as it could be.
You can't keep track of changes in HEAD when you are working on a
branch. However, merging code is usually not as complicated as people
think it is.

Kieran posted a very comprehensive roadmap:
> * Finish all open projects (random map maker (donkyhotay, gizmo), Nicowar 
> (GeniXPro), > editing units in map editor (nct, needs more options like 
> strength for say powerful globs, > or health if the campaign requires say and 
> injured King)
> * No one may make CVS commits that contain new features
> * Thourohly test globulation and report all bugs (and gdb output) at the bug 
> tracker
> * Find and eliminate desync bug
> * Fix all (or most) bugs at bug tracker, hopefully clear it complelty (close 
> old ones even if > they havn't been fixed, and if they still happen, they 
> will be revived)
> * Release 1.0

This boils down to:
* don't add new stuff to HEAD
* finish HEAD stuff
* squash bugs
* release

It's unfortunate that open projects must be finished before releasing.
This is due to the fact that they have been done on the HEAD branch.
Had we avoided that, we would not be in that position today. I think
it would be worth to change the source control system (that might
imply ditching savannah), so people can work on their enhancements
without holding back the HEAD branch.

Martin