Network play, including in-game voice chat

[GoogleCodeExporter]

Enhancement: add network play (discuss desired features in comments to this
bug)

Enhancement: support in-game voice chat

Original issue reported on code.google.com by [email protected] on 23 Mar 2008 at 10:23

[GoogleCodeExporter]

Does anyone else have any particular interest in working on this?  I realize 
it's not
much of a priority at the moment, though it is an area I am especially 
interested in.

Original comment by [email protected] on 4 Jun 2008 at 1:21

[GoogleCodeExporter]

This is nicer, but I think other things are more important at this moment like
improve the input, sound and rsp plugins. Soon I will start study in ufal and 
has
more time, then I will help in the input and in the rsp plugin.

Original comment by [email protected] on 2 Mar 2009 at 7:34

[GoogleCodeExporter]

rite now in the svn there is basic suport for netplay

Original comment by [email protected] on 4 Mar 2009 at 2:28

[GoogleCodeExporter]

What about: http://www.ggzgamingzone.org/about.php.en

Original comment by [email protected] on 5 May 2009 at 7:10

[GoogleCodeExporter]

Perhaps integrate with Kaillera? They have 0.9 sdk on their website.

Original comment by [email protected] on 18 Oct 2009 at 6:10

[GoogleCodeExporter]

Kaillera isn't open and doesn't support nearly any plattform mupen64plus 
support.
Look at the netplay branch in svn to see what has been done yet.

Original comment by [email protected] on 18 Oct 2009 at 7:31

[GoogleCodeExporter]

Another note is Kaillera is very old and quite outdated

Original comment by [email protected] on 3 Mar 2010 at 10:42

[GoogleCodeExporter]

