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

[Eneko Nieto]

Maybe building something above any floss network library? Google
around have found these:

http://www.zeroc.com/ice.html
http://enet.bespin.org/Features.html
http://pocoproject.org/features.html

I haven't found any suitable library with lobbying, server discovery
and so on. Anyone knows someone?

Eneko

2013/6/1 Albert Astals Cid <aacid at kde.org>:
> 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
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel