Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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
  ignore  |  Print  
  Send weapon fire in a phisic world  (Read 6938 times)
0 Members and 1 Guest are viewing this topic.
Offline blow

Senior Newbie





« Posted 2006-09-04 08:25:32 »

Hi all, im using UDP to send data client to server and viceversa, it works fine for send the position of players, but not for send fire data.
My game is like a "Worms" game, but not turned based, and the weapons can fire pretty fast.
When i fire, a bullet is created in scenario and it is managed from phisic.
Now im using this system:
CLIENT: when press fire button, if he can fire he send fire data to server(type of weapons and angle of fire).
SERVER:receive data and send it at all clients.
CLIENT:receive data from server and if there are any fire action process it whit data(type of weapaons and angle of fire).

The problem is that i can lose some packet, and so some client have a bullet and some client nothing.This is a big problem becouse my world is destroyed under the fire!(like worms).
Another problem is latency, the position of player is process in local but the fire is process whit latency, so if i fire and move my player, i can see my bullet fire bheind me!
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2006-09-04 09:40:44 »

for reliable fire you either have to build a layer on top of UDP that kinda does what TCP does, or just use TCP in the first place.

As for the latency, welcome to the club, we're all dealing with it, and you basicly have to decide whether you want to live with it, or invent a smart system that works around the issue in some clever way.

Search the forums a bit, as this topic is discussed quite regularly.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline blow

Senior Newbie





« Reply #2 - Posted 2006-09-04 09:51:51 »

Thank for reply!

Another question, whit UDP protocol what is the best way to send data every time?
Example, i have to send player position, so the client send him position at server each gameLopp cycle(whit 60 fps, the time of loop is 16ms), and server can:
1) send data at all clients as soon as receive data from a client,
2) when receive data from client store it in an array and after a period send array at all clients
Whit first system the byte to send is few(32 byte) but this data have to send every time, whit second system the byte depend on number of clients connected but it can be send whit pause period(for example every 30 ms).

What is the best way?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sunsett

Senior Devvie




ribbit!


« Reply #3 - Posted 2006-09-05 17:28:49 »

Ouch, sending an update every game cycle is a really bad idea.  In fact, for simplicity it might be a good idea to create a separate loop in another thread that handles sending of updates.  I've got a system that handles this (in the game loop or in its own thread) in JGN as well as support for reliable UDP if you're interested:

http://javagamenetworking.dev.java.net

If nothing else it might be something to look at to get some ideas for your implementation.
Offline Kova

Senior Devvie





« Reply #4 - Posted 2006-09-05 21:38:51 »

don't know about UDP, but for TCP I think max number of messages you can send is 10 per second. Beyond that TCP starts to merge them ... at least in my case. I'm strugeling about it also, so far I got to this: record every events in game in past few frames (my game is 60 fps, so thats for past ~6 fps if sending 10 msgs in a sec), then send that to server, server then starts to process those events. This methed enforces lag, but it's the most precise one I could find searching the forum / net. Now I'm stuck with how to ping problem since TCP merges packets which couses delay and incorrect latency time reported... bah I'll soon ask for help about this surely.
Offline sunsett

Senior Devvie




ribbit!


« Reply #5 - Posted 2006-09-05 23:03:17 »

Simply disable that feature:

1  
channel.socket().setTcpNoDelay(true);


And then you can manage merging yourself.  At least that's what I do in JGN.  Messages are queued up and then when update is called messages are merged together to form optimal packet sizes to be sent out and then pieced back together similarly on the other side.  This keeps the painful lag from occurring yet does not sacrifice the efficiency the feature was intended for.
Offline blow

Senior Newbie





« Reply #6 - Posted 2006-09-06 07:55:50 »

So the best way is send data only when occour an update? the problem is that in my game there are always update...so i have to send data every cycle game...

If i send only 10 messages for second, animation arent' smootly, or not?
Offline blow

Senior Newbie





« Reply #7 - Posted 2006-09-06 08:33:42 »

My problem i think is the bandwith...to send player position and situation i have to send an object of 150 bytes.
To send fire action i have to send an object whit 130 bytes.
Becouse the player situation change every game cycle, and there are often a fire action, i have to send a lot of bytes every time...
Offline sunsett

Senior Devvie




ribbit!


« Reply #8 - Posted 2006-09-06 11:12:30 »

That's a lot of bytes for a simple update....why so much?

