Re: [Freeciv-Dev] Serious Suggestions

[David J Porter <porterd@xxxxxxxxxxxxxxx>]

> On Wed, 24 Feb 1999, Matt Busigin <jediknight@xxxxxxxxx> wrote:
>
> #On Wed, 24 Feb 1999, Tony Stuckey wrote:
> #
> #For small values of widely. A domain-specific language can be made very
> #easy to learn, yet powerful.  Most general programming languages are not
> #easy to learn, regardless of power. TacOps doesn't even have a language --
> #just a bunch of checkboxes in a dialog box, but it's got very useful
> #scripting.
> #
> #Scope is important.  I don't think that writing an entire AI in the
> #scripting language itself is necessarily useful.
> 
> Exactly.  The AI, and the like, are probably the most CPU intensive part. 
> The last thing you want is for it to be interperted!

I agree that the AI code needs to be compiled rather than interpreted
via a scripting language.  Client helper applications could possibly be
effieiently executed from scripts.

There is, IMHO, an argument for allowing some sort of dynamically
loadable object modules for this.  This has the advantage of being able
to continue writing 'C' rather than some other language, with the
advantage that compilation allows.

Oh, and if we (I??) implement dynamically loadable object modules it
would be sensible to allow them in both the client and server.  This
would alleviate some of the problems with hardwired code for major
wonder effects, etc., since they wouldn't need to be physically loaded
if the wonder wasn't being used.

A problem I can see with this straight away is the nightmare of figuring
out the LCM of the server vs multiple clients, not to mention that it
would be good to at least have a handwave attempt at backwards
compatibility.

An advantage may be that it could be a mechanism for putting some real
power behind the Rulesets by allowing wholesale wonder modifications
backed by the code to implement them; new units with non-standard
ablities; or new city improvements, etc.

Points that will need further invesitgation:

o Client/server module synchronisation :-

        For modules that need synchronisation would benefit greatly from being
        generated from a single source file and activated by compile-time
        defines (i.e. -DMODULE -DCLIENT or -DMODULE -DSERVER).  Also, some
        method of producing monolithic versions may be useful for systems that
        can't or don't implement dynamic loading (i.e. by not defining
        -DMODULE).

o Code reorganisation :-

        There'd be a lot of code that would be effected by this change, which
        at this point would seem to make the change to dynamic loadable
        modules at the present time to be impracticable.  In fact, I can't see
        any part of the code that won't be impacted.

-- 
And as we stand on the edge of darkness
Let our chant fill the void
That others may know

        In the land of the night
        The ship of the sun
        Is drawn by
        The grateful dead.
                -- Tibetan "Book of the Dead," ca. 4000 BC.