[Kde-games-devel] Online Granatier, common real time online gaming libs?

[Albert Astals Cid]

El Dissabte, 1 de juny de 2013, a les 01:31:28, Nathan Sala va escriure:
> 2013/5/31 Mathias Kraus <k.hias at gmx.de>
> 
> > Am Mittwoch, 29. Mai 2013, 21:56:40 schrieb Nathan Sala:
> > > Hello there gamers,
> > 
> > Hi
> > 
> > > We had a really great time playing Granatier today on the KDE stand for
> > 
> > the
> > 
> > > OpenSource solutions forum in Paris.
> > > People also enjoyed watching us ;)
> > 
> > Nice to hear :)
> > 
> > > It came an idea which is to implement the online mode.
> > 
> > I always wanted Granatier to be an online game, but I didn't find time to
> > do it.
> > Last year, I think, I saw a blog post from the telepathy guys. They had a
> > proof of concept online version of battleship, but I don't know what
> > happened with that.
> > At that time it sounded reasonable to use telepathy to connect the player
> > with each other. With telepathy we wouldn't need to care about such things
> > like NAT and so on.
> > 
> > Yes that would be good. Can it help with NAT?
> > 
> > > As far as I know, there is no example of real time online gaming in kde
> > > games?
> > 
> > I see a common part which would be valid for any game:
> > > - A client/server model with their specific interfaces.
> > > - Network layer
> > > 
> > >   - A common messages header.
> > >   - A TCP/UDP messages matching.
> > >   - A messages synchronization based on sequence numbers.
> > > 
> > > - A later next step: textual description of the network messages and
> > > automatic structs and classes generation at compile time.
> > 
> > It look like you have some experience with online gaming. It would be
> > great if you could help with a common library.
> 
> No. I have experience about networking performance and reliability, but not
> about game engines.
> As a first step I want to build a solid low level networking UDP/TCP layer
> which will handle clients/server synchronization.
> But then I need to find a good generic algorithm and therefore a  protocol.
> 
> The best idea I have until now would be like:
> - User inputs are sent to the server and redistributed to all the clients.
> - Every XX milliseconds, the server sends the full current state of the
> game to all the clients.
> 

Hi guys, i don't want to discourage anyone from doing cool work, but want to 
warn about how "hard" is to do this stuff in a maintainable way, we have a 
"deprecated" library for networking in libkdegames called kgame (yeah aswesome 
name) and we had during a time ggz bindings.

The problem is that we don't have much people with network programming 
experience and network programming is hard (and is a big-ish attack vector 
too) so we ended up deprecating/removing those libraries.

Then again I'm not saying you should not work on those but maybe it'd make 
sense to find out if there's anything out there we can reuse first.

And if we end up writing our own stuff it'd be also cool if it doesn't endup 
too deep inside games that use it (i.e. if in 5 years the library is 
unmaintained, yanking the library for the game should only mean losing the 
netowrking features, not losing lots of other things, that afair is what 
happens with the kgame lib))

Again, this is not a "don't do it", just a small past history that might or 
might not help in the present.

Cheers,
  Albert


> > > And then Granatier as a POC:
> > > - Modification of the game engine to fully support the client/server
> > 
> > model
> > 
> > > with 2 types of clients: local and remote.
> > > - Some UI work about creating/joining games and so on.
> > 
> > I already did some proof of concept work in a scratch repo to try to
> > separate the game engine from the visual representation, but didn't get
> > too
> > far.
> > It's a big task, the codebase is about 8000 lines of code, but it is
> > doable if there are several people working on it.
> 
> What a good new. That's what we need!
> 
> > Regards,
> > Hias
> > 
> > > This is just a first thought, so any comment is greatly welcome
> > > 
> > > Regards,
> > > Nathan