I send 3D synchronization data with physics synchronization in a game I did not too long ago and it wasn't nearly that much data and was synchronizing more than 10 times per second.  In JGN there is an Updater class that allows you to specify how frequently you want synchronization data to be sent, so it essentially removes all the complexity of things such as this.
Offline blow

Senior Newbie





« Reply #9 - Posted 2006-09-06 11:33:39 »

I cant use JGN, i can only use native sun libreries...

My packets size is so bigger becouse its are a serialized object, so i take a lot of bytes...

I dont understand...if i send data only 10-20 time for second, i can see a player in a wrong positon, so if i see a player in a worng position i can fire to kill he but i cant kill becouse its arent' here!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sunsett

Senior Devvie




ribbit!


« Reply #10 - Posted 2006-09-06 12:24:47 »

Look up "dead reckoning" that helps somewhat with that.

Generally speaking it's just the inacting of Newton's first law:

Quote
An object at rest tends to stay at rest and an object in motion tends to stay in motion with the same speed and in the same direction unless acted upon by an unbalanced force.

So if an object is moving at a certain direction at a certain speed if there is a delay in receiving an update from the server it will continue in that direction at the speed since it is most likely that it will continue like that.  If you've ever had connection problems with Battlefield 2 it's pretty interesting to see that tank that was rolling towards you keep going despite mountains, buildings, etc. in the way.
Offline blow

Senior Newbie





« Reply #11 - Posted 2006-09-06 12:56:10 »

mmm but i think dead reckoning is no good for my game, look this:
Click to Play


My game is 2d action game, in this situation if the client(Player) press foreward the player move at direction.
So i see the player move, but if the client stop to press foreward but i have untill receive the update i see player move again foreward!
So i will see player in the wrong position,impossible for my game!
Offline Kova

Senior Devvie





« Reply #12 - Posted 2006-09-06 13:05:03 »

about bandwith, serialized objects take much more space then just raw data they contain. I use NIO and only send data I need (x pos, y pos, speed and such) in ByteBuffer and it dosen't take much bandwith, 4B for single Integer or Float, 2B for Short... When your data arrives you can create object you need with them.

So since you cannot send message every frame your problem is what to do between messages. As sunsett said, you can try to simulate movement until next message arrives and then correct mistakes. This is hard to do good (I tried) since player can quickly change direction and speed between updates so when his message arrives at server correction is clearly visible. You can develop that further to make correction not visible but that is hard, I went for simpler way and implemented forced lag I mention earlier so everything stays smooth and correct.
About collision and such, you'll need to do actual collision on just server becouse client can simulate wrong data and make a fake collision or something similar, I've done it so the server process all collision and sends them to client which then applies it. You can also make visual collision on client but not do actual calculations of stuff until server confirms it. All this is game dependat and you must find the best way to solve it.

@sunsett
tnx for that tcp method... I thought merging in TCP is low level, TCP protocol controlled and that you can't control it even in native code. Maybe I manage to fix my data laging now.

EDIT:
about your picture blow, that could never happen if you write good code
Let's see, client starts to move forward towards the hill and sends a message with his info, server recieves the message and starts to move the local client towards the hill. Lets say next message dosen't arrive before local client reaches the hill. As server moves local client towards the hill it gets collided with the hill and server stops moving it. So on both client and server you can preserve terrain collision. Remember your player on server isn't just a image, it's an real object just as much as on client's machine.
Offline blow

Senior Newbie





« Reply #13 - Posted 2006-09-06 13:20:42 »

Yes server can stop player, but i cant see the rela player position too...i see player stopped before hill but in rela player is on the hill!

I dont say this for the lag, becouse a lag is a real problem, but for update time, if im update my postion 20 time per second there a lot of delay from update to update...
Offline sunsett

Senior Devvie




ribbit!


« Reply #14 - Posted 2006-09-06 15:47:21 »

20 times a second is a LOT of updates....if you're seeing "delay" then you're not actually receiving updates 20 times per second.....I can update 5 times per second and only be moderately choppy....one of the JGN demos does that.  Feel free to try it out and crank up the updates to 20 times per second and I guarantee you won't be able to see any delays.
Offline blow

Senior Newbie





« Reply #15 - Posted 2006-09-06 16:06:05 »

Thank guy, now i write something to try this system.
Thank again.
Offline Kova

Senior Devvie





« Reply #16 - Posted 2006-09-06 16:11:20 »

