On 3 April 2011 23:27, Christian Van Brussel <[email protected]> wrote: > Hi, > > a network layer in CEL is clearly of great interest. > > But I see one main problem to your current proposition: it does not seem > to care at all about the current network layer of CEL (see > CEL/include/physicallayer/network.h). However, if I remember correctly, > the guy who wrote it spent almost a year thinking about this API and > asking questions on the CEL forum before commiting it.
I will look up on the forums. The CEL implementation is a very important part and the most unique of the design. Am also looking at network.h. The interface looks robust and well thought through, and features some of the things I discussed such as channels for example. I will try to amend my proposal to add to this rather than replace > > The current implementation of the network plugin is TCP-based, but the API > abstracts the actual implementation of the plugin, so this can be replaced > later by a UDP or Peer-to-Peer implementation. The API is rather good so > there is no real point to start a complete new one doing basically the > same thing. I agree that there is no point in re-writing code that already works. My argument in the pdf document is that a TCP library will not be able to provide high performance networking as the TCP protocol incorporates certain time delays when waiting for lost packets, keeping packets in order, etc. which in poor network conditions (when packet loss occurs such as when using wireless for example) can cause 'jumpy' flow of data. This is fine for a strategy game, a chat server, etc. but will not give acceptable performance for a game that requires responsiveness such as a first person game. This is a point that I would like to discuss - is this kind of performance required? It is possible to add an additional networking interface for UDP for when the TCP library isnt responsive enough, but having two libraries when UDP could do the job of both seems pointless. Likewise, we could not add UDP if time critical delivery is not a prioritized feature, instead focusing on communication and entity layers. > > What the current network plugin lacks is described in the GSOC page: "A > first need would be to define and implement a system so that the whole > networking behavior is defined through property classes, e.g. so that a > CEL game can become a networked game simply by adding some specific > entities and property classes. Another need would be to define for each > existing property classes how they update efficiently to/from the > network." I do try to discuss this at length in the object / entity layer. As far as I can tell, it is a case of serializing entities or members of entities and synchronizing those values. For this I was considering inspiration from Boost.Serialize where the programmer could implement write and read virtual functions for an entity and the networking engine could take care of the rest. I was also proposing that the networking implementation was slightly open ended so that the application programmer could decide under what data should be send and when. Different types of games will lend themselves to different implementations, sometimes a game will want to sync positions and rotations, other times it will want to sync physics forces, other times user input. In the pdf I was proposing a simple set of objects that handle the synchronization of an entity or the property of an entity. This would also include a framework for managing games, providing callback for players joining and disconnecting, etc. It looks like much of that is already implemented. > > That would be the main topic of a GSOC project on it. An UDP > implementation is clearly interesting, but it would have any interest only > once the network layer is actually completely integrated in CEL. > Perhaps I should amend the application to propose something more along the lines of developing the existing library into production code including implementing the synchronization handling objects, game management, etc? If at all, UDP could be an optional deliverable. This way, the focus would be on developing a finished product rather than an entire networking framework and CEL would probably have more to show for as a result. Can I ask who would mentor this project? Best wishes, Dan ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
