Re: Well...

[Matt Slot <fprefect@AmbrosiaSW.com>]

Jan Ekholm <chakie@infa.abo.fi> writes:
 > The way it looks now I think I have to abandon the 'Zombie' project. I see
 > no use for it anymore and I definitely have seen no public interest
 > whatsoever,

I've been meaning to send some feedback for a while. You have something
working, which is more than most of the other network libraries I've seen.
Here is a list of suggestions based on my cursory examination of the Zombie
docs and APIs:

  * The Web page and documentation look very good, which is a very good
    inducement to developers -- they want to know a library is supported.
  * You need to actively port to a wider range of platforms, as there are
    very few Linux-specific game projects -- people want to keep their
    options open. WinSock would be an obvious next step, and then BeOS and
    the Mac.
  * There are too many public classes and files to wade through. If a
    novice had to choose between BSD Sockets and Zombie, it'd be simpler
    to learn sockets.
  * I think Zombie tries to do too much -- it's both a low-level API that
    wraps BSD Sockets and POSIX, and a high-level API that does a bit of
    administrative work (like teams and names) but nothing useful. Pick one
    or the other, or architect it so that each layer is clearly distinct.
  * You use C++, which means the low-level stuff should be easy to abstract
    and port to another platform.
  * You provide a few high-level services, but punt on the major issues like
    synchronized timers or tracking client latency/bandwidth.
  * Alot of the APIs and documentation uses BSD Sockets terminology, which a
    developer who chooses Zombie may not be familiar with.


 > [...] but apparently everyone wants to do networking 'their own'
 > way. Well, that's the way it goes...

Because I've yet to find a network session library that meets my needs (and
satisfies my technical side), I wrote my own:

  * Mundane utilities, like memory allocation, threads, and queues are
    abstracted into a specific utility library
  * The low level network API abstracts the platform networking (sockets,
    OpenTransport, etc). It only worries about endpoints, addresses, and
    producing/consuming queues of data.
  * The high level session API tracks hosts in the session, exchanges data
    between given hosts by ID (not address), tracks latency statistics, and
    performs any other administrative tasks (name+logo, synchronized clock).
  * Messages are either fast status updates (current position, orientiation,
    pressed keys) and reliable state changes (changes to the world, captured
    resources, new objects) -- not specifically tied to TCP or UDP.
  * The application is responsible for maintaining the simulation on top of
    the high-level API, sending status updates or state changes as necessary
    to keep the world operating.
  * The high level API is in C and only has about 20 calls.
  * The library runs on MacOS, Windows, and UNIX.

Once you differentiate between low-level networking, high-level networking,
and the simulation itself, you can focus your documentation on the *really*
important design issues, like compensating for latency.

Matt

(Before you ask, my network session library is not open source. We're using
it to develop several upcoming games in-house.)



/* Matt Slot, Bitwise Operator * One box, two box, yellow box, blue box. *
 *  <fprefect@ambrosiasw.com>  * <http://www.ambrosiasw.com/~fprefect/>  */