Dennis,
thanks.
> Do the clients have to do anything between turns? If not, the
> simplest thing is to just have these clients block on a read request
> waiting for data to be returned from the server.
the only thing that the clients do is receiving information on the action of
other players, and updating some player-related and state-of-the-world related
statistics.
>
> {BTW: I think the term you're looking for is "console" or "command
> line" client <G>; after all -- stdout is just and I/O stream, and bash
> is just a shell interpreter}
thanks, exactly. My plan is to have a GUI in the end, but in the meantime -
for testing - it is important for me to have a working version and I was
planning to address the GUI issue later.
> The only controlling aspect of your users is the initial connection
> to the "game". Once connected, the users are at the mercy of the "game"
> to notify them that it is time for them to enter instructions (you don't
> describe enough detail to determine if a "turn" is a single transaction,
> or could consist of multiple transactions [you mentioned "buying
> letters" along with playing letters to extend words; can both take place
> in one turn?])
This is a good idea. Details: for every turn, the player performs three
operations: buy(not buy); create(a word, an extension, nothing); copyright(or
not), then passes. Other players do not really need to be notified in real
time, can as well be notified at the end of the turn.
To give some more details, basically the game works as follows:
each turn, players buy, produce, decide on Intellectual property of their
creation. The words created pass through a spellchecker and other basic checks
(does the player really own the letters he's using, etc...) and then is added
to a public wordlist; copyrighted words entitle the owner with royalties and
copylefted words do not. Every time a player extends a copyrighted word there
is a flow of royalties to be allocated.
>
> -=-=-=-=- "Game"
> ConnectionThread:
> while True:
> accept connection
> send world state to new display/player
> add connection to connection list #lock
>
> Main:
> start connection thread
> active player = 0
> while True:
> if len(connection list):
> send ACTIVE token to connection list [active player]
> while True:
> get player response
> if response == QUIT:
> del connection list [active player]
> #lock
> update world state
> for p in connection list:
> #lock
> send world update to p
> if response == EndTurn: break
> active player = (active player + 1) % len(connection
> list)
> else:
> sleep(1) #no players connected, so sleep before
> repeating
>
> (the #lock indicate operations that may need to be protected by using a
> lock object)
>
>
> -=-=-=-=-=- "Display"
>
> connect to "game"
> ACTIVE = False
> while True:
> get game data
> update console display
> ACTIVE = game data == active token
> if ACTIVE:
> get user input
> if user input == EndTurn:
> ACTIVE = False
> send user input
> if user input == QUIT:
> break
> disconnect from "game"
>
Thanks for this pseudocode - helpful in many ways. The only reason I had to
structure the game as a one server-many clients was that I wanted to
centralize the functions related to computing the payoffs etc in the server. I
think this can be done in your architecture too.
P
--
Paolo Crosetto
---------------------------------------------------------------------
PhD Student in Economics
DEAS - Department of Economics - University of Milan
---------------------------------------------------------------------
--
http://mail.python.org/mailman/listinfo/python-list
