On 09/26/2013 02:05 AM, Daniel Sank wrote:
I want to implement something functionally equivalent to a network chess
game. I first consider how I would do this on a single computer with no
network (maybe this is bad thinking). Each piece in the game is
represented by an instance of class Agent. Each agent has a .graphics
attribute which is an instance of a class from a GUI toolkit library or
equivalent. Whenever an agent in the game needs to do something there
will be business logic executed by the game objects proper (ie the
agents) which will invoke methods on the .graphics objects to update the
screen. This sort of structure seems natural as it allows easy
integration of drag/drop, mouse click detection etc. It also nicely
separates the real business logic from the GUI.
I think you have the right idea but that's still a bit too much coupling
between the logic and the UI for my taste. I don't want the game logic
to have a .graphics attribute; I want the game logic to fling game
events to one or more consumers, each of which may or may not be a GUI.
(Maybe it's a headless AI player. Maybe it's a logging service. The
server shouldn't care.)
Now I want to run over the network. The question is how should I set up
references between the client and server objects?
There's more than one way to do it.
Here's my game that uses PB: https://github.com/dripton/Slugathon
I used PB (because AMP and Foolscap didn't exist yet), but I didn't use
the fancy bits of PB like Cacheable, because I strongly prefer simple
remote method calls to fancy remote objects. But if you grep for
callRemote, remote_, and perspective_, you can see how I did it.
As noted above, my game server flings events (see Action.py for what
they look like) to both GUI and AI clients. The actions are just little
value objects that happen to inherit from pb.Copyable and pb.RemoteCopy
for convenience, though they just as easily be JSON blobs.
Of course, it's probably much easier to just use Cacheable. It comes
down to programmer preference.
One piece of advice: do the network code first and always exercise it,
even when playing on a single computer. Every time I've written a
single-machine game first then tried to add networking later, the
networking has been a mess to debug.
--
David Ripton drip...@ripton.net
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
