Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#7195) inlining map_pos_to_index
Home

[Freeciv-Dev] Re: (PR#7195) inlining map_pos_to_index

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jshort@xxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7195) inlining map_pos_to_index
From: "ue80@xxxxxxxxxxxxxxxxxxxxx" <ue80@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 6 Jan 2004 02:59:21 -0800
Reply-to: rt@xxxxxxxxxxx

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

On Mon, Jan 05, 2004 at 11:42:59PM -0800, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >
> 
> Raimar Falke wrote:
> > Freeciv has no hardware requirements
> > like commercial games have. This leads to a "lets make it as fast as
> > we can since there may be slow hardware out there". But even with a
> > fast hardware (1GHz+ CPU) you can watch it crawl when you do an
> > autogame (set timeout to -1 and use only AI players).
> 
> The autogame is so easy to measure that it has become a benchmark for 
> measuring "speed".  But as I've said before I believe this is highly 
> flawed.  The vast majority of a normal player's wasted time is spent 
> watching units animate (i.e., the "stepped movement").
> 
> Try:
> 
> - Timing an autogame.
> - Timing the same autogame with a client observer attached.
> - Timing the same autogame with a client observer attached and animation 
> off.
> 
> The second game probably won't complete because the client is too slow 
> for the server and will be cut.

The benchmark could be the year when the client is cut *g*

> Increasing the between-turn speed for players is a MAJOR boon.  Half the 
> people I know didn't like civ3 because all you do is watch workers move 
> around.  The same is true in freeciv.

I think the same, when watching autogames i don't need to see all moved
units.

> Some methods have been proposed to improve this.  However most of these 
> have drawbacks.  The player needs to get this information, after all, 
> and people can only understand incoming data so fast.
> 
> - Make auto-settlers take more efficient paths.  This would certainly 
> improve the problem.  But it is hard to do.

It would help, and should be done anyway. But when having 100 workers
you have to wait for them anyway.
 
> - Animate multiple units at once.  But then the player wouldn't be able 
> to pay attention to all of them.

That would be another concept. And only possible when only units are
moved which stand near each other.
 
> - Disable animation selectively.  For instance you could not animate 
> auto-settlers at all, or not animate allied units, or not animate enemy 
> units.  IMO this method has the best possibility for success.

I think the same. In most cases i only need the moves from my enemies
which i see, and are near my boarders or attacking forces. I don't need
to see my moves (i know to where i move my units) the moves from my
allies or the moves from units which are seeable because of my exploring
units.

> Server speed does have an impact in some cases, though.  One is mapgen. 
>   Current mapgen programs may take up to 5s (?) to run on popular 
> hardware.  Future mapgens may take 10x as long but run on faster 
> hardware.  Most importantly, while mapgen is running the user must wait. 
>   So optimization here is helpful, although *algorithmic* optimization 
> is probably going to be a lot more helpful than constant-factor 
> optimization.
> 
> Pubserver also needs civserver to be fast, since it runs many civservers 
> and no civclients.  I suspect this is not an issue now, but if it were 
> more heavily trafficked it could become one.  Of course we always have 
> the option of improving the hardware.

You forgot to name the AI. Some people like to play against many
AI-players and waiting to long between turns isn't funny too.

Thomas
-- 
Thomas Strub  ***  eMail ue80@xxxxxxxxxxxxxxxxxxxxx
Reden ist Silber,
      Schweigen ist Gold!




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