@sunsett
5 updates per second is 200ms pause, your game must be slow paced if it's hardly noticable. On the other hand I have 2d soccer game, player can move fast in every direction so it's noticable even in 10 ups, but only noticable (ugly to see player receving corrections of few pixels in x and y).

@blow
you missed the point... if on server player must go up, he wil go up. Same as on the client. He's not ghost, sending direction dosen't mean where his image should be drawn, it's the same as you control your player on client machine but you use keyboard and player on server uses messages he got from client. When you press forward your player will go forward, if the reaches the hill he will go forward climbing the hill... messages will come to player on server that he must go forward, he will also reach the hill and also climb the hill as a normal player would. Remember, he's not a image or ghost, he's your muppet on some other computer and acts like you do on your computer, just receives commands differently.

EDIT: good luck with implementation, it will take you time to learn it and tweak it though
Offline sunsett

Senior Devvie




ribbit!


« Reply #17 - Posted 2006-09-06 17:28:27 »

Okay, so maybe "hardly noticeable" was an exageration, but it opens two JFrames with a box on each side and when one window is focused you can use the keyboard to move around the box and vice-versa.  It's just a simple example of doing updates and I simply opted to do fewer updates so you can see them occur visually.

Feel free to bump it up to 1,000 if you want....it will take it. Smiley
Offline blow

Senior Newbie





« Reply #18 - Posted 2006-09-07 13:36:06 »

Another thing, for player i have understand that both client and server can move it and detect its collision, but for the bullets? Bullets can move very very very fast, and i can fire 20-30 bullet for second(think machine gun) how can i render all bullets in local client and how can detect his collision accurately in all clients at the same manner?
I think is impossible send for each bullet its postion,direction and speed... so how can i say at all clients where are bullets?
Offline JAW

Senior Devvie


Medals: 2



« Reply #19 - Posted 2006-09-07 14:44:47 »

There is something I read yesterday in Game Programming Gems 3 (its 3 I think) about networking.

1) Use TCP if you need packets to arrive and dont send redundant data.
Current position, direction and speed is redundant. You send that every now and then, so if one drops it doesnt matter But this only applies in shooters where you move single entities.
If you send unique data like "shot from x direction d", you need it to arrive, so use TCP.
If you send positions of shots every update, it doesnt matter  if it drops, youll send an update next frame.

2) Only what the server says is real is real to the players. So if anything shoots, it sends a message "i shot direction d" to the server. The server replies ok or not ok. In the meantime, the shot is displayed but is "unofficial". If the shot gets denied, it disappears. If values like position are corrected, it warps. The server decides if it hits and does damage.

Consequences:
- Sometimes things might jump, when the server replies different than the client simulates, but we speek of maybe a few hundred ms. The jump wouldnt be too big depending on speed. The time between player input and server correction is less than 1 sec, usually.
- Events like damage appear delayed. You might have notet this in multiplayer RTS already, that a unit losses HPs half a second after an attack hit.Sometimes units even die with latency.

-JAW
Offline blow

Senior Newbie





« Reply #20 - Posted 2006-09-07 16:17:22 »

mmm so i have to use tcp to send bullet packet data? Im prefer use only UDP it isn't possible?
Anyway, look this gif, this gif illustre my trouble:
In local my player is moving as soon as im press FOREWARD, but in server side this event is noticed whit 200 ms delay so the player move after this time.
When i relased the FOREWARD button in local my player stopping to move, but now my ping is 250 so in server this event is noticed whit 250 ms delay and so the player stopping to move after this time.
The porblem is that now server situation and client situation dont coincide.
Click to Play


But if i dont move my player in local, i see my player move after ping delay, and i think this is very bad and make unfeeling game sensation.
So how can i solve this prob?
Offline blow

Senior Newbie





« Reply #21 - Posted 2006-09-07 16:26:47 »

There is something I read yesterday in Game Programming Gems 3 (its 3 I think) about networking.

1) Use TCP if you need packets to arrive and dont send redundant data.
Current position, direction and speed is redundant. You send that every now and then, so if one drops it doesnt matter But this only applies in shooters where you move single entities.
If you send unique data like "shot from x direction d", you need it to arrive, so use TCP.
If you send positions of shots every update, it doesnt matter  if it drops, youll send an update next frame.


So if im decide to send only start fire position and direction i have to use TCP so ima sure that message arrive at server, but if im decide to send bullet position, direction and speed each update i have to use UDP, it s true?

