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: Petr Baudis <pasky@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
From: Andrew Sutton <ansutton@xxxxxxx>
Date: Sun, 2 Dec 2001 11:18:04 -0500

On Sunday 02 December 2001 04:51 am, you wrote:
> > essentially, what's going to make freeciv2 fundamentally different than
> > freeciv1 is a) the programming language (c++)
>
> I will stay happily with FreeCiv1 then.

okay.

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

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

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

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


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