Boat Racing Game

I'm really really late to this game and it might be a stupid idea.



I'm working (ridiculously early stage) on a boat racing game.  I've got multiplayer plans and one of the possibilities I had been considering is to use P2P for in game VOIP.  I'm only considering it if the server traffic gets bogged down, and I'm a very long way from pretty much anything at this point.  Right now I have some 3ds models from a friend, the jME code from CVS, a dream, and 9 years of Java development experience along with some C++ back in the day.



It seems that from a conceptual level it could take away a fair amount of bandwidth strain in exchange for the aforementioned NAT/firewall/ISP blocking issues.  I don't care about alienating users that can't or won't do port forwarding.  I'm not planning on selling it or even really making it available to everyone.  Just an idea.  Thoughts?

splitted



Let me ask this, how would it take away bandwidth strain by using P2P?  I mean, the idea of removing strain off of a server by removing the server that's pretty sound, but by removing it off the server you then push the bandwidth usage increase to every client now.  If you don't have and cannot get a server this may be your only option, and I'm often accused of painting an overly grim picture of P2P, but I think you should really consider using client/server if you have any probable way of getting one.

How would you go about implementing the physics for a boat travelling across water in jME-Physics with waves?

Good question. I'm curious.

adamgp said:

How would you go about implementing the physics for a boat travelling across water in jME-Physics with waves?
You can use a 'spongy' material for the water... or you could use a couple of 'spongy' joints to avoid collision detection at all and position the joints on top of the waves...

Good answer. I guess the springs would have to be disabled when the boat is above the water to allow them to jump - not sure how easy that is.

unless you are going to make a massive game, you wont need to make something special out of it.

Use the trivial N Square math to calculate the amount of packets you will be using:

Lets say 5 boats, with a tick of 10 packets each second(every 100ms a packet should be sent)

it will be 5 * 5 * 10 packets. Each trimmed UDP packet will be around 9 header, 4 * 3 for location, and about 3 * 4 for direction.

5 * 5 * 10 * (9 + 3 * 4 + 3 * 4) = 8250Bytes per second. which are around 8kbs for the server in upload bandwidth.

IT will go fast up for just one client more, but you will easily could have more.

Lets say you have a 20kbs upload modem you want to know how many clients can handle.

x = clients



x^2 * 10 * (9 + 3 *4 + 3 * 4) = ca 20000

and closets I can get is 7.74. Meaning there can be just a little under 8 on a 20kbs upload modem.

However if you wanna play LAN, most routers support 100/10mbit, which would not give a problem for many player :slight_smile:



if you want the exact number it will be something like this:

x^2 * 10 * (9 + 3 *4 + 3 * 4) = ca 10^6 * 10

which is a little over 174 players, however you might have to send other information, so I can only give you a point in the right direction.

If you say you can take easily 50 people on a LAN, I think you could be happy :slight_smile:





Hope it helps.

irrisor said:

adamgp said:

How would you go about implementing the physics for a boat travelling across water in jME-Physics with waves?
You can use a 'spongy' material for the water... or you could use a couple of 'spongy' joints to avoid collision detection at all and position the joints on top of the waves...


Sorry about the threadjack, networking stuff follows...

I'm not looking at exact wave modeling.  Maybe at some point in the future but for forseeable future random small bumps will do nicely.  I was just going to go with something similar to a dynamic version of the flagrush tutorial.  It doesn't look to me like this sort of application translates all that well to JMEPhysics in its current state.  I don't have any fancy suspension or really any moving parts that I can't approximate easily.  I'm going to treat them as blocks on a (random) slightly bumpy surface and just push them around.  I figure that's a good starting point for a prototype and then decide if more accurate modeling is needed.

As far as networking goes, I really don't have much reason to suspect that VOIP will cause lag but I have heard a lot of talk from users of stuff like BF2 that see degradation when using in game VOIP from a purely black box standpoint.  All I was planning on doing was designing for the possibility that it would be an issue and maybe support the P2P option.
darkfrog said:

splitted

