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 dripton@ripton.net