On Sun, 14 May 2006, S Mattison wrote:
My solution to this; Treat each card played, and each sub-hand as a
different move. When the user, or any bot, plays a "Play 5", that is
one move. Update all. Then let the next card be played, and so on.
That's what we are doing. However, a single "update" is fast enough that
if two things happen close together, you won't see the intermediate state.
(Relying on the slowness of screen updates to pace interface changes is
obviously a bad idea -- DOS games learned that twenty years ago.)
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
humans.
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.)
Now, slowing down the client's display makes me nervous too, because then
there's a mismatch between what the client is receiving from the referee
(server) and what the client is receiving from the player. The player is
"lagged", for all practical purposes. In most on-line games, that's a
*bad* thing. :)
But a good fast-forward control, combined with a player preference to
control how fast changes tick in, should alleviate that.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.