I don't think that voice chat has to be provided by mupen64plus, there are other
applications like mumble and teamspeak that work lust fine for that purpose.
Networking support alone would be just fine - there is an Open Kaillera project
(http://okai.movsq.net/), but I don't know how good that it works.

Original comment by [email protected] on 4 Mar 2010 at 4:07

[GoogleCodeExporter]

in-voice chat could be added later, but would be very interesting

Original comment by [email protected] on 4 Mar 2010 at 4:12

[GoogleCodeExporter]

okai and mupen64k could be a good starting point. maybe somebody could resurrect
okaygo

Original comment by [email protected] on 4 Mar 2010 at 4:38

[GoogleCodeExporter]

And could use speex ( http://www.speex.org/ ) codec.

Original comment by [email protected] on 4 Mar 2010 at 4:41

[GoogleCodeExporter]

Must this voip stuff really be implemented by m64p? Why not inside the p2p 
network
play library? I am not sure if it is really needed at all since their are better
solutions like jingle, mumble or even teamspeak.

Original comment by [email protected] on 4 Mar 2010 at 5:28

[GoogleCodeExporter]

What libraries do you recommend?

Original comment by [email protected] on 4 Mar 2010 at 5:31

[GoogleCodeExporter]

I don't recommend any library. I only said that voip should be implemented in a
different layer and not directly in m64p. First of all more people can benefit 
from
it and also good voip applications are hard to write. An "my little own isle"
implementations aren't feasible in my eyes.

Even if speex is nice, it isn't good in all situations and will only cover the 
audio
codec but not the whole rest like session and connection management or i/o.

If you have a different view then please let me know. I just wanted to write my 
view
on that topic and not that everything is bad.

Original comment by [email protected] on 4 Mar 2010 at 5:44

[GoogleCodeExporter]

My point of view is the worst thing in implement VoIP stack wouldn't the 
difficult,
but manage the code.
This is why I agree with you, but find a good library can take a bit of time 
and I
just ask for you if you already knows any good library/framework for VoIP.

And sorry by my bad english =(

Original comment by [email protected] on 4 Mar 2010 at 5:55

[GoogleCodeExporter]

mumble is already using speex

Original comment by [email protected] on 4 Mar 2010 at 5:59

[GoogleCodeExporter]

The murmur (the server part of the mumble project) seems good, and well (I 
don't read
all, then I can't know if is enough) documented:
http://mumble.sourceforge.net/Running_Murmur
http://mumble.sourceforge.net/Murmurguide

There is a murmur protocol implementation without the Qt dependencies too,
http://code.google.com/p/umurmur/ .

Original comment by [email protected] on 4 Mar 2010 at 6:33

[GoogleCodeExporter]

i don't really think m64p needs to worry about the VoIP aspect when people can 
just
as well use a third party program that will run nicely. i think that the team 
should
focus on the actual network play before thinking about extraneous features.

Original comment by [email protected] on 27 Mar 2010 at 12:57

[GoogleCodeExporter]

I'd like to see a pidgin plugin that just allows you to start a game online
automagically with any other pidgin user.

Original comment by [email protected] on 27 Mar 2010 at 5:40

[GoogleCodeExporter]

What is the status of netplay within Mupen64plus?  The online smash64 community 
is looking for a way to move off of kaillera and this would seem like a great 
solution.

Original comment by [email protected] on 30 Nov 2010 at 5:29

[GoogleCodeExporter]

it seems like this issue fell off quite a while ago! Since mupen64plus has 
moved into a holding pattern pending the development of a UI, this issue should 
be improved upon! Forget the ingame voice chat for now, i think the primary 
thing of concern should be developing netplay itself. 
I suppose Kaillera interoperability code would be a good temporary fix, but 
given that there was once promising netplay code in the svn, it doesn't seem 
unrealistic to expect that it can't be brought back. As many other improvements 
have been made and compatibility goals achieved in mupen64plus, and given the 
broadness and reach of this improvement, this issue should definitely be 
upgraded to medium or high priority.

Original comment by [email protected] on 25 Jan 2011 at 2:40

[GoogleCodeExporter]

The real problem for now is the lack of developers. If a good one is ready to 
code a network plugin from the new API (2.0), go to the developpers's IRC. :)

Original comment by [email protected] on 25 Jan 2011 at 4:42

[GoogleCodeExporter]

I am wondering if there is any status on this.

There appears to be a proposed spec for this at 
http://code.google.com/p/mupen64plus/wiki/DeveloperNetplay

However, with my friends and retro gaming enthusiast acquaintances living many 
miles from each other and myself, netplay is a big priority.

I would like to suggest getting a functional framework implemented (perhaps via 
a server/client model so X dependencies on the linux port can be avoided if not 
necessary), and once a working implementation of that is in place, work on more 
interesting features (such as NAT traversal).

Alternatively, if it would lead to quicker initial implementation, a direct 
point-to-point connection would be acceptable but this would only allow for two 
players and would require firewall/router configuration (and, presumably, a 
much more drastic change to the codebase for the client itself). 

Original comment by [email protected] on 29 Sep 2011 at 7:08

[GoogleCodeExporter]

Me and my friends are having to rely on Project64k 1.4 and Mupen64++, and 
they're not very good, although Mupen64++ did keep us in sync with Mario Party 
2 for about 20 minutes.

From what I can see, Mupen64plus has pretty much perfected everything, the next 
step would be Netplay in my eyes... Every game I've tried works and runs at 
60FPS.

Original comment by [email protected] on 11 May 2012 at 3:59

[GoogleCodeExporter]

Please implement this for mupen64plus 2.0 

Original comment by [email protected] on 13 Jul 2013 at 6:35

[GoogleCodeExporter]

@gejimene: This is impossible because mupen64plus 2.0 is already released

But we welcome anyone who wants to implement it

Original comment by [email protected] on 13 Jul 2013 at 6:41

[GoogleCodeExporter]

Can't believe after all this time, people still have to use PJ64k to get 
online. :(

I'd love to see this developed!

Original comment by [email protected] on 7 Jan 2014 at 6:10

[GoogleCodeExporter]

Kailerra is outdated, and so are the abandoned forks of Mupen64++ and 
project64k that utilize it. It's time for something new. Would be willing to 
donate.

Original comment by [email protected] on 13 Mar 2014 at 2:31

[GoogleCodeExporter]

I too would like to see netplay, it was in the code almost 5 years ago and 
never put back, I really hope something like that will be implemented by march 
2015 for the 15 year anniversary of perfect dark. I am also willing to donate.

Original comment by [email protected] on 13 Mar 2014 at 4:07

[GoogleCodeExporter]

Maybe create a crowdfunding project at indiegogo.com or something?

Original comment by [email protected] on 25 Mar 2014 at 5:02

[GoogleCodeExporter]

I would also be interested enough to donate.

Original comment by [email protected] on 11 Aug 2014 at 7:34

[GoogleCodeExporter]

Try using the AQZ netplay plugin, had great results with it on Mario Party 2 
and 3, has never desynced on us.

Original comment by [email protected] on 13 Aug 2014 at 9:15

[GoogleCodeExporter]

If you guys are so interested in donating, maybe someone should step up and 
prepare a bounty at https://www.bountysource.com/ . Maybe with 
management/permission from richard42.

Original comment by [email protected] on 28 Aug 2014 at 4:40

[GoogleCodeExporter]

You can use AQZ netplay plugin with project64 1.7 with WineBottler 1.6.1 on osx 
10.9.2. I couldn't get it to host a game but I could join one.

Original comment by [email protected] on 9 Sep 2014 at 5:21

[GoogleCodeExporter]

Hi,

I'm working to make the netplay for mupen64plus.

Currently, I've got something running with one player/server and one 
spectator/client. It's an intermediate step. When I will have something stable 
and cross platform, I will commit my code.
The next step is of course to be able to play over the network with 2 players 
first. 
Next steps will follow...

Technical:
Currently it's tcp based without blocking socket. I think about implementing 
udp also.
I'm synchronizing inputs, it's not the best way to deal with game networking. I 
prefer state sync but it seems the emulator state is too big to do something 
like that. I will put some input lags and try to make some prediction in case 
the packet is late or lost.
There is also fps sync to avoid having some drifting simulation. (maybe a clock 
sync?)
One network method I will love to try if it's possible, it's GGPO netcode 
http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPO
s_netcode.php. The best challenge is not prediction but to be able to comeback 
to incorrect frame and re-simulate everything until the current frame.


About the voice chat, I definitely think that a third party software will do a 
better job than me.

I keep you up to date,

Cheers,

Yohann

Original comment by [email protected] on 16 Mar 2015 at 11:59

[GoogleCodeExporter]

@Yohann.m: Thanks for considering contributing to this project :)
If you have any question related to the actual code feel free to start a 
discussion on our github project page (can reach more devs on GitHub than 
here), or eventually in the mailing list. Links for both are on the google code 
page.

Hope you'll be able to do something interesting and find this experience 
enjoyable.

Bobby (contributor to m64p)

Original comment by [email protected] on 23 Mar 2015 at 6:21