quote:

---

Original post by krez
hey man, leave the ellipses out of this... they have NOTHING to do with this issue...
--- krez

---

I have nothing against ellipses, but a single period will suffice in most cases, will it not?

Anyway...

I just remembered something about the derivative of acceleration. I know you have velocity and acceleration, but I seem to remember someone once giving a name to the 3rd derivative of displacement. I personally like the term accelerocity, but is there any word that is the (de facto) correct term? If so I would definately use it in my programs (internally) when I have a variable for such things.

--TheMuuj

[edited by - themuuj on July 17, 2002 12:43:04 PM]

[edited by - themuuj on July 17, 2002 12:44:25 PM]

Yes, assume that the ratio of modem/broadband is about 30/70.

As for AP, trust me, you can''t just send the position every frame and expect the other player to get it and display it correctly. Think about this. If I send it every single frame, then theoretically, the other players will see that every single frame. The problem is that what is currently displayed for them will be what I was doing and where I was at about 250ms ago. Doesn''t sound like a long time, but when you''re turning in a tight loop, it would matter. This is assuming that no packets are dropped.

Say you were chasing someone and firing at their rear. Some router decides to start dropping packets just as your shots get close to him. He pulls a tight loop to the right, and ends up behind you. Because of those dropped packets, you won''t even see that he turned. Suddently he''s behind you and firing at you. It will look like a major programming bug and it''s not.

Sending that many updates would simply not be feasible. Not to mention, that sending every single frame assumes that everyone has the same framerate. If you have a framerate of 240 fps and I have a framerate of 30fps, what you see is going to be very choppy. Based on the assumption that no packets are dropped and the packets arrive at the same time, every time, you will see me move every 8 frames of animation. It''s not going to look consistent. You absolutely must use some type of interpolation.

As for the derivatives, they are position, velocity and acceleration. Position is pretty much displacement, although I''m sure if you talk to someone with a PhD in Physics, he''d tell you they''re not the same thing and he''d be right. Let''s just call it position for now.

dx = derivative, dx^2 = the second derivative

dx(position) = velocity
dx^2(position) = dx(velocity) = acceleration

You don''t take the third or fourth derivative. To go from the acceleration function to the velocity or position, you take the integrals.

Integral(acceleration) = velocity + C where C is an unknown constant

Integral^2(acceleration) = Integral(velocity + C) = position

---

Looking for an honest video game publisher? Visit www.gamethoughts.com

quote:

---

Original post by MatrixCubed
Instead, concentrate on the facts: TCP is a "guaranteed messaging" protocol (i.e. the packets will be received in the order in which they were sent). This makes things like physics, motion, and action-event updates a little easier to manage. UDP on the other hand, requires that the programmer manage this.

UDP packet transmission is certainly 'faster' in general because of its smaller size and lack of error-compensation, but what advantage does this have if the developer implements his own protocol-layer (essentially mimicking TCP so that packets are sorted properly) that ends up slower than TCP?

---

Hi MatrixCubed. I have no idea why you say that TCP makes physics easier. Maybe you can go into further detail? Since TCP is streamed, and has inherent latencies, you are likely to get updates in a less timely manner. This results in frustrating play for the end users.

Anyone who has ever implemented a game using a "reliable" UDP will tell you that you do NOT end up with something that is slower than TCP (unless your pet monkey writes your code). First of all, you don't mimic TCP. Typically, you only provide reliability and order. There is far more to TCP than reliability and order. Flow control, full-duplex connection, TIME_WAIT, congestion avoidance and so on... Those items introduce huge latencies and system overhead.

Many games that have nice physics engines use UDP... I'd be willing to say most games in general use UDP. I agree that just because company "A" used it for game "X" doesn't mean that it's the best for company "B" to use for game "Y". But there is probably a good reason that company "A" made the decision to use UDP in the first place.

It is reasonable that people think TCP is the obvious choice, because it does the work for you. But as you gain experience, particularly handling thousands of simultaneous users, you will see that the overhead of writing UDP-based networks is more than worth the rewards.

Edit: By the way, I checked out your website, it looks pretty cool. Be advised there is a commercial game in development called PlanetSide.


[edited by - fingh on July 17, 2002 3:18:06 PM]

Also, on a semi-related note, it should be noted that you can turn Nagle''s algorithm off if you so desire, meaning that TCP will not wait and accumalate data before sending.

quote:

---

Original post by TheMuuj
I just remembered something about the derivative of acceleration. I know you have velocity and acceleration, but I seem to remember someone once giving a name to the 3rd derivative of displacement. I personally like the term accelerocity, but is there any word that is the (de facto) correct term? If so I would definately use it in my programs (internally) when I have a variable for such things.

---

