Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Have I adaquatly described BULLET?  (Read 12272 times)
0 Members and 1 Guest are viewing this topic.
Offline Jeff

JGO Coder




Got any cats?


« Posted 2006-02-12 21:26:40 »

I happend on an old thread and noticed that BB had asked me some time ago to describe BULLET and how we used a combination of TCP and UDP at TEN to get what at the time was measurably the best Quake2 play on the internet.

Did I answer that question well enough or should I write something up now?

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sunsett

Senior Duke




ribbit!


« Reply #1 - Posted 2006-02-12 22:09:42 »

I would be very interested in an explanation as I'm trying to write the best game networking API for Java and am currently in the last stages of adding joint TCP/UDP support for the client/server architecture.

-Matt Hicks
Offline Jeff

JGO Coder




Got any cats?


« Reply #2 - Posted 2006-02-13 01:04:50 »

Okay.  This si from memory but...

B.U.L.L.E.T. or Bills Ultimatew Latency Lage Elmination Technology worked as follows.

Background Information:
In order to understand BULLET you have to understand a tiny bit about TCP/IP.  The first thing to realzie is that, under *normal* conditions, TCP and UDP perform almost identically.  The difference in behavior, and thus performance, is when a packet is lost en-route.  UDP just ignores it and keeps flowing the packets-- the data is lost.  TCP/IP stops the flow of pacekts and sends a packet back asking for a re-transmirt of the lsot data.  Because TCP gaurantees in-order delivery it cannot deliver the later packets until it gets that lost one so it queues them up. The result is a latency spike and then a whole bunch of packets being delievered one right after the other.

What BULLET did was to cover that latency spike with a second channel of data.  In addition to sending the packets via TCP, they were collected and periodically sent as a "window" of packets in a UDP channel.  We found it was fairly rare for BOTH the TCP and the relevent UDP packet to be lost at the same time. So if the UDP packet arrives with packets that the TCP channel hasnt delivered yet, we just continue the flow by sending those to the client.  When the blocked up TCP does arrrive, we throw away the already seen packets.

Because order is not gauranteed in UDP its possible we mkight recieve the "windows" out of order. We handle this by locally storing any "future" windows until we've passed through their packets.

Obviosuly we cant use the TCP layer's packet numbering for this ebcause its not exposed to us, so all these packets have a few bytes of packet nukmber pre-pended before they are sent.

We found that this radically reduced the ocassional laytency spikes you see in TCP and which caused us so much grief in gameplay.

It was preferrable in our judgement to a pure UDP reliability scheme for two reasons:

(1) For various reasons, the network-layer-level TCP has advantages over an attempt to do the same thing at the user level.  For instance,  internet routers can reckognize TCP packets and thus give them priority over UDP packets when the router backs up.

(2) Its not reinventing the wheel.  TCP was already there so why take the extra cost and added bugs-risk of building reliable in order delivery ourselves out of UDP?



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sunsett

Senior Duke




ribbit!


« Reply #3 - Posted 2006-02-13 01:57:15 »

Very nice.  Is this an open-source project I can cannabalize for parts....*cough* I mean look at exactly how you did this? :-p

Aren't you essentially sending all the same information twice?  Once through UDP and once through TCP?  Isn't that a large waste of bandwidth?

I actually ended up at the same conclusion, albeit further down the road.  I realized that UDP had significant advantages over TCP for latency and speed but there is also the need for reliability in many cases as well.  I ended up writing that "user-level" reliable UDP and it works actually quite well but it's significantly slower than TCP for obvious reasons when a message is undelivered.  Now, I've gone ahead with JGN and added support for both TCP and UDP and a CertifiedMessage sent through UDP is guaranteed deliverable because of the implementation how it handles it, but that same exact message can be sent over TCP and all the "CertifiedMessage" aspects are completely ignored and just relies on the features of TCP.

I would be very interested in a critique of my API as I'm sure you have a lot more insight to the concept.

BTW, I noticed a strange problem that started popping up when I would receive a message via a Datagram and would get the InetAddress of origination from it and then would try to use that to send a message back via TCP (on a different port - the correct TCP port for the remote server) and it would say "Protocol not supported".  Have you ever run into this?  I ended up having to create a work-around that simply:

