I have one question about the UDP bit. What does rolling our own custom networking solution give us over supporting existing high-performance networking libraries for games e.g. raknet? If nothing, then I would suggest to focus more on the property class level of things.
Who might mentor what is a little unknown at this point :) A few of us might be interested, depends on other proposals. On 4 April 2011 10:44, Dan Walters <[email protected]> wrote: > 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 > -- - Mike
------------------------------------------------------------------------------ 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