I just found the answer myself. Apparently the 3rd derivative of position is called 'jerk.'

And apparently there is such a device that can measure jerk, called a jerkmeter (boy I wish I had a jerkmeter when dealing with jerks!)

The name jerk actually makes a bit of sense when you start thinking about it. Like, when you are riding in a car, you feel the changes in acceleration more than anything. If a car changes from an acceleration of 1m/s^2 to -2m/s^2 in a single second, you will feel quite a jerk.

I have also come across a uses for jerk when doing cubic splines on motion, and it could certainly come into play when interpolating movement data.

The term 'jolt' seems to be used in the UK at times, but it makes me think of a drink with lots of caffene.

Now I will have to remember to use that term in my code. :-)

float timeDelta = 0.1
Vector3 jerk, acceleration, velocity, position;
...
position += velocity * timeDelta;
velocity += acceleration * timeDelta;
acceleration += jerk * timeDelta;

I like how that looks, even though I don't think I will ever use it like THAT. :-)

--TheMuuj

[edited by - themuuj on July 18, 2002 10:19:07 AM]

jerk. That''s pretty funny. I don''t think I''ve ever heard it formally called that.

Then again, when I went to college, we were doing continuous functions of time. When you talk about the difference from one second to the next, that''s discrete time and that''s where the third derivative would apply. We used Z transforms for discrete differential equations. Mostly LaPlace transforms for continuous diff-eq''s. For Z transforms though, we never really discussed the formal names of them. My professors were more concerned that you understood the concepts well enough to be able to apply them to digital systems with analog interfaces to things like motors for control systems. I always thought it was pretty neat, but I hated the work. Even for ''simple'' problems, the solution was typically 3-4 pages long, and that''s because my handwriting was small. A lot of other people would have easily twice that.

As scary as this sounds, I can actually imagine using Simulink within Matlab to calculate what a smooth framerate would be in a 3D FPS game. If your program drops below that framerate, you should start dropping the level of detail of the scene to compensate so the game doesn''t become, shall I say, ''jerky''?

heh. I''m not going to go on. This could turn very stupid very quickly.

---

Looking for an honest video game publisher? Visit www.gamethoughts.com

For this type of situation, I''d recommend using UDP. Packets arrive when they do, and not all of them may be necessary.

It should be a simple choice, large, fast paced games, where time is critical, UDP is a good choice, send things and hope they get there, resend the ones that are absolutely necessary if you didn''t get a reply.

TCP is fine for games too (especially the non time critical ones), you just have to know when to use it.

Tribes 2 used UDP, and this was pretty much the developers'' reasoning.

A good network layer will use both because both have advantages over the other.

TCP is good for those messages that must be reliable; connect, disconnect, full state, chat, opening a door, using an object, etc. It makes sure the packets get there and it does it at the system level, a good advantage over UDP, especially on the server.

Advantages: System level reliability service. Bandwidth reduction for bad conections (sliding window and slow start). Easy to route through firewalls (very important for some customers, especially in Asia.)

Disadvantages: Nagle algorithm wait times, but this can be disabled on most IP stacks). Bandwidth reduction for bad connections (sliding window and slow start).


UDP is good for those messages that don''t have to get there; delta state mostly, but sometimes others like chat. Since clients can make up for losing this information, UDP will work and gives a few advantages over TCP. You can write your own reliabity service if you would like to replace TCP, but you should still support both.

Advantages: It has slightly less header overhead than TCP, which reduces bandwidth.

Disadvantages: Not all firewalls will route it. You must write your own reliability service if replacing TCP. First type of packet to be dropped by routers.


Did I forget any?

Anyway, what I''m trying to say is there is no one solution for everything. Evaluate what you need and use what is required.

For the original post, use UDP for everything. If you want to make sure chat gets through, use TCP for that. But the game is small so you don''t need it.


Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

quote:

---

Original post by mtaber
You should also comment on how the game should handle dropped packets,

---

If you specific how it should handle dropped packets (other than *must* resend or disconnect), you can''t use TCP; the specification would then require a UDP (or lower) protocol.

I''ve worked with three seperate net libraries with commercial MMOGs. Of the three, only one uses TCP. It is not currently used in any core game systems, only backend support services (e.g. administration, etc...).

The other two libraries provide reliable UDP services in addition to the standard ''best-effort'' UDP service. Once you have a well-tested reliable UDP system, you really don''t need to resort to TCP unless you are working with another external protocol like HTTP. TCP has some advantages over UDP (and vice-versa), as listed by other posters. But if you have a well-rounded network library, you can accomplish pretty much anything with UDP. An obvious exception is OOB data. Most NATs and firewalls can handle UDP with proper configuration. I believe some load balancing equipment works best with TCP, but I''m not positive.