1  
2  
byte[] addy = address.getAddress();
address = InetAddress.getByAddress(addy);


Then it would work just fine.  It may also explicitly have something to do with both client and server being on the same machine.

-Matt Hicks
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #4 - Posted 2006-02-13 12:59:12 »

For my networking system was designed to save bandwidth at all means, I cannot like that idea.
I dislike the need of an additional int to be send just for packet identification (although sending everything twice is worse, of course Smiley ).

But there are other things I don't feel comfortable with:

  • The size and periodicy of that 'window' is rather arbitrary. Good points when to transmit that window are ahrd to find? (Compare to Socket#setTcpNoDelay())
  • Can be counterproductive: doesn't the packetloss rate depend on load? Thus the redundant UDP packets may cause the loss they try to hide.
  • Not an algorithm, just stochastics. On networks with 90% UDP packetloss it won't help very much .... just causing overhead.

What were the environments BULLET worked on?


 

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline sunsett

Senior Duke




ribbit!


« Reply #5 - Posted 2006-02-13 14:17:01 »

Herkules,

I would say you're an extremist though. :-p  Bandwidth must sometimes be minimally sacrificed to a greater purpose.

For networked games cannot live by bandwidth alone. :-p

-Matt Hicks
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #6 - Posted 2006-02-13 16:04:14 »

By no means. I just started this networking thing when 14.4k modems have been common. Every byte is sacred.
But even today, upstream bandwidth on DSL lines still is poor. And thats what counts for a 'casual server'.

numplayers = k * (bandwidth/messagesize)    ....  this holds today and forever

And I'm still a believer that the battles are lost and won on higher levels, e.g. gameplay first, smart update/distribuition schemes and proper factoring next. Not on the lowest network protocols.

And I don't like probability in computation.

And I have seen networks (LAN!) dropping 90% UDP.

And I've seen projects being delayed for month bc. somebody said 'UDP is faster' and after that failed to deal with all these buffers, threads, locks, timeouts, states, re-sends, overlaps, .... necessary to make the thing work reliably.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #7 - Posted 2006-02-13 16:15:00 »

BTW, I noticed a strange problem that started popping up when I would receive a message via a Datagram and would get the InetAddress of origination from it and then would try to use that to send a message back via TCP (on a different port - the correct TCP port for the remote server) and it would say "Protocol not supported".  Have you ever run into this?  I ended up having to create a work-around that simply:

1  
2  
byte[] addy = address.getAddress();
address = InetAddress.getByAddress(addy);


I'd suppose the InetAddress object retrieved from a datagram is of a special subclass of InetAddress which contains information about the protocol. Or InetAddress carries this information with it. InetAddress is quite a complex object.....

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline kevglass

JGO Kernel


Medals: 188
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2006-02-13 16:40:01 »

I'm with Herk here. I'm quite surprised that adding a UDP in conjunction with the TCP improved things:

1) If you throw out a whole bunch of UDP packets onto the line the TCP algorithm is going to do what its designed to do - detect load (according to the TCP RFC the algorithm is designed to work across mimimal connections) - and then back off  - adding the UDP would probably cause the TCP to backoff and increase the window size more often - which in turn would cause the detection of lost packets to be detected less often - and hence the lag spikes would be increased.

2) The UDP data you recieve might be useful but you can't then (especially from java) go diving down into the TCP stack to tell it that you've actually got the bits of data its been waiting for and hence the TCP is still lag spiking over and over - does your UDP stream ever get synced again? Of course this would be case except for...

3) As you said, TCP and UDP perfom pretty similarlly on a lossless connection. So, if you start getting gaps in your TCP stream then its because you're losing packets (or some nasty router has stripped them because they're not "priority"). If you're losing packets you'll lose UDP too.. its just you won't loss the requests for resends sent the other way. Seems like a very slim improvement (although one I've found quite useful so far)

However, given this is Jeff we're talking about I'm pretty sure this is anecdotal performance figures and hence this definitely did give improvements. So, could you give us some more details in the environment where this improved things. Were there dial up lines involved alot? (TCP header compression?) Was this quite a while ago (before routers bothered looking at UDP packets enroute)?

