Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2004:
[Freeciv-Dev] Re: (PR#2521) general effects framework
Home

[Freeciv-Dev] Re: (PR#2521) general effects framework

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kaufman@xxxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2521) general effects framework
From: "Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>
Date: Wed, 21 Apr 2004 08:33:52 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=2521 >

On Tue, 20 Apr 2004, Mike Kaufman wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=2521 >

> when jason and I last had this conversation I was sure this was a
> bad/unworkable idea. I can't seem to remember exactly why I felt so. Ah, I
> do seem to remember some problems... One problem here is that most of the
> effects cannot fit comfortably into a bitvector type solution. For example:
> how would you store in a savegame: global effect Spy Resistant +20% has
> survived AND global effect Spy Resistant +50% has also survived? You can't.
> A bit vector can only store whether some Spy Resistant effect is on or off.
> It can't describe any of the other 12 parameters making up the effect.

Actually, you can:
EFFECT_SPY_RESISTANT_PLUS_20
EFFECT_SPY_RESISTANT_PLUS_50

So it is possible. It is just less extensible from a ruleset perspective,
i.e. if you want to add new effects, say Spy Resistant +33%, you need to
change the C code. The advantage it that the code would likely be faster
because you would be doing direct array indexing rather than list
searching like is done in both your and Ben's patches.

I give one additional proof that it is possible to implement all existing
effects this way: currently the effects are done by checking the improvement
array per city and the global wonders array in the game structure. The
checks consist of on/off checks for buildings. So converting to on/off
checks for effects bitvectors in a city and in a game is possible.


You could even generalize the concept in the future if you wanted to, by
adding an effect definition block in the rulesets, thus:

[effects]
EFFECT_SPY_RESISTANT_PLUS_20 = { "Spy_Resistant", "20" };
EFFECT_SPY_RESISTANT_PLUS_50 = { "Spy_Resistant", "50" };

Then you could do an initial pre-processing step to find per-effect
categories, bin them, etc. Also make a code generator to create
C code for these effects automatically. Like it is being done for packets
now.

I am not saying this is how we should do it, just that it is possible.

> That's not to say that only Enable_Nuke and Enable_Space do not have this
> problem. Any_Government, Have_Embassies, No_Anarchy, No_Sink_Deep, and a
> couple of other effects whose parameters are totally ignored can be used
> this way. Using such a bitvector though means that savegames might be
> corrupted if the order of enum effect_type_id changes. Better would be to
> save a list of the effects names that survive in the savegame and using
> effect_type_from_str() to look up the effect. Hmm. I don't know if there's
> much point. comments?

The problem is that adding struct fields is not easily extensible. If I
want to add a new field I need to add those fields, init them somewhere,
change the ruleset and game load/save routines, etc. While if this
was done in a bitvector, or some other array, list or set structure easy
to extend, there would be no such problem.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa




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