Friday, June 08, 2007

Minimal Pygame Networking Achieved

Hello pygnet! pygnet sits on Twisted, and make it easy to trade marshal-able Python objects between clients and a server, using TCP.

It also (seems to) integrate well with the de-facto standard pygame event loop, as long as you call the poll function regularly.

So... what is next in my quest to complete a multiplayer-persistent-world-online-game? I think I need to define the game rules, and a backend strategy for implementing them. Also need some way to persist data to disk. ZODB perhaps?


Richard Jones said...

pygnet eh? So, will it work with pyglet? :)

I would suggest you talk to Will McGugan about his gameobjects library, as he might be thinking about the same issues as you.

I'd avoid ZODB since most games end up with mostly relational data in them, as opposed to object data. In that line I'd look at SQLAlchemy as a good layer to build on, as that then gives people freedom to choose an appropriate (or use their favourite) database backend. For peer-to-peer hosted casual games, sqlite should be more than adequate and is definitely easy to ship :)

Florian said...

pygnet uses marshal to deserialize data from the network. nuff said (insert security nightmare here)

Simon Wittber said...

The serialization scheme will be independent of pygnet, so you can choose something suitable for your application.

There are plenty of safe serialization schemes out there. I've even written one, as a safe alternative to marshal.

Florian said...

I'm playing cheesecake with extensions now.

1) no license meta data, no readme, no install, etc.

2) no mention about the security implications of pygnet in the default (marshal) setting

3) using marshal as a default, which is probably what nobody *really* wants to do.

4) using the encoding as a module global is bad design. It means that even though you got a protocol abstraction, all protocol instances share a common state.
Solved properly you should configure GameProtocol objects with the encoding they should use (and whatever other parameters they need). You might want read "Design patterns" by Gemma et all.

Simon Wittber said...

Mostly valid points, except 4). All protocol instances are required to share some state, I had to make part of that shared state configurable due to security concerns. If it was anything more than that, I would agree with you. Fortunately, Python's late binding came to the rescue. I've seen this done in a few Python projects... hey is this a new pattern? :-)

To do it as you suggest, I would need to subclass the protocol class, customise its behavior, and pass it through to the init functions... but that is starting to go beyond what pygnet is intended to do. If I do that, there is no advantage to using pygnet, Twisted becomes the better option.

BTW: If you would like to help out, please join the project!

Florian said...

Just, using multiple protocols is then impossible, ooops...

Though there is neither a need to subclass, nor give up defaults, python to the rescue.

Simon Wittber said...

Nice solution...

...but it's doing more than I want pygnet to do. I'd like to keep any specific to twisted out of the API, and keep it simple enough to be understood in about 60 seconds.

The best thing is really to replace marshal with something else, as you originally implied.

Popular Posts