Bandwidth/Network performance is the same as Grapihcs Performance - the more performance you've got, the more other things you can put in (of course theres a trade off here for time in development). However, if we were talking about networked physics for instance - I'd want all the room I could get Smiley

Kev

Offline sunsett

Senior Duke




ribbit!


« Reply #9 - Posted 2006-02-13 17:35:06 »

Speaking of networked physics...  Roll Eyes

I'll be putting up a new release of my networked physics API as soon as JGN 1.05 is released.  JGN 1.05 will offer complete support for TCP and UDP, time synchronization, and P2P.  The new release of the PhysicsNetworking API sends all physics messages over UDP and any player information (join, chat, disconnect, status change, etc) goes through TCP.  It works quite well.  I've got Roll-A-Rama (my PhysicsNetworking demo game) using all the new features and it's working quite well on my LAN. Wink

Herkules, the basic content of a Message in JGN consists of a short (message type) and two longs (message id and time sent - this will be adjusted when time sync to be the time sent on the remote machine that is receiving it).  Even peaking the number of messages I'm able to send over the network because of software performance (over 2,000 sec) that won't even put a dent in standard DSL bandwidth. Shocked  Now, definitely I agree that bandwidth minimization is beneficial, but I gain several advantages by sending that information across that could be sacrificed, but I think the advantages outweigh the disadvangtages.

I agree that InetAddress is a complex object but you wouldn't think it should have any ties to the protocol.  That just seems wrong. Shocked

I'm still hoping one of you networking elites will give me some good constructive feedback: http://javagamenetworking.dev.java.net  Wink

-Matt Hicks
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #10 - Posted 2006-02-13 18:19:50 »

Herkules, the basic content of a Message in JGN consists of a short (message type) and two longs (message id and time sent - this will be adjusted when time sync to be the time sent on the remote machine that is receiving it).  Even peaking the number of messages I'm able to send over the network because of software performance (over 2,000 sec) that won't even put a dent in standard DSL bandwidth. Shocked  Now, definitely I agree that bandwidth minimization is beneficial, but I gain several advantages by sending that information across that could be sacrificed, but I think the advantages outweigh the disadvangtages.

?

2xlong+1xshort = 18byte
+ 20byte UDP = 38byte

*2000/s = 76000byte/s

Thats a multiple of a common DSL upstream and at least 5x overcommits the usable capacity.  For now just with overhead.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline sunsett

Senior Duke




ribbit!


« Reply #11 - Posted 2006-02-13 18:43:21 »

Though I haven't confirmed your "+20bytes for anything UDP" that is not entirely accurate for my system as it allows multiple messages to be sent in a single packet which even if what you say is true would significantly reduce the amount of data being passed through the pipe.

-Matt Hicks
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #12 - Posted 2006-02-13 19:11:05 »

http://www.networksorcery.com/enp/protocol/udp.htm

Where does this 2000 come from?


I benchmarked HQ message sending a bit. Sending + decoding empty messages leads to ~20000/s using the loopback TCP line and ~300000/s using HQs 'local' setup (which just copies bytebuffers) on my poor notebook. I'm pretty sure profiling the network case would show that logging eats up the time.   

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Jeff

JGO Coder




Got any cats?


« Reply #13 - Posted 2006-02-13 20:54:22 »

Very nice.  Is this an open-source project I can cannabalize for parts....*cough* I mean look at exactly how you did this? :-p

Nope sorry, it was a TEN propriatary thing, which is now wholly owned by EA along with the rest of the TEN/POGO.  In fact AFAIk this is the first time its been really descibed publicly.  Its so old now,though, and I've seen enough thinsg out there that are simialr enough, that I figure Im not doing any great harm by discussing it.

Quote
Aren't you essentially sending all the same information twice?  Once through UDP and once through TCP?  Isn't that a large waste of bandwidth?

yes indeed.  The tradeoff is bandwidth for reduced latency spiking. 

Quote
I would be very interested in a critique of my API as I'm sure you have a lot more insight to the concept

Im honored to be asked, but til GDC is past *I* have really limited bandwidth Sad

