Looney Labs Fluxx Mailing list Archive

Re: [Fluxx] Volity Fluxx 3.1 online

  • From"S Mattison" <s.mattison@xxxxxxxxx>
  • DateMon, 15 May 2006 13:21:51 -0700
On 5/15/06, Andrew Plotkin <erkyrath@xxxxxxxxxx> wrote:
> The Bot must take time and pretend to think of it's strategy, like a
> human opponent would. I've had this debate before, whist thinking of
> ways to implement realistic AI. There HAS to be a wait time, or
> otherwise the judges will realize that your AI is simply a chat-bot,
> because it responds instantly.
But we have no intention of fooling people into thinking that the bots are

True. But if you don't treat them as humans, you have the classic
"Puzzle Pirates Foraging Imbalance". A long time ago existed an online
game called puzzlepirates.com ... This downloadable game was really
neat. It was sort of like Furcadia.com, except, instead of dreams, it
had islands, and instead of user-made games, it had built-in games.
The idea of 'Economy' in the game, was that you sail out to
unpopulated islands, and harvest the resources (Wood, Plants, Stone,
Gems), and sail them back to the islands, where you would play
minigames to manufacture these resources into artifacts like clothing,
swords, and even new ships. Any ship on the route could be attacked by
any other ship, computer or player owned, to steal their resources.
Populated islands would still produce such resources, of course, and
were sold at the markets. The problem came, however, when they decided
that they couldn't implement foraging in the correct way, to allow
everyone equal access to rare resources. They made it so that whenever
player characters 'foraged' an island, all they got were random fruits
that they could eventually sell for money. NPC boats could still
forage islands correctly, and got the resources. This forced all the
players to get their resources by attacking the NPC boats. (I even
told them the correct way once I realized it was an issue (foraging
based on percentages, not on respawn times), but they decided to leave
their game crippled.)

What this all means is that the Computer is a Magical Person whom is
allowed to break all the rules. While this idea may seem fair to
operating-system developers, it should never happen in games. If a
player plays a card, and you see the card they play, and that card
lets them play three more cards, you should see each of those cards as
they play it. (Which, I assume, is what happens?) But what happens
when a computer plays that same card, and you treat it differently
from a Human, who takes his or her time? You see it play four cards at
once (or rather you DONT see it, because it all happens at once!).

But a good fast-forward control, combined with a player preference to
control how fast changes tick in, should alleviate that.

That still doesn't address "pseudo lag", where a player who wants to
see is forced to rewind, and find a spot that he remembers the game
looking like...

>From an architecture perspective, I think it's a bad idea to delay the
bots at all. We want decisions and network communication to happen as
quickly as possible. Displaying things to the player is a UI issue, and
should be managed entirely by the client -- if only because each player
can manage his own client preferences independently. (Imagine if that
slider was controlling the *bot* -- then all the players would fight about
where to set it.)

Decisions still happen as quickly as possible. What you do, is you
decide a good wait time, say, one-and-one-half seconds. You poll the
timer as soon as the Bot takes control. Then you do the decision
subroutine. After that's done, you poll the timer again. If the wait
time has passed, go immediately with the next played card. If it has
not passed, then wait for the remaining amount of time.

We could always solve this by saying that there is no real strategy to
the game of fluxx, and the bot should always pick a card at random and
play after 1.5 seconds. ;)