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

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 10:40 AM 01/12/11 +0100, Reinier Post wrote:
>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:

>> 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.

Good ... it is a big step to move from the undesirable or impossible
to one that is just under resourced :-)

The latter I suspect can be fixed easier than you might first think.
 
>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?

I actually really like the staged concept. So, yes you are right on
the money here.

The corecleanups and some other cleanups being done are significant 
rewrites along these lines without too much code change, just 
rearrangement and a few trowels of filler on occasion. 

This really is the way to do a bottom up fix. Clean, isolate via 
interfaces that you propagate through the code, then do a final rewrite
of an encapsulated submodule *if* it needs it.

As to the next stage of how ...

I'm less fond of trying to put labels or rigid rules on how to do this
up front. Doing some things, then working out the emerging interfaces
and setting some bounds at this stage before propagation is a little
more likely to keep things moving. Once the whole effort well underway
to completion, then a second look at a more rigorous master plan to
bring the best of all the pieces into a final consistent framework 
might make strong sense, or there might be a framework coming down from 
the other direction that cleaned up modular components could be folded 
into.

Moving things to given files, in one of a number of generally acceptable
formats which I can read into your comments is very good. Carrying this 
to the extreme too early in the process from misplaced enthusiasm is the 
first derivative problem to be careful of, i.e. the very bad side :-).

>> 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.

Same thing can be said for the current FC packet handler, right?

That is the ultimate interpreter for all the client AI civbot code :-).
 
>> 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.

So you are saying you don't want civserver installations to have 
uncontrolled access to the underlying OS or filesystem. This problem
has been solved. There are numerous implementations available as 
example to base an FC solution on.

>-- 
>Reinier