Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2002:
[Freeciv-Dev] Re: Generator script
Home

[Freeciv-Dev] Re: Generator script

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Billy Naylor <banjo@xxxxxxxxxx>
Cc: Peter Hans van den Muijzenberg <blue-peter@xxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Generator script
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Thu, 5 Sep 2002 19:34:07 +0200

On Thu, Aug 29, 2002 at 09:30:51PM +1200, Billy Naylor wrote:
> On Thu, 29 Aug 2002 06:03, Raimar Falke wrote:
> > On Wed, Aug 28, 2002 at 07:27:00PM +0200, Peter Hans van den Muijzenberg 
> wrote:
> > > Hi,
> > >
> > > I'm really here to see if the networking code can be split off from the
> > > game code, so it can be reused for other net games. But now that I'm
> > > here:
> > >
> > > Is there still a need for a script that generates packet send and receive
> > > functions? there are some issues, but in itself this seems doable.
> >
> > I'm also toying with this idea. It is possible but there is currently
> > no strong need for this.
> 
> I sounds like something that may be useful for people who'd like to build
> clientside stuff, like a client AI in perl for example.

There are bigger problems. Much bigger problems:

  Suppose you want to implement something like CMA in perl. For this
  you have to have a way to "recalculate" a city
  (common/city:generic_city_refresh and all depending functions) at
  the client. 

  So this means either you recode all the city calculation
  in perl (city calculation uses a lot of information (other cities
  for trade routes, player for the government and the tax rates and so
  on)). So you would end up implementing a lot of common/* in
  perl. And you have to "port" new stuff like the upcoming generalized
  improvement code to perl.

  Or you build an interface to the C-"core" which contains
  common/city:generic_city_refresh and Co. And then build a
  perl-interface using SWIG or doing it by hand. If you do this you
  can easily also generate interfaces to the send_* and receive_*
  functions.

So the packet sending and receiving function are IMHO your smallest problem.

I have done this considerations in the past and came to the conclusion
that the first way is A LOT of work. In the second way you want a
small interface. For example you have no interest in the
receive_packet_ruleset_government function. You don't want to call
this from perl. You want to access the received data. So you want to
access the layout of struct government and the flags and enums of
common/common/government.h. And you want access to
get_government(). So you end up with a stripped-down client which
would consists of 
 - the network part, 
 - the caching part (cities, unit,...) and 
 - code to do exact calculation (the same way the server would do it).

You only need an perl-interface to the last two parts.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "When C++ is your hammer, everything looks like a thumb."
    -- Steven M. Haflich


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