Quote
2) Only what the server says is real is real to the players. So if anything shoots, it sends a message "i shot direction d" to the server. The server replies ok or not ok. In the meantime, the shot is displayed but is "unofficial". If the shot gets denied, it disappears. If values like position are corrected, it warps. The server decides if it hits and does damage.

Consequences:
- Sometimes things might jump, when the server replies different than the client simulates, but we speek of maybe a few hundred ms. The jump wouldnt be too big depending on speed. The time between player input and server correction is less than 1 sec, usually.
- Events like damage appear delayed. You might have notet this in multiplayer RTS already, that a unit losses HPs half a second after an attack hit.Sometimes units even die with latency.

-JAW
Why i have to do this?
Offline Kova

Senior Devvie





« Reply #22 - Posted 2006-09-07 16:51:27 »

blow, you're assuming you 250 ping wich is terrible ping... on servers in my local country I have ~50ms. I see your illustrated problem, but as JAW mentioned, corrections on simulated movement are very small. In your animation guy moves 2m more then it should, this can't happen if you send messages frequently.
Furthermore, don't confuse ping with network ups, not the same. If you have high ping, your messages will all arrive to server but reaction time they are applied will be large. Correction you need to do after appying simulation dosen't depends on ping (theoreticly), but on network ups (messages you send to server in a second). If you send 10 ups (100ms pause), your simulation will only be wrong for maximum 100ms (case where message is sent and exactly after client changes direction or something).

About TCP vs UDP, when I researched for my game what to use I've noticed that reliability is very important and that you'll eventually need it. People that started off with UDP were frequently upgraded it to be reliable in which case they should use TCP straight away. Also I didn't came across any example where UDP is faster then TCP, seems it is just mentioned theoretically that it could be faster. I would recommend TCP.

About your shots problem... I don't have a clue how to deal with that, but you may ask CommanderKeith, he made SGS, a small 2D game with a lot of shooting and it's working fine.
Offline JAW

Senior Devvie


Medals: 2



« Reply #23 - Posted 2006-09-08 11:25:47 »

You need interpolation or simulation of entities. And you need synchronized timers.

The server runs the timer, clients copy the timer. Server sends a timer update to all clients from time to time to keep them close to sync. Best would be to take into account the latency. Have the server send a package with his current timer time to the client and the client sends it back. The server can read the time value and compare to his current time and calculate a clients latency. Take that latency into account when syncing timers. When the server sends a sync which takes 100 ms to travel to the client, you must add 100 ms to the timer value to really be in sync with server time.

Now you can operate on each client based on server time. Each client runs a simulation of what happens on the server. And clients fill gaps of time.

A server would send a message "unit U is in position x,y with direction d and speed v at time t". The client can then
- save this position as reference position
- every frame calculate a current position based on direction and speed and time elapsed since recieving the reference position

Easy example, an entity is at position 10, 10 at a server time of 1000ms, moving right (east) at 10 per second, making it 1 per 100 ms.

The client recieves the information at a time of 1200ms, he saves the reference 10,10 at 1000ms, heading right with 10 per second.
Elapsed time is 200ms, so the position offset is 2. The client draws the entity at 12,10.
He does so until he recieves a new reference information.

Ideally, the new reference information is perfectly in sync. But it is possible, that the information differes. Perhaps the unit did stop or change direction. So the current display position and the real server side position differ. Dont matter, discard the current position and use the new reference.

Consequence is, that the unit "jumps" because the client simulates it too far into a wrong direction, because he didnt know that the unit stopped or changed direction. When he gets the new information, he just corrects things by jumping / warping the units to their correct position.

In fact this doesnt matter. The differences in position are usually minimal, a few pixels. And there is the chance that the player doesnt even see affected units, because his screen position is somewhere else.

The same way damage can apply "in the past". Client 1 sends an attack against a unit of Client 2. It takes 200 ms to the server, he calculates damage and sends it to Client 2. It travels another 200 ms. As effect, the damage arrives 400 ms later than it actually happens.

The great trick is to keep things in sync there. Imagine the unit of Client 2 dies by the damage. But the information travels 400 ms, and in the meantime, the unit does an attack and damages another unit. In fact, this would be impossible, because the unit is already dead, but Client2 doesnt know it yet. So when the server recieves the message that the unit wants do deal damage, the server needs to know, that the unit already died and thus ignore any damage done later.


