BRAINSTORM ! - Going to make a network game

Networking & Multiplayer
#1

Please help me with ideas for a network game.

I am working on this page:
http://www.ryer.dk

  • I am gonna make a network game which should be available here.
  • It will be webstart executed, cus most ppls use Microsofts virtual machine in their browser which wont allow me to develope in Java 5.0.

Please brainstorm on the tagwall with game ideas, It may be realtime and turnbased games. If the game will be realtime I just have to tell ppl what port to open to listen to UDP incomming traffic.

Thanks in advance.

#2

As the page is in danish I will just have to tell you that…

NAVN means NAME

and

BESKED means MESSAGE

You write messages at the bottom right corner of the page.

#3

I liked your black cube and red circle game :slight_smile:

#4

Thankyou :slight_smile: Just finished Ping Pong i javascript too. check it out: www.ryer.dk. But I need an idea for a multiplayer network game which should be the big thing on my site.

#5

what about two player Pong? :-p

Check http://javagamenetworking.dev.java.net for your networking API. :wink:

-Matt Hicks

#6

TCP is too slow to handle 2 play realtime games alone. I would need to use UDP. So this wouldnt be possible from an applet.

#7

JGN is entirely UDP and it is possible from an Applet if it’s signed.

-Matt Hicks

#8

Sigh … :-\

#9

Sorry buddy. :o

I think TCP would be fully capable of doing most realtime games, it’s just the extremely fast-paced ones that would be a problem.

Give in to UDP…feel its power rushing through you! :stuck_out_tongue:

-Matt Hicks

#10

I agree sunset, TCP is capable of handling real time games.
Remember, the best is the ennemy of the good.

Danskeren, I am writing JNAG actually and I think that it may be ready soon (1 or 2 weeks) for you to use it. I would be happy to contribute to your projet and to have someone to help me to test my lib, so if you want we can work together on it, I can do the network part.

Karma.

#11

Well handled TCP is generally plenty fast. The only issue you need to handle is the ocassional latency spike, which can be covered by game design.

UDP is unreliable, and sooner or later you will find yourself ina corner where you need reliability. Att hat point you can go through the pain of reinventing TCP in UDP but in the user space rather then kernel space, which for a number of reasons is gauranteed to be inferior, OR you can start mixing TCP and UDP…

#12

I know UDP is unreliable but speed is above reliability when it comes to movements of the enemy. In a pong game, a half second delay on the enemy is a lot, and thats why I said TCP was not able to handle real time games.

If there were no firewalls and shit around I would combine the two protocols. UDP for the movements and TCP for all the things that is needed to be recieved by the other clients.

But UDP trafic is a pain in the a… when working across the internet I think. Lots of people have HW firewalls and are not able to play then.

#13

If you have 1/2 second latency on TCP, UDPs latency won’t be much lower. Thats no criteria.

But esp. for PONG … thats network paradise!! As soon as the ball leaves the opponentes batter (is that the word?), everything is predetermined maybe for seconds!!. So just send a (reliable, of course), timetamped message at this single point and you are fine. Pong is one of the best gameplays for latency hiding bc. of the long time the ball moves without being affected by the opponent.

Fast paced TRON e.g. is the opposite!

#14

How’s that:

Let the outgoing ball be a bit slower than the incoming. When you hit the ball, send a message about [when,where,direction]. On the other side of the net, the ball travels a bit faster (for it is ‘incoming’ there). So, when on your screen the ball reaches you opponents batter, his reaction (in form of a network message) might already have reached you!!

This way, latency can be completely hidden by gameplay!!

If the batter is moved by keyboard (haven’t seen the game, sorry): for batter movements, only send the ‘corner points’ where/when batter starts, stops or changes direction. Reliably of course, otherwise this won’t work. From this you can create a perfect track of the opponents batter.

With that, Pong should send only very, very few data which helps to keep latency and packetloss low and you can download a video while playing :).

And yes, a HUGE advantage of TCP is that internet routers and firewalls are used to it :slight_smile:

#15

hehe, don’t make a proclamation that TCP is better supported over firewalls, that just lunacy. :-p

