[Freeciv-Dev] Re: unit flags/capabilities

[Reinier Post <rp@xxxxxxxxxx>]

Note, I'm commenting without having done much to the code.

On Thu, Nov 29, 2001 at 12:21:31PM -0500, Andrew Sutton wrote:
> On Thursday 29 November 2001 11:25 am, Reinier Post wrote:

(I don't understand your comment on the network protocol.)

[...]

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

I don't see this.  A list of enums and fields is easier to maintain: less
code and concepts to be aware of.  There isn't much to be subtyped anyway,
the flags (unit capabilities) system seems an adequate description.

Am I wrong?

> > > 3. it groups widely different types of data together into one bitfield.


This is what the flags do, too.

> > > 4. it separates out data that should be there.

OK.

> > > 5. adding a new implementation won't change the old code or the rulesets

Same with the flags.

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

Mechanisms to improve extensibility have been added.
For example, the unit capability (flag) system.

> i have to rant now. the whole problem comes from the fact that the framework 
> and features have been implemented without a real design.

This is not correct.  However the demands have grown as goals were met,
requiring redesign along the way.

Perhaps you can point out some flaws in the existing design.
So far you have given one example (unit types should be separate
structs) which I don't find convincing.  But I haven't done much coding.

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

Who is 'you'?  The three people who spend time revising patches
this month?  Who would have the authority to write these requirements
down?  Even well-argued ideas with working implementations don't always
make it into CVS, because they don't get enough feedback.  Perhaps opening
CVS write access would improve this.

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

The lack of design documents is one of the Freeciv FAQs.
I'm sure an offer to do this will be much appreciated.

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

This is not the problem with Freeciv.

> that nobody wants to take the time to go thru the steps 
> to make the *software* good.

Freeciv has always ensured this by restricting commits in CVS tree
to 'moderated' patches.

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

Is this an actual problem with the patches posted here?
 
> 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.

Freeciv is a complex product that works quite well.
If the code breaks it might not stand up.

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

Is there any need to discuss it?  Most patches don't touch the architecture.
Raimar's CMA patches really break the design, in my opinion, and there was
some discussion then, but apart from that I can't think of anything.

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

What's scary is the 'if'.

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

Efficiency is important.  I used to host Freeciv games over a 28k8 modem
line.  Freeciv has many users who play on that sort of connection.

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

What is not obvious to me that your proposal would bring improvement.

> andy

-- 
Reinier Post