The message of the article I read, which I can only confirm, is, that when you need a controlled communication, use TCP, do not use UDP and implement an own layer of transport control.

Network playing is no easy topic. You should look for some articles about this. If you have only local networks and few entites, you can allow some errors and asyncs. If you plan to use many entites like in an RTS and if you have high latency connections, you need strong synchronization algorithms and a strong server to perform the extra computation or a dedicated server.


Tell us about your game. If you use shots as objects which travel, send position and speed over UDP. If you use shots as instant effect actions, and insist on using UDP, give each shot a unique ID and let a client confirm if he got the information. While you have no confirmation, continue to send this shot to all clients that didnt confirm yet.

-JAW
Offline blow

Senior Newbie





« Reply #24 - Posted 2006-09-08 12:59:44 »

Ok i have understand i think, that one you say is to draw a player opponent, its true?
My game is a 2D fast action game, like "Soldat", each player can move very fast and can fire a lot of bullet for second.Each bullet is a real object and it must be renderizable on screen of each client!
For my player, how i can send my message at server and what my message has to contain?
I have to send only key pressed?
How i can move my player as soon as im pressing a key, if i have to send this first at server, and olny when server answar at me i can move my player?
So, i have this question:
1)Im a client, when i want to move my player, what i have to send at server? Only key press? and why?
2)If to move my player i have to wait server answer, what can i see my player moving as soon as im pressing a key?
3)In my game there is often an update, i think each game tick, becouse i have to send player's arm position(it move whit mouse), so how often i have to send client data at server?
3)Server must send data at all clients as soon as receive a data from one client?

A small example:
Im a client,my player is in position x,y and i decide to move it right(east) whit 80pixel per second, so i press FOREWARD key for 1 second. In my local machine i move my player as soon as im press key, and i send this at server, so server can move my player server-side copy.
But when in my local machine my player is at position x+80,y (1 second is delayed) in server my player copy is at position x+80-ping_Time,y and when server send me a new position, is possible thta this position is back my local position, so my player jump back.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #25 - Posted 2006-09-08 13:25:58 »

There is something I read yesterday in Game Programming Gems 3 (its 3 I think) about networking.

1) Use TCP if you need packets to arrive and dont send redundant data.

No offence, but ... Don't. Just don't. Please. If you want to talk about TCP vs UDP, go to the thread that I stickied a couple of years ago, and *READ* it. Any posts by people who blatantly haven't read it (and, note, I've read it several times, so I'll KNOW if you haven't) will get deleted. We're not going to have any half-assed, ill-informed wars over it around here - one is enough Smiley.

malloc will be first against the wall when the revolution comes...
Offline Kova

Senior Devvie





« Reply #26 - Posted 2006-09-08 18:07:02 »

For my player, how i can send my message at server and what my message has to contain?
I have to send only key pressed?
1)Im a client, when i want to move my player, what i have to send at server? Only key press? and why?

Everything you need to for doing the same, identical thing on server. It's your game, you know best what makes objects moving.

How i can move my player as soon as im pressing a key, if i have to send this first at server, and olny when server answar at me i can move my player?
2)If to move my player i have to wait server answer, what can i see my player moving as soon as im pressing a key?

well that depens on what you want. You can do that, but in fast games you really need quick reactions so what you do is move client straight away and try to duplicate on server what your client does best as you can. So you don't correct your client with info you receive from server... no need to.

3)In my game there is often an update, i think each game tick, becouse i have to send player's arm position(it move whit mouse), so how often i have to send client data at server?

Yes, every game has an update each tick and every object is updatet with new values... Don't quite understand your question... you must send updates often enough to make it look good on the other side. You could send 2 updates in a second, but on other side it would look like player is warping and much of simulated data would be wrong (depends on game though). Best is to send often as you can, keeping in mind bandwith.

3)Server must send data at all clients as soon as receive a data from one client?

Again it depens on game, my server sends data to clients in fixed interval, 10 times a sec. If you want more precision you could send some data right away if it is important.
Example: moving in quake like game needs precision or you'll fall or something, so when simulating isn't very satisfying becouse when client stops server could stop somewhere else and then warp player on server back later where he actually stoped, clif edge for example. To improve this I've read that programmers send, besides normal messages in interval, a message to server when player stops.
Offline JAW

Senior Devvie


Medals: 2



« Reply #27 - Posted 2006-09-13 18:47:00 »

The TCP or UDP thread needs a conclusion or summary. Can anyone sum up this debate?

