[Freeciv-Dev] Re: unit flags/capabilities

[Andrew Sutton <ansutton@xxxxxxx>]

On Thursday 29 November 2001 11:25 am, Reinier Post wrote:
> On Thu, Nov 29, 2001 at 08:51:25AM -0500, Andrew Sutton wrote:
> > > Why? The server core only uses enum unit_flag_id. And this is good
> > > IMHO. The server AI needs extra infos about how to use certain unit
> > > types: enum unit_role_id was added.
>
> Which doesn't belong in 'unit', for it is unknown at the client side.

ahh... the joys of lack of documentation :)

> > > So what are your problems with this? Running out of flags? We can fix
> > > this in a transparent way (no changes of the format of the rulesets,
> > > no changes of the code, just the network code, unit_flag and ruleset
> > > reading). It may necessary to have other infos about the units (for
> > > example if you program an AI). But I don't see that you are doing
> > > this.
>
> (This would really make it more extensivble.)

how? data extensibility isn't an issue to be solved in a network protocol. it 
can be an aspect of a network protocol related to the capabilities of the 
application, but shouldn't be a solution to the actual extension of types and 
capabilities within the application. i think that's just common sense.

> > 1. it's a clumsy implementation.
> > 2. it isn't very extensible
>
> I don't think your idea makes it any more extensible in practice.

you're probably right. it's just as *easy* to keep adding new enums and 
fields. this patch will just make the extensibility centralized and make the 
extension *maintainable*.

>
> > 3. it groups widely different types of data together into one bitfield.
> > 4. it separates out data that should be there.
> > 5. adding a new implementation won't change the old code or the rulesets
>
> All nice if you want it in the first place ...

you don't want that?

> > this is a more graceful way to introduce capabilities to units than to
> > continually define and insert enumerations and bitfields into a
> > structure. there's been alot of talk about coding style? that's bad.
>
> Yes, definitely, but it's a consequence of C's typing system.

no. this is a consequence of adding new features without a real gameplan of 
how to maintain the addition of features. this is *not* an implementation 
issue. it's a design issue. the simple fact is, the original code base was 
buit to not be extensible except via patches. lots and lots of patches.

i have to rant now. the whole problem comes from the fact that the framework 
and features have been implemented without a real design. you have some 
extremely vague requirements for features, but don't bother to mention any 
requirements for the framework itself. i've never seen anything that says, 
freeciv shall support an unlimited number of nations. maybe if it had been 
written down, you wouldn't be having to fix the nation limit bug now.

and you can't defend this point. nobody can. the only documentation is a 
half-assed attempt to document the code (/* ... */ is terrific!) with 
absolutely no architecture defined except a sentence or two that describes 
the client/server model. oh. and don't point me at the mailing list for 
architectural decisions. a developer shouldn't have to and shouldn't expect 
to filter thru past conversations to find the current architecture of an 
application.

but don't worry, this isn't an issue solely rooted in freeciv. the gaming 
industry in general takes this stance. everybody seems so focused on an 
immediate end result, that nobody wants to take the time to go thru the steps 
to make the *software* good. and i'm not talking about a complete software 
process here. just enough of one to force developers to take the requirements 
of the game in account when they start designing.

i think its assinine that maintainers (and developers) would argue against 
patch that redesigns and reimplements a core subsystem of the game because 
they don't see an immediate need. i've seen all this talk about feature 
enhancements and nitpicking algorithms, but i haven't seen ANY talk about the 
actual game architecture (besides what i started with this thread). it's 
obvious to me and propably alot of developers that the core implementation is 
inadequate to support the flexibility that the features demand. i mean 
really, what's so scary about changing a core mechanic if it doesn't break 
existing code and provides a framework that's easier to maintain and 
implement new features - even if it does result in more code. it's a 
tradeoff. extensibility for efficiency. what's more important? some might say 
efficiency, and i agree for something that didn't need to be modular.

if anybody is REALLY interested in improving freeciv, take a look at what 
needs to be improved - the ability to add features, the ability to 
generically deal with new features. the rest will fall into place.

andy