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

[Reinier Post <rp@xxxxxxxxxx>]

On Mon, Dec 10, 2001 at 06:41:30PM -0500, Ross W. Wetmore wrote:
> At 09:21 PM 01/12/08 +0100, Reinier Post wrote:
> >On Thu, Dec 06, 2001 at 11:34:23AM -0500, Andrew Sutton wrote:
> >In the 3 years I've been following Freeciv it has become much more
> >customizable, although nothing takes it beyond a multiplayer Civ I and II.
> >Little of this customizability is actually being used.  The game has also
> >become more portable, but the user base seems more or less stable.
> 
> Customizable in a very restricted way. The real problem is that none of
> the customizations really replace the lack of basic features that are
> still missing.

Yes.
 
> >> the alternative would be to develop in anticipation of the needs of 
> >> users/developers. anticipating eventual features would lead to a more 
> >> flexible framework.
> >
> >Definitely, but is it worth the trouble?  I've never seen more than 30
> >players at once on civserver.freeciv.org and they *never* ask to play
> >with an alternative ruleset.  If the existing range of options in rulesets
> >isn't being used, is it worthwhile to make the game more extensible?
> 
> That is like saying there is no need for any options in Danish supermarket 
> products based on a market survey of only New Guinea tribesman.

Amazon customers, I would say.
 
> Besides the whole ClientAI thrust is to allow extensions for just such
> reasons. 
> 
> So the question is does one do another primitive oneoff hack or think 
> about what one might need to do to build this into the game system in 
> a general way that could be used by everybody from FreecivAC types or 
> other game/rules variant developers to the Civbot challengers.

Well, I just wanted to make the point that you may not get very many
developers or users on such a project, although it's technically the
way to go.
 
> And just to stem the refrain about the scariness of dealing with code
> not sanctionned by the maintainers, you should be aware that there are
> somewhat more advanced concepts of how to do this than you seem to 
> imagine. Rest assured that because you can think of a bad way to add
> code does not mean that this is likely to be the final design choice 
> so it is at least reasonable to talk about it :-).

An alternative to starting from the ground up is to make the code
C++-like in stages.  The first thing is encapsulation.  Make it a rule
for every piece of data to be an object attribute, and for every piece of
code that touches it to be in a class method for that class of object.
E.g. for unit types, all the data structures would be in unittype.c and
unittype.h would export only functions; it would be an error for anything
else to touch the data directly.

Is this a good first step?

> As a for instance, interpreters are usually considered quite safe in
> that the code they interpret is basically constrained by the operations
> or language the interpreter understands.

Yes, that's the problem with using a general purpose scripting language
like Perl.
 
> It is also the case that we are a long way from the DOS days when the
> entire operating system or program was open to any code that wanted to
> poke around in its innards.

I'm still thinking about automatic, unattended civserver installations.
True, if you control the OS it's easy to set up a system that can't
really be destroyed, only sabotaged.

-- 
Reinier