glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] concept for building priorities


From: Joe Wells
Subject: Re: [glob2-devel] concept for building priorities
Date: Fri, 24 Aug 2007 14:11:39 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

"Kai Antweiler" <address@hidden> writes:

>> While we are waiting for you to program it, what do you think of just
>> using the simple method I proposed, namely NewAverage = (OldAverage *
>> 0.9 + NewData * 0.1)?
>
> Put it in an inline function and include commends on why you chose these
> numbers.   As a statistician I probably want to play around with this
> in a few years.

By the way, I am assuming the number 0.9 will be replaced by a value
determined by actual testing.  I was just using 0.9 as an example.

>> Probably the time the globs take should be adjusted based on their
>> speed to get instead the time the "average" glob _would_ have taken.
>
> But if you want to compute a time period, you have to normalize the
> value.  Otherwise you can not compare UT and HT.

I don't understand the two sentences above.  Can you clarify?

>> However, I don't think we should adjust for the distance of the trip,
>> because a globule arriving from a long distance may be the first of a
>> large number of globules arriving from a long distance.  For example,
>> consider the first warriors that start returning from a strike on an
>> enemy base.
>
> Yes, true.  We need more values for better estimation.  Let's say
> each Inn stores values from the last 20 customers.  If less than 3
> globs differ much from the median their values are flattened or
> rejected.  If we additionally use the distance and speed of those
> globs who already signed up for a meal, we should adjust to a group
> of long distance travelers faster.  We can estimate AT before the
> actual arrival.

I can see that storing additional information could help make the
numbers better.  It's a nice idea.

I worry that the increase in the quality of the numbers might not be
enough to justify the more complex programming involved.  If we keep
the programming simple there will be fewer bugs to be tracked down and
solved.  Programming and debugging time for glob2 is a scarce
resource.

What do you think about first trying the simple approach which keeps
only a single computed average number for UT?  I think even the simple
approach would improve game play enough over the current situation to
justify it.

>> In the meantime, what do you think of my proposals?  I think they are
>> fairly simple, and could well be good enough.  Combined with Leo's
>> idea of boosting priorities based on the length of time spent waiting
>> to hire a globule, I think some nice improvement in game play might
>> result.
>
> I think so.

Okay, good.  Does anyone want to try implementing it?

> Adjusting Inns is too distracting right now for the player in my opinion.

I agree.  Right now a player must regularly scan through all of their
inns to adjust the requested worker numbers.  It makes it almost
impossible to play against Nicowar without frequently pausing the
game.

-- 
Joe




reply via email to

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