[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Underware-devel] Networked pong
From: |
Loic Dachary |
Subject: |
[Underware-devel] Networked pong |
Date: |
Wed, 21 Jan 2004 13:44:31 +0100 |
Hi,
The pong example currently in the CVS implements a protocol
that allows two players to play together. It works on a lan but I
doubt it would work over the internet. A server sits between the two
players. At present the protocol looks like this:
- version -> check that client/server version match
- name -> client advertise its name to the server
- advertise -> server advertise other players name to the clients
and associate them to a serial number used instead
of the name
- context -> server informs client that it has been given a serial
number
- xy -> client sends paddle position to server that broadcast it
to the connected clients
- throwball -> client sends a ball position to the server and a
direction, the server sends it back to all clients
including the client from which the packet originated
When ever the ball bounces (table border or paddle) it sends a
throwball packet to the server. Each client synchronize with this event,
ensuring that no client can drift significantly from another.
The twisted protocol is written in the most simple way so as to
tightly control the packet size. Each packet type exists both in the python
and C++ namespace so that C++ game code can manipulate them convienently and
the python server code can do the same.
I'm not too happy about the python/c++ binding for packets
because there are certainly many ways to implement it in a much
simpler way. The scheme used, however, is appropriate for exposing
a class hierarchy to python and enrich them with python methods if
appropriate. For instance, each packet class has pack/unpack methods
used to serialize packets. The C++ packet hierarchy currently looks like
this:
MAFPacketEvent
MAFPacketXY
MAFPacketString
MAFPacketAdvertise
and we want the python hierarchy to mimic it:
Packet
PacketXY
PacketString
PacketAdvertise
We do that by intermixing C++ and python classes as follows:
CMAFPacketEvent (C++ wrapper of MAFPacketEvent)
Packet
CMAFPacketXY (C++ wrapper of MAFPacketXY)
PacketXY
CMAFPacketString (C++ wrapper of MAFPacketString)
PacketString
CMAFPacketAdvertise (C++ wrapper of
MAFPacketAdvertise)
PacketAdvertise
The non-intuitive part is that a C++ class python wrapper inherits from
a pure python class.
The python integration for the whole set of packet classes is
generated by the underware/builder.pl script based on the
c_template.{h,cpp}, all_template.{h,cpp}, bind_template.{cpp}
templates. The human written part of the binding (transform C++ member
to python object) is written in bind_<class>.cpp. All these classes are
in the underware directory.
I would not go as far as to say that this is simple. It will
be worth the effort when we decide to expose CGI classes though. At
present it is doing the job and tweaking the network protocol within
these constraints is reasonable. I won't rework this part before next
month.
Cheers,
--
Donate to FSF France online : http://rate.affero.net/fsffrance/
Loic Dachary, 12 bd Magenta, 75010 Paris. Tel: 33 1 42 45 07 97
http://www.fsffrance.org/ http://www.dachary.org/loic/gpg.txt
- [Underware-devel] Networked pong,
Loic Dachary <=