Hello again, I'm Anthony. In addition to the GameStream proposal, I'd like to propose Netplay in RetroPlayer. My experience in networking is limited to a small UDP project at a previous internship and an upper division networking fundamentals course, but I'm very interested in this topic.
Summary:
Adding networking support for RetroPlayer emulation for multiplayer games, in a similar fashion to netplay on other emulation platforms like RetroArch. Must be able to deal with common networking issues and latency.
What will the project focus on:
The scope of this project is a bit broad, with many little optimizations that could be made in order to improve usability and such. The most important part of this project is getting some sort of netplay in order over LAN, and providing a clean and central place for emulation networking.
How I will achieve this:
A binary addon that will provide networking capabilities to RetroPlayer. I think it would be wise to implement using UDP due to congestion control properties and overhead of TCP. This project would require a server-client model of doing things. I would look into architectures like GGPO (good game peace out) for guidance in creating a smoother online experience with RetroPlayer.
One possibility to adapt the existing
netcode of RetroArch, which would have the added bonus of being compatible with their clients.
Benefits:
Multiplayer functionality over the internet, which is perfect for playing those nostalgic SNES with friends.
Goals:
- Develop a protocol between server and clients for two player games
- Handle synchronization issues, possibly through syncing key save state frames provided by the rewind functionality.
- Have a playable netplay via LAN
- Deal with issues over the internet to deal with less than stellar networking means, including latency, dropped packets, etc.
What does it touch in Kodi
Probably stuff in Kodi/network, though I don't know how much access addon's are allowed.
Also, some changes in the RetroPlayer core and Game api might need to be changed to accommodate network play.
Requirements
C++, networking knowledge
Let me know if theres anything that could be improved. Thanks.
Nice! Be sure to checkout this other discussion thread in RetroPlayer subforum for some related network gaming ideas:
http://forum.kodi.tv/showthread.php?tid=201868
Much of this could probably be achieved through an implementation based on the RakNet framework? Other than network communication the RakNet framework provide Lobby System and much more.
https://github.com/OculusVR/RakNet
http://www.jenkinssoftware.com/features.html
Anyway, using an existing framework like RakNet or similar frameworks would let you focus on the other parts.
(2015-03-11, 00:56)acmiyaguchi Wrote: [ -> ]I think it would be wise to implement using UDP due to congestion control properties and overhead of TCP.
Not sure if you need to restrict yourself you only UDP or only TCP if you use an existing framework with supports both, again recommend that you have a look at RakNet.
(2015-03-11, 00:56)acmiyaguchi Wrote: [ -> ]One possibility to adapt the existing netcode of RetroArch, which would have the added bonus of being compatible with their clients.
Be careful to check open source license compatibility, which goes for all and any code you will look at for Kodi integration.
(2015-03-11, 00:56)acmiyaguchi Wrote: [ -> ]This project would require a server-client model of doing things.
Cool, but if possible please then also make clients be servers for casual peer-to-peer network gaming. I just don't think is not very user-friendly if one would have to use an separate external server application for some quick peer-to-peer network gaming on a local network, especially not in a 10-foot experience application like Kodi which is suppose to be able to run as an appliance without a desktop PC or server.
I think from a usability point of view it would be best if each Kodi application could act both as a client and as a server for simple offline peer-to-peer connection? Similar to good old "System Link" for Xbox
http://en.wikipedia.org/wiki/System_Link
Note that Kodi already uses Avahi (Zeroconf) for auto discovery on a local network
http://en.wikipedia.org/wiki/Avahi_%28software%29
(2015-03-11, 00:56)acmiyaguchi Wrote: [ -> ][b]How I will achieve this:
A binary addon that will provide networking capabilities to RetroPlayer.
I'm not sure that the networking code itself would work as a binary addon within the current concept of RetroPlayer and Game API design?
Maybe create a whole new "Networking API" instead and make RakNet use that API? Or add a networking extension to the Hardware API? Having a "Networking API" or networking extension to the Hardware API it could possibly be reused for other networking related stuff than gaming in the future.
By the way, here below is a diagram of garbear's layout design for how RetroPlayer and the Game API fits into Kodi today:
This is the current layout of the RetroOlayer project. It is centered around two APIs, the Game API (connects RetroPlayer to Game Clients) and the Hardware API (connects Game Clients to input). The Hardware API moves all of the joystick code out of XBMC and into binary addons. I have also started working on support for the Retrode and Retrode-like devices through the media reader sub-API.
You'll notice the only functional difference is that RetroPlayer is no longer connected to any input. I've re-written the joystick API two or three times, and the end result was never satisfactory because I couldn't separate the input from RetroPlayer. Now, with input gone, the complexity of RetroPlayer is greatly reduced, leading to more maintainable code.
Putting as much code as possible behind APIs is generally a good strategy. I learned this rather late in the development of RetroPlayer, so there are still quite a few parts that are entangled. however, looking at this diagram, I think I'm on the right track - components are finally only communicating with their API, and not with other components.
Thanks Hedda for all the suggestions, I appreciate it
(2015-03-11, 16:04)Hedda Wrote: [ -> ]I just don't think is not very user-friendly if one would have to use an separate external server application for some quick peer-to-peer network gaming on a local network, especially not in a 10-foot experience application like Kodi which is suppose to be able to run as an appliance without a desktop PC or server.
To address this issue really quick, what I mean by Server-Client is that one person would be hosting the game and the rest would join under him. This way its easier to address issues of synchronization and such. It doesn't necessarily require an external server to do. Ideally someone would be able to set up a machine as host, call up a buddy and tell him to connect to his machine for some multi-player fun.
Essentially how I see this addition working would be to exchange save-states and input between two running instances of the emulator. If I remember correctly, then rewind functionality depends on a stream of save-states in order to work, which would work well for synchronizing two separate instances. You would have to use one machine as reference, which would be the first player machine as host. I think the RetroArch implementation allows you to switch who is host and client which I think is useful.
I have been taking a look at Kodi, and there is already some networking utilities that can be reused, I just have to take a look at what is available to addons. For example, there are already a cross-platform Socket class located in Kodi/network/Socket.h. I think that a framework like RakNet might be a bit overkill since the netplay doesn't need too much complexity. The less dependencies I can draw in the better, but RakNet does seem to have a lot of nice features.
With how volatile development seems to be on RetroPlayer at the moment, I would want to have something that is working and is easily maintainable. If there is need for more functionality, this addon would ideally be the place to make the changes, something like
garbear's peripheral joystick addon which has already been abstracted away from the RetroPlayer core. There would probably have to be a few changes to the Game API to accommodate networking and a netplay addon, but I haven't spent the time to look too deep into the code.
(2015-03-11, 00:56)acmiyaguchi Wrote: [ -> ]One possibility to adapt the existing netcode of RetroArch, which would have the added bonus of being compatible with their clients.
This is a really interesting idea that I haven't considered. It would be really cool if our frontends were interoperable. However, the code translating between the libretro API and the Game API is growing as I tweak the Game API to be more suitable for Kodi. I worry that RetroArch compatibility might limit, or at least complicate, this project.
My dev process for the Game API has been to copy the libretro api EXACTLY, and as I tweak the Game API, I update the libretro wrapper to maintain 1:1 compatibility. A similar process for RetroArch netplay interoperability might be suitable.
(2015-03-11, 00:56)acmiyaguchi Wrote: [ -> ]Deal with issues over the internet to deal with less than stellar networking means, including latency, dropped packets, etc.
The scope of the project doesn't require this, but it would be a good "extended goal" once the other primary ones are met.
I haven't given netplay nearly as much thought as GameStream, but if you end up choosing this instead of GameStream I'll help flesh out the rest of the details for the final proposal.
FYI ZeroMQ is a great networking library.