On Wed, Jun 17, 2009 at 5:35 AM, Madeline Book<madeline.b...@gmail.com> wrote:
> For cma in particular: it is slow (no CPU computation should take
> longer than a second; the algorithm does not scale), inefficient (too
> much client-server communication making it unwieldy in online
> games), does not adapt well to non-default game rules (the ugly
> cross-dependence of common/ files and untested behavior for other
> rulesets), and fails to accomodate even basic game situations that
> occur again and again (no way to prevent greedy tile grabbing, no
> way to fix tile usage, recomputation right at the very moment when
> client needs to be responsive, etc., etc.).

I'm not sure that the _start_ of the turn is the right time to run the
CMA.  So many times I've forgotten to check all my cities after
founding my 14th, and the next turn all hell breaks loose, because the
CMA never had the opportunity to fix the civ-size unhappiness.  I'd
rather pretend I didn't just consider multithreading.

I'm not too fussed about problems with other agents though; really
only with agents-in-general.

> (I mention in passing that the entire "attribute" system should be
> removed, and probably would have been long ago, were it not for
> the single annoying dependence of the cma on it.)

Would you suggest that client-side code should rather keep state in a
section file?  (Or even in .civclientrc itself.)  If all goes to plan
I'll want to remember things like "The Georgians have stabbed me in
the back 7 times, but the Sami have always been there to help me."
Things that cannot, even in principle, be calculated from the game
state.

> Every potential agent implementation must consider whether it fails
> in the above mentioned respects at least.

Oh, my agent will almost certainly fail here.  Epic fail.

> In general there is also the
> question whether client side automation afforded by "agents" is even
> desirable for freeciv, as then it may degenerate in to battle of computer
> programs rather than players.

FWIW I'm working for the machines to hasten this battle of computer
programs to defeat the humans.  I just want to see how credible a
client-side AI I can make.  (Apropos, I seem to recall someone else
having gone this way, but I can't find the announcement.  Anybody else
remember who / better search terms?)

But I do understand: as a human player I also dislike the idea of
twitch-like AI reaction times.

> For example in the case of the "city worker twiddling" problem that
> cma tries to alleviate (player does not have to micro-manage citizens,
> in theory), one should also consider fixing the design of the game
> itself. That is, instead of throwing AI at the game problem, consider
> finding and proposing better game mechanics that would not suffer
> the same player annoyances.

Some of the proposals I've seen would also make it easier for an AI to
accurately value a site for building a city.  I'm finding it hard to
analyze even how I choose places myself.

> Then there is the current problem of agent implementations almost
> always requiring to keep track of some form of state between
> activations, but the design of freeciv packets makes this quite
> cumbersome at best (cf. the request id hacks used by cma). In brief,
> there is poor support for stateful client side programming (other
> parts of freeciv suffer from this too, and I have a "solution" in mind,
> but have not yet had time to make a test implementation).

This reminds me of another obstacle to easy agent programming: by the
time the agent gets its callback, the entity causing the event might
be gone.  This manifested in a segfault when my unit-changed callback
tried to print a killed unit's name.

What is the intellectual status quo in freeciv regarding reference
counting things like units, cities (tiles don't die)?  I'd like it if
the client-side unit/city objects hung around a little bit longer, at
least until the agents are done using them.

I can also foresee problems in trying to correlate consequences with
actions.  My agent will eventually have to know that a particular
unit-changed callback relates to a dsend_packet_unit_move() that it
issued earlier.

> Finally I would just like to mention lua as a much better candidate
> for work than the agents framework. Extending and implementing
> all non-resource intensive code in a lua engine would do wonders
> for AI programming, both on the server and the client side. At
> least so my dream goes, assuming that the lua integration is done
> right. ;)

I like the idea of a scripting language hooked in, but for my code I
think it might suck.  I have to compensate for my Artificial Stupidity
with zillions of CPU cycles.  If my AS ever has to wait for a human
player, it isn't doing enough number crunching!

Thanks for your comprehensive reply.

_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to