Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
Home

[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Sutton <ansutton@xxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
From: Petr Baudis <pasky@xxxxxxxxxxx>
Date: Sun, 2 Dec 2001 18:06:56 +0100

about objects in c...

say we have map and each tile is object with information about terrain and
special, possibly containing seat (object) and possibly containing units
(objects).

struct tile *map[MAX_MAP_X][MAX_MAP_Y];

struct TILE {
  /* possible private declarations */
  ...
  /* following assigned accordingly to terrain and special */
  /* this may be even in separate struct */
  int (*get_terrain)(struct TILE *);
  int (*get_special)(struct TILE *);
  int (*get_defense_bonus)(struct TILE *);
  ...
  struct seat *seat;
  struct unit_stack *units;
} tile;

struct SEAT {
  /* following assigned accordingly whether it's city, hut, or something else */
  int (*get_population)(struct TILE *);
  int (*entering_unit)(struct TILE *, struct unit *);
  ...
} seat;

it is not so bad, in fact it could be done even better than i did here, and
you have no c++ bloat ;p.

> > Have fun with implementing separate bit of AI control for each those
> > capability. Especially when we want to move AI to special client. Hmm?
> 
> what's the difference between implementing the ai as a client of a monolithic 
> application vs. a client of a microkernel application. there really isn't. 
> things change in freeciv1 and things will change in freeciv2. unless the AI 
> is *extremely* well written, there's going to have to be changes to integrate 
> the new features.
you got me wrong. when you will put each type of unit into separate module, that
means you will also in that module teach AI how to cope with that type of unit,
if you are so modular, won't you? otherwise AI will panic and cry and you will
be out of luck.

> > We have those capabilities already, haven't we?
> 
> no. in freeciv1 movement is an intrinsic capability of the unit. the 
> alternative generalizes everything about units. there's a subtle dfference.
everything? that is? iirc you mentioned only move rate.

> > Raimar writes...
> > Why? Why do you want dynamic loading of modules? You have the source
> > and can recompile. In general I think that the flexibility you want to
> > achieve isn't needed. If a new property (a flag now) is introduced
> > (you may use the unit as external resource collector for example) you
> > need to write a new module. Changes of about the same size has to be
> > incorporated in the current implementation to achieve this. I don't
> > see why your scheme is better.
> 
> > Petr writes..
> > Why dynamical modules?
> 
> dynamic modules? why not? it's a forceful separation of kernel and module. 
> besides, it really goes along way to forcing the kernel have certain 
> properties - like a well defined interface. it also helps ensure the 
> decoupling of the modules from the kernel (so you don't have specific game 
> aspects tromping through the core mechanics to accomplish their goal). it's 
> commonly accepted graceful implementation of the microkernel pattern. 
> besides, there's nothing to say that source written for a module can't be 
> hard linked to the kernel.
now define what exactly will be kernel and what it will provide and what's
so cool with microkernel pattern when used for freeciv.

> > Why it would?
> 
> why would it what? be an appropriate behavior? look around! honestly, how 
> many really monolithic applications do you see? everything evolves to a 
> modular system at some point.
/me counts...
...
/me stops counting bored.

yes, i like modularization too, i'm using to write usually highly modularized
software, however i soon learned that everything, even modularization, has
its limits, and i think having separate module for each unit is above that
limit. so please can you be concrete, which modules do you expect to see?

-- 

                                Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC, FreeCiv hacking
.
  "A common mistake that people make, when trying to design
   something completely foolproof is to underestimate the
   ingenuity of complete fools."
     -- Douglas Adams in Mostly Harmless
.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/


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