Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2004:
[Freeciv-Dev] Re: (PR#725) Order of end/new-turn activities
Home

[Freeciv-Dev] Re: (PR#725) Order of end/new-turn activities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ChrisK@xxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#725) Order of end/new-turn activities
From: "ue80@xxxxxxxxxxxxxxxxxxxxx" <ue80@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 11 May 2004 02:42:53 -0700
Reply-to: rt@xxxxxxxxxxx

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

On Tue, May 11, 2004 at 12:57:18AM -0700, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=725 >
> 
> Raimar Falke wrote:
> 
> >>just make them more consistant.  The above may be one example
> >>because we might want to update tech _before_ production (or maybe
> >>not...).
> > 
> > Can we define what properties we want from the sequence? Should it:
> >  - fair
> >  - give an advantage immediately
> >  - give a disadvantage immediately
> > ? Which parts should always be predictable and which can have a more
> > complex calculation?
> 
> - Fair (shuffled_players_iterate instead of players_iterate).  There 
> should be no consistent bias.
> - Consistent (don't mix production and research).
> - The effects should be random only when we want them to be.  Mostly 
> this randomness should come from shuffled players, I think.

We should use shuffled players only when we need it. And every case
where we can use players_iterate instead of shuffled_players_iterate is
good.
 
> The ordering in the previous example makes a difference in gameplay but 
> this is not a technical issue.  So we should take Pille (or the design 
> board's) advice on this.  There are many similar dependencies that could 
> go either way: possibly too many even to find.  And sometimes there may 
> be multiple dependencies between two atomic "activities".  The odds of 
> this increase when we make the atomic groups larger.
> 
> For instance if we have two atomic activites:
> 
>    - Restore units
>    - Do city shields & production
> 
> Restoring units may kill some of them (helicoptors, etc), changing the 
> amount of shield surplus the city gets.  However building buildings may 
> affect the restoration of units (barracks).  A player with a helicoptor 
> building the united nations might end up losing the helicoptor if marco 
> polo's is built first, but the loss of the helicoptor gives one extra 
> shield allowing the completion of another helicoptor in another city.
> 
> These dependencies are complicated, but most of them don't matter all 
> that much.

Your example is easy to solve. The upkeep of the unit has to be paid the
whole round. So it is ok to pay the shields for helicopters, fighters
... which die at the end of the round.

But a good player would be able to see which units would die and disband
them before the end of turn phase. So we can say the upkeep has to be
payed after the phase of unitrefresh. 

Now it is the question if the upkeep has to be payed after or before a
new unit is build. 

Should new units cost upkeep for the round they are build?
To keep it simple i would say no. 

With that decision we pay the upkeep before the phase where new units
are build. 

So the order of these actions is:
 - disband units which are dead (not enough fuel ...)
 - pay upkeep of the units and destroy the units without enough upkeep
 - build new units

But that wasn't all ...
What is with the action of workers and units (building improvements
(airports! ... pillaging)

I don't want to continue this now.
 
> However sometimes the ordering does make a technical difference. 
> Production should be upgraded before units and buildings are completed.
 
In all cases with dependencies it is a difference which action is before
or after.

So i think we have to go a step back. Name all action, categorice them,
search dependencies and after that decide how to solve the dependencies.

Thomas
-- 
Thomas Strub  ***  eMail ue80@xxxxxxxxxxxxxxxxxxxxx
jb: people are stupid, they don't want to learn.




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