I have to agree with Jeff. I’m facing that issue in JGN. I’ve essentially re-invented TCP inside UDP, which works great for the most part, but I know in the future being able to mix TCP and UDP is really what is going to be needed. I will probably update JGN eventually to remove CertifiedMessage and just offer the ability to create a TCPMessageServer or UDPMessageServer and whichever one you decide to send your messages through, they will be handled accordingly.

As for pong I would say the best way to handle networking there is to to just broadcast position of the paddle from each client and have a server component that is responsible for transmitting authoritative position of the ball. This way you are guaranteed reliable synchronization. Further, the best way for something like this is with UDP in my opinion because it can be the “fire and forget” mentality. If one gets missed it doesn’t matter because there’s another one right behind it. However, since there are only three things being tracked in pong (one per machine - paddle for each client and ball for the server) it could be done in TCP without any noticeable difference in performance.

JGN is easier to use though. :wink:

-Matt Hicks

#16

It’s true, the headers of TCP can be compressed to 2 bytes (!!) while UDP-packets have headers of around 30 bytes.

#17

I need to do some ethereal tests to verify that one. :-p

I was under the impression that the actual message might be small but there’s so much other stuff sent across with the TCP message that the overhead is drastically increased.

-Matt Hicks

#18

Even a simple game like Pong would suffer from latency. Yes a big part is deterministic; the ball motion. But the movement of opponents is not. Imagine the ball is heading for player 1’s goal. The motion of this ball can indeed be predicted by all players, but if player 2 hasn’t received an update from player 1’s bat it doesnt know if he made a goal or not. Especially with TCP latency spikes (packet loss, TCP stack waiting for a delayed msg to arrive…) this could happen. Depending on the update rate of the gamelogic / ball movement speed, it could just be so that a delay of 200ms ruins it. Would player 2 need to guess it was a goal, or would player 1 have been able to dodge it?

Not that using UDP will completely solve this… but UDP could be used to send periodical updates to the player pos…just fire and forget. And use TCP for reliable messages, or a reliable protocol on top of UDP. (There are some potential pitfalls combining the two protocols next to each other). But on the other hand developing your own reliable UDP protocol is tricky too. I’d recommend using a well tested reliable UDP protocol like jEnet. Using a reliable UDP protocol (one that actually works like it should, if its not done well it can easily end up less efficient than TCP) you could have control over what messages to send unreliable, reliable and/or in order.

Thijs

PS: I didn’t knew about the 2 byte compressed header size for TCP, hows that achieved?

EDIT: Ah I happend to read over Herkules explanation about tweaking the ball movement speed :slight_smile:
That could be a tweak in game design to overcome latency to some degree. The ball would have to catch up at some point though (as incoming for player 2 means outgoing for player 1 and are handled at different speeds for both) which will result in a speedup for the ball at player 1’s screen when it bounces back. If you’d want to keep the speeds contant, you could also determine the average latency and adjust the logic update rate / movement speeds to that.

#19

It’s called vonJacobsen compression and only holds for certain dialup, ppp,… protocols (no details avail.).
And I have 3 bytes in mind … anyway. I think it takes advantage of the fact that on point-to-point connections all the adress informations that make up the headers can be stored in a lookup bc. it is constant for a ‘connection’. And this logically only works for TCP, bc. a kind of ‘connection’ is needed.

The good news is that the poor, thin lines (modem,ISDN) typically allow for vJ where we really need it. On a LAN there aren’t any problems anyway…

#20

I looked at JeNet in the past but decide to start from scratch since it requires 1.5 and several third-party APIs. If they ever get around to releasing anything but beta1 I might look into it further. :-p

Hey Herkules, I’d like to know your thoughts about JGN. If I could sway you in the direction of JGN I’d be happy for your help in writing joint UDP and TCP support in the API. I would assume you’d agree that any good networking API is going to have to have support for both? Since you have a lot of experience with TCP and I have a lot of experience with UDP if we were to work together I would think that we could achieve that goal.

Just a thought. :wink:

-Matt Hicks