.
Quote
BTW, I noticed a strange problem that started popping up when I would receive a message via a Datagram and would get the InetAddress of origination from it and then would try to use that to send a message back via TCP (on a different port - the correct TCP port for the remote server) and it would say "Protocol not supported".  Have you ever run into this?  I ended up having to create a work-around that simply:

We actually just ran into something very similar in Project Darkstar.  In our case the behavior was unique to windows.  I believe one of my guys is going to file bug on it shortly...

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2006-02-13 20:59:27 »

For my networking system was designed to save bandwidth at all means, I cannot like that idea.
I dislike the need of an additional int to be send just for packet identification (although sending everything twice is worse, of course Smiley ).

But there are other things I don't feel comfortable with:

  • The size and periodicy of that 'window' is rather arbitrary. Good points when to transmit that window are ahrd to find? (Compare to Socket#setTcpNoDelay())
Its directly related to the worst spike you are willing to tolerate.

Quote
[li]Can be counterproductive: doesn't the packetloss rate depend on load? Thus the redundant UDP packets may cause the loss they try to hide.[/li]

Yes on the first half but not likely  on the scond.  It depends on the load at the router, which is concetrating a great many users' pacekts.  Just doublign your data isnt likely to impact that much.

Quote
[li]Not an algorithm, just stochastics. On networks with 90% UDP packetloss it won't help very much .... just causing overhead.[/li]
[/list]

true.  We didnt find that sort of behavior on the networks TEN worked on which wer egenrally of pretty high grade.  Most of our users were dialup which meant we had some control of the netwrk from connection point in.

Quote
What were the environments BULLET worked on?

The TEN network.  I dont remember the statistics but probably mreo then 50% of our users used the dial-ins we provided, which were supplied by Concetric.  TEN itself was tied pretty well into the backbone of the net.  We had both east and west serves AIR because at the time the MAE EAST/WEST bridge was a bottleneck.  We had multiple connectiosn to back bone points in order to get aroudn some of the other worst bottlenecks.

 
Quote

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sunsett

Senior Duke




ribbit!


« Reply #15 - Posted 2006-02-13 21:21:56 »

Quote from: Jeff
Im honored to be asked, but til GDC is past *I* have really limited bandwidth Sad

I have an easy solution, get JGN an invitation to GDC and I'd be happy to explain it in person. Wink  Speaking of which, I have been working on a networking demo utilizing Swing in jME, jME-Physics, PhysicsNetworking, JGN, Shadows, and other cool things hoping that jME would be invited to GDC and that jME would be willing to show it off.  Is there any word on this?  Wink

No worries, I'll bug you about it again after GDC.  Roll Eyes

I guess your premise in this API is the scenario that bandwidth is cheaper than lag.  For most broadband connected machines (which makes up the majority of the gaming community) I would suggest that's probably pretty accurate.  I guess the real potential problem lies in situations where a TCP message gets lagged and the UDP message never reaches its destination.  In that case you would still see a lag spike but hopefully minimized occurence.

-Matt Hicks
Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2006-02-14 00:15:55 »

On GDC, I'm sorry, but we are seriously limiting the demos we are showing this year.  The focus this year is very much on Project Darkstar.

I might be able to scam you an expo pass, but thats the most I could do this year.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sunsett

Senior Duke




ribbit!


« Reply #17 - Posted 2006-02-14 01:41:24 »

No problem, I'll just have to wait until next year...I'll have a lot more to show off then anyway. Wink

I bet a could write an implementation of BULLET (based on the info you've shared) in JGN relatively easily since it would just be a combined message queue with a UDP and TCP receiver that keep tabs on the messages so duplicates get dropped.... hmmm.  Shocked

I'll have to play around with that....it's so hard to test networking concepts because you need a crappy internet connection to test with. :-p

-Matt Hicks
Offline colesbury

Senior Newbie





« Reply #18 - Posted 2006-02-14 02:40:33 »

What's project Darkstar?

-Sam
Offline sunsett

Senior Duke




ribbit!


« Reply #19 - Posted 2006-02-14 04:53:27 »

...and colesbury was never seen or heard from again.  Cry
Offline thijs

Junior Duke




Lava games rock!


« Reply #20 - Posted 2006-02-14 15:25:19 »

Besides saving bandwidth, I don't get why people would like to use TCP for any *fast paced* action game. I know thats a bold statement given the amount of discussion on this and yes i've read through the whole TCP VS UDP thread. But hear me out Wink

Typically you'd have two kinds of messages in your game; ones that need to be send reliable and ones that you should fire and forget about. In most fast paced multiplayer action games, you typically have objects that are controlled by remote players but which behaviour is difficult to predict, be it because of a high degree of freedom in movement etc. To be able to make an accurate prediction as possible of their behavior, we need a high as possible update rate of their current state. We need to forget about resending a lost packet as these would already be outdated when they arrive, we need to go on. Unfortunatly thats impossible because the way TCP is built, so UDP is clearly needed for that purpose.

Of course we still have the need for reliable messages and TCP was build just for that purpose. I also agree TCP performs just as well in the same environment as UDP and does a better job at delivering reliable messages than any reliable UDP protocol ever could, because TCP is implemented in hardware. So you could go and built something that uses UDP for the highrate updates and TCP for reliable messages. But using TCP and UDP together has some potential problems:

  • TCP doesn’t work with the UDP NAT punch through technique.
  • In certain situations (typically on narrow channels like modems or a slow DSL uplink), TCP can interfere with the UDP protocol layer, causing jitter in receiving UDP packets.
  • Using two protocols forces you to make two different outgoing/incoming connections and handle two different types of incoming messages, which probably means you’ll have to design your game to take this in account. This point is more of a design question though.

Now, it's also possible to implement a reliable protocol using UDP. But this needs a solid design designing and massive amounts of testing to get working properly. Also using reliable UDP will probably give slightly less performance to TCP, but this is often not needed for the reliable messages and we'd talk about a very small amount here. But going with reliable UDP would prevent the all potential problems pointed out above. Also, there are already are some quite solid reliable UDP libraries around, even one ported to Java as I pointed out before (jEnet) which will save you this trouble.

Now I think this holds up only for games with fast interaction between players, TCP is probably a better choice when you don't need that (because the internet is mostly build around TCP like mentioned before). Herkules Flying guns is a very good example that even a flight simulator can be done using TCP, deadreckoning on the aircraft works quite well I guess as their motion is pretty limited?

Thijs

<a href="http://www.dzzd.net">3DzzD!</a>
<a href="http://www.arcazoid.com">Arcazoid!</a>
Offline sunsett

Senior Duke




ribbit!


« Reply #21 - Posted 2006-02-14 16:22:30 »

I agree thijs.  In fact, that's exactly the way JGN is built.  Roll Eyes

JGN now supports UDP and TCP as well as reliable UDP.  You've got the best of both worlds.  You can maintain a TCP and UDP connection internally and not have to worry about it, you can got straight UDP, straight TCP, or have several of each.  In fact, this was necessary for my PhysicsNetworking API which is built on top of JGN.  PhysicsMessages are sent via UDP but any player updates are sent over TCP.

-Matt Hicks
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #22 - Posted 2006-02-14 17:11:47 »

Herkules Flying guns is a very good example that even a flight simulator can be done using TCP, deadreckoning on the aircraft works quite well I guess as their motion is pretty limited?

I won't say limited ... it has steady derivatives, motivated by physics.

The WW1 flight sim theme was chosen with networking in mind. Besides having motions that can be predicted quite well it has many other advantages:

  • rel. Positions are hard to perceive exactly
  • shooting is not symmetric: the target has no clue wether the attackers position is excactly suitable for hitting. This gives easy (and 0-protocol) rules for this kind of interaction
  • few points where network artifacts get obvious (like gates or such)


Latency is not really an issue in FG.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline sunsett

Senior Duke




ribbit!


« Reply #23 - Posted 2006-02-14 17:34:32 »

How can latency not be an issue?  The dilema described by Jeff in reference to latency spikes due to TCP is always an issue if you have lag.  Do you have an internal method of ignoring messages that are too old?

darkfrog
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #24 - Posted 2006-02-14 20:06:15 »

Of course quality goes down with latency. The point is that in a networked environment, things are never exact. But in case of FG, things can stay believable over a wide range of latency. In the area of motion, you cannot tell wether a new position arrived 100ms earlier or later. This can easily be smoothed out.

In a properly setup HQ system, all stations share an understanding of time. Thus a client knows that some remote position/speed/force was established at a certain time and can do valid integration from there. The actual current position it computed due to older data is supposed to have only a limited error and smoothing out the diff can be carried out w/o the local user even noticing it.

In terms of shooting, machinegun bullets are very fast and it is impossible to avoid them. So if the local object is told that it was hit, it was hit, regardless wether that information is 100ms old. If I see a remote enemy starts shooting, I can see him shooting and again 100ms is not a delay I could determine even if my opponents screen is beside mine. If I had rockets or so, I'd take care their time-of-flight would be seconds ... far above my expected latency.

This e.g. is completely different in Quakes brute force networking where you cannot even move without a reply from the server. Combined with an unsteady motion, you can percieve every single millisecond of latency. Q3 therefor is hardly playable over the internet in a fashion you got used to on a LAN.

OTOH, games like WarBirds play well even with 200 players online and you cannot tell the difference to a LAN game (WarBirds is TCP BTW).

Do PONG .... don't try TRON  Smiley

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #25 - Posted 2006-02-14 20:09:04 »

This is getting a bit off-topic and I fear the moderators.....

Every single thread seems to end in the fruitless TCPvsUDP debate. This time, we ended somewhere else, hence not discussing BULLET any more. Shouldn't we start a new thread 'Gameplay issues in networking'?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Jeff

JGO Coder




Got any cats?


« Reply #26 - Posted 2006-02-14 20:56:18 »

How can latency not be an issue?  The dilema described by Jeff in reference to latency spikes due to TCP is always an issue if you have lag.  Do you have an internal method of ignoring messages that are too old?


All internet games have to deal with latency of one form or another.  You deal with it in your design to hide the latency.

As an example, the MMO demo Im writing for GDC right now does local motion and collision detection with an over-riding sanity check on the server to catch cheating.

Flighth sims actually have a huge amount of possible "slop" in the position.  if yo uare willing to let the one firing determine hit or miss in fact its possible to cover almost any amount of "lag".

Now letting the firing player determien hit or miss has cheat potential, but you can again do sanity checks on the serve to see if the result is "reasonable".





Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #27 - Posted 2006-02-14 21:25:37 »

Yes, FlyingGuns in fact is widely open for cheating.

But, OTOH, ... nobody ever tried and I'd be glad to find enough recognition that cheaters were attracted!

For FG is merely a tech project, I use simple, clean and minimal techniques and ignore all evil Smiley

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline sunsett

Senior Duke




ribbit!


« Reply #28 - Posted 2006-02-14 22:59:50 »

In the PhysicsNetworking API I wrote, the implementing game can supply their own implementation of the interface PhysicsServerSession for the server that has a isValidPhysics() that receives all the information on the message received from the player that should be applied to a physics object.  The implementing game simply defines its own checks within that and returns true if it's valid (then the server applies it and spawns it off to the other clients) or false if it's invalid (and rejects the physics message, sending back a message to that client with the correct position of that object).  This allows for handling of clients that have either gotten seriously out of sync, or clients that are trying to hack the game.

It's a pretty simple concept, don't deal with it myself, pass it off to the game to deal with. :-p

-Matt Hicks
Offline Jeff

JGO Coder




Got any cats?


« Reply #29 - Posted 2006-02-15 05:54:20 »

In the PhysicsNetworking API I wrote, the implementing game can supply their own implementation of the interface PhysicsServerSession for the server that has a isValidPhysics() that receives all the information on the message received from the player that should be applied to a physics object.
-Matt Hicks

In the end, the best dead reckoning (which is what this is called) always takes into account both the actual behavior of the obecjt in question and the ruekls of the game being played,.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

theagentd (20 views)
2014-10-25 15:46:29

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (46 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (69 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (74 views)
2014-10-11 23:24:42

BurntPizza (46 views)
2014-10-11 23:10:45
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!