Let me ask this, how would it take away bandwidth strain by using P2P?  I mean, the idea of removing strain off of a server by removing the server that's pretty sound, but by removing it off the server you then push the bandwidth usage increase to every client now.  If you don't have and cannot get a server this may be your only option, and I'm often accused of painting an overly grim picture of P2P, but I think you should really consider using client/server if you have any probable way of getting one.


I'm operating under the assumption that bandwidth is more constrained on the server side.  That's how my typical client/server (non gaming) applications have gone.  I don't care about increasing bandwidth usage on the client, in fact I want to do that to take load off the server.  That's the whole point.  My clients should have plenty of room to send messages to all the other participants in addition to their conversation with the server for game synchronization.  Maybe I'm missing something.

The plan is to make it a configuration option if needed.  Default is client/server.  If voice commo bogs the server down configure it to use P2P for voice traffic and see if that helps.  P2P is just a different perspective on client/server and if you've designed in the proper points of control, it's just configuration as to where your server(s) is.
bwarren said:

I'm operating under the assumption that bandwidth is more constrained on the server side.


That is typically a bad assumption to make.  By definition the server should have significantly more bandwidth and more power than the clients do.  Further, you don't know what the clients are running and though tempting to make the assumption that clients have powerful machines and lots of bandwidth that is typically not the case.  Now, I'm sure you're immediately disagreeing with the "typically" remark, so let me explain.  The majority of ISPs provide large pipes for download, but upload is significantly limited even on the best home networks.  This typically isn't a problem when playing games over the network because the server is responsible for primarily "sending" information and the client is primarily responsible for "receiving" so having a large upstream isn't a big deal.  However, if you go to the P2P approach you are now changing that to push significantly more uploading occurring from the clients that cannot scale to the level that servers are made to.

Finally, having a configuration option to choose between P2P and Client/Server sounds really cool from the outside, but I wouldn't want to be the one that has to program the logic to switch between them in my game. ;)
darkfrog said:

bwarren said:

I'm operating under the assumption that bandwidth is more constrained on the server side.


That is typically a bad assumption to make.  By definition the server should have significantly more bandwidth and more power than the clients do.  Further, you don't know what the clients are running and though tempting to make the assumption that clients have powerful machines and lots of bandwidth that is typically not the case.  Now, I'm sure you're immediately disagreeing with the "typically" remark, so let me explain.  The majority of ISPs provide large pipes for download, but upload is significantly limited even on the best home networks.  This typically isn't a problem when playing games over the network because the server is responsible for primarily "sending" information and the client is primarily responsible for "receiving" so having a large upstream isn't a big deal.  However, if you go to the P2P approach you are now changing that to push significantly more uploading occurring from the clients that cannot scale to the level that servers are made to.


"The majority of ISPs provide large pipes for download, but upload is significantly limited even on the best home networks."

That turned on my "DUH!" light.

Point taken.  I hadn't thought about that aspect of it.  My P2P development was with corporate apps on LANs and WANs, not home users dealing with ISP throttling.  I was thinking I was missing something and there it would be.  A corporate IT monkey not recognizing the home user environment's differences in connectivity.  I was just thinking about firewall and NAT configuration issues.

I was having a hard time believing that someone involved in development of something like JGN would have unfounded religious issues with P2P.  Makes a lot more sense now.


Finally, having a configuration option to choose between P2P and Client/Server sounds really cool from the outside, but I wouldn't want to be the one that has to program the logic to switch between them in my game. ;)


I'm not afraid of that part.  I've done something similar in non-gaming applications and it worked pretty well.  It's actually a pretty interesting design problem.  Note that I said "design problem" there.  The code doesn't become significantly more complex because of it, at least not in my experience.

Again, I think you're not taking into account the "game" aspects here.  The "rules" changes significantly in networking between P2P and Client/Server in various ways. The biggest thing to handle is "cheating".  P2P and Client/Server are completely different in how these things should be handled.  If you're simply talking about VOIP then it's not such a big deal (although an exploit to allow you to anyone at any time could be bad).



If you're still interested in such an endeavor if you're interested in contributing to the community you might consider writing it for JGN and it could be released in the project.