Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability a
Home

[Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability a

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Daniel L Speyer <dspeyer@xxxxxxxxxxx>, Jules Bean <jules@xxxxxxxxxxxxxxx>
Cc: gregor@xxxxxxxxxxxxx, freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability and Development]
From: Andrew Sutton <ansutton@xxxxxxx>
Date: Thu, 6 Dec 2001 11:34:23 -0500

> Do you really think we can anticipate more than a very small fraction of
> the ideas potential-ruleset-makers may come up with?
>
> Building rulesets *should* be fairly easy -- and we should have a lot of
> people doing it -- but it's boring if all you can do is recombine a short
> list of features.  Now, we could write a longer list, but this means only
> those with the skills and familiarity to write in the freeciv core will be
> able to create interesting rulesets.  This is a major developement-model
> error for a game with so many somewhat technical fans.
>
> Furthermore, if new unit powers are written in C, then they can't be used
> multi-player until everybody (roughly including
> civserver.freeciv.org) upgrades.  This is a gross violation of
> "release early, release often".

excellent point... there seems to be a fundamental divide on the actual 
direction of the game. there's one camp that believes that features should 
only be added by core developers, restricting the feature set to those that 
have been approved and tested. the other camp believes that customizability 
is the goal to success (if not necessarily performance :)

who gets to decide the eventual direction of the game. IMO there seems to be 
considerable short-sightedness on the part of the maintainers. current 
development is reactive to the needs of users and developers. this doesn't 
help the release early, release often part at all. for example, i need a new 
feature. if i can figure out how, i can write it. if it turns out that i need 
to add a bunch of stuff and start messing with the structure of core 
subsystem, it's going to turn me off from writing it. THEN, i have to submit 
a patch and hope it gets included.

the alternative would be to develop in anticipation of the needs of 
users/developers. anticipating eventual features would lead to a more 
flexible framework.

it seems that the main conflict comes from vision: near future to eventual 
future. so what's the answer. who decides the future of freeciv?

andy


[Prev in Thread] Current Thread [Next in Thread]