Its a question of some details and maybe even of what you like more.

Quote
1)Im a client, when i want to move my player, what i have to send at server? Only key press? and why?
2)If to move my player i have to wait server answer, what can i see my player moving as soon as im pressing a key?
3)In my game there is often an update, i think each game tick, becouse i have to send player's arm position(it move whit mouse), so how often i have to send client data at server?
4)Server must send data at all clients as soon as receive a data from one client?

1 & 2)
You can either send action requests and wait for a server confirmation or you just act and send that to the server. To keep gameplay smooth, you generally need to respond immediately, so move the player instantly. In both cases, the server can reply with allowed or denied and if action is denied the server needs to correct the result.

It depends a little on the nature of the game. For a fast action game with a lot of bullets, I would tell the server for each object position and velocity along each axis. It would be unusually that the server denies something, and correction is likely not to be noticed by the player. A player wont see when 1 of 20 bullets jumps 4 pixels or disappears after a collision.

3) You dont need to send everything every tick. You could:
- split work. Put all objects into a list and send 10 packets per tick. When the list is through, go back to the beginning.
- send only every x frames. 3 to 5 updates per seconds can be enough. A human player will not see it at all.
- send some things more often than others
Identify things that change often. Players change directions. Bullets are fast and so are likely to collide with something, so communicate collisions often. And you need to be sure that bullets are visibile for everyone, so send them often. If a packet drops, the next arrives soon. Send this 10 times per second or so. Other static things are less important. Crates destroyed, ammo or armor picked up, etc. Updating this 2 or 3 times a second is enough. The effect is, that an armor disappears at worst a half second later than it has actually been picked up. While you use UDP only, you can never be sure, if a information reaches the server or client. So if you send one "armor picked up" packet and it gets lost, the armor is still present for other players. Either send the armor status (present or not) every 500 ms or you need some confirmation response and send the information until you get a confirm.

4)
Depends on how your server is written. Probably it also has a game loop. So it might be like this
- get all incoming messages
- verfiy messages for correctness. Send denials to clients, ignore those.
- process messages, mark all objects that changes
- send changed informations to all clients



Do you encounter any specific problems? I would send everything, divided among several frames. Just a list of all objects which i process over and over. Every object gets updated every few frames. Its scalable because the ammount of updates is static, it just takes more frames for one object to update again. Maybe everything works. If it does not work, try to correct the problem. Is there too much network traffic, is there too much latency, or are clients out of sync? It is easier to handle a specific problem.

-JAW
Offline JAW

Senior Devvie


Medals: 2



« Reply #28 - Posted 2006-09-17 09:55:35 »

Hi

I just read another article dealing with RTS networking. It says that Dungeon Keeper used 4 "turns" per second and another fame used 6 "turns" per second. A turn is a complete exchange of information, that means, all clients send their new input to the server and the server sends all new informations to every client. The clients use interpolation to keep the visuals smooth until the next update. And interpolation in most cases isnt more than "guessing" where would the object be now, if nothing changed (if direction and speed stayed the same). Interpolation will not make decisions, so you dont decide that an object collides with another, you just make objects overlapping and wait for the server to send the collision. The server decides. Interpolation just moves the things around based on the information the client has.

For a RTS they use TCP in the article, because with TCP they can be sure, that messages do arrive and that they arrive in order. The network protocol relies on the fact that all clients are sure to get the same messages in the same order, so that all clients stay in sync. Using TCP you can develop a "fire and forget" mentality (well, send and forget), because you can be sure that your commincation arrives at the destination and in exactly the same order. This saves work for recovering lost messages and resoring message order and thus reduces the disadvantages of TCP.

But in your case, neither order of messages nor message loss should matter. Anyway, you can make your own decision. If you cant afford message loss and / or need to keep the order of the messages, try TCP, if not, use UDP. And, maybe more important for you, some professional (RTS) games use 4 - 6 network updates per second, for an action game maybe use 6 - 8 updates then. I'd try 6 and do only more if 6 isnt enough.

-JAW
Offline Kova

Senior Devvie





« Reply #29 - Posted 2006-09-17 14:45:28 »

fire and forget is UDP system actually... you send a message and you forget about it, not dealing when or will they come to server.
RTS are generaly slow games... for fast games 10 updates should be used I think.
JAW please read TCP vs UDP thread here, it has really lots of usefull information.
Pages: [1] 2
  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.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (21 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (105 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!