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

[Petr Baudis <pasky@xxxxxxxxxxx>]

> actually it is bad. you're automatically assuming that those pointers will be 
> non-null, and at some point they won't be. it's not safe programming. it's a 
> poor equivilancy.
i didn't write any actuall programming example for it. obviously you need to
test it.

> oh... don't forget, your tile is now 160 bytes. assuming a map of only 32 by 
> 32, that comes to a total of... 160 KB. and that's for a small map. using 
> c++, you'd lose all the function pointers (reduce to 64 bytes).
uh, who says each tile will have own copy of structure with handlers?

> besides, you're missing something else too. maps are sparsely populated. to
> assign a unit stack to every tile is just a waste. a more appropriate (and
> equivilantly fast) implementation would be to store the unit stacks elsewhere
> and map them by the coordinates. i know it's not quite as elegant (or easy),
> but it's better on the footprint.
4 byte waste. we are not in 70s. that is for 80*40 totally empty map 12kb
waste. not so fatal imho. anyway this was actually only *example* ;p.

> make the association of a unit stack external to the tile and you come up 
> with a 32 byte tile.
> 
> the seat would probably follow the same rules as the unit stack. remove this, 
> and your tile is empty. of course, it will contain a terrain indicator, but 
> you didn't write that so i'm not adding it.
that was under that private data. in fact i would separate handlers list and
make only pointer to it so one can reuse it per terrain type. anyway i'm not
proposing this now by any rate, altough it wouldn't be bad i see no actual
need/benefit from it, and i'm not going to implement it as i have enough items
in my todo list for now :-).

> > 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.
> 
> the current proposal isn't to put units into different modules... just 
> capabilties. the unit is still a single class. the unit _will_ have to know 
> how to cope with capabilities, but again, it has to in freeciv1. add a new 
> capability, the ai has to learn it.
how?

> > everything? that is? iirc you mentioned only move rate.
> 
> did you want a complete description of every capability i can think of? 
> that'd be a long email. besides, i'm actually working on this description 
> off-line.
great, looking forward at it.

> > now define what exactly will be kernel and what it will provide and what's
> > so cool with microkernel pattern when used for freeciv.
> 
> what the kernel is is a tough question, as i only know as i think about 
> things. to start with it is the game manager. the kernel understands how to 
> load modules to get data. it understands how to create a game based on a 
> ruleset (combine module data into understandable game form). it understands 
> the basic protocol of the game, and is capable of enacting it. it maintains 
> the world map, all the units, all the cities and all the players. it provides 
> a player api for human and computer players and it provides an admin api 
> allowing the game to be administrated or changed on the fly. it also has an 
> extension requiring players be clients of the game server.
>
> the microkernel pattern is what it is. a commonly recurring architectural 
> pattern that is used to separate specific functionality or data from a core 
> that could really care less about specifics.
ok, that's nice goal to achieve, but see bellow.

> > /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?
> 
> since we've only talked about unit capabilities, that's all i have to go on
> so far. a core module that provides the most common, basic unit capabilities
> (move, sentry, fortify, pillage). a civ module that provides civ extensions
> to the capability list. possibly a masters of magic module that provides MOM
> capabs. possibly an alpha centauri module that provides AC capabs. questions?
this would be nice. still i think doing this in C w/o major rewrite is
possible.  if you don't think so, go ahead, fork another project doing that and
see how successful you will be, it's quite possible you will beat us and we
will join you later. however i don't see any core developers amazingly raising
their head and concentring around you with happy crying, so i think you won't
success with converting this project to c++. obviously i can be quite wrong
here too.

-- 

                                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/