PDA

View Full Version : [VIDEO] Different FPS Netcodes



t3h m00kz
March 20th, 2008, 01:14 PM
Low quality/Streaming:

1iiLjwf3po0
Okay quality/Download:

http://www.megaupload.com/?d=2BY441ZU

;[

SnaFuBAR
March 20th, 2008, 01:38 PM
informative, well done.

CrAsHOvErRide
March 20th, 2008, 02:28 PM
Maybe you should have gone more into Pro/Contra...

In UT the server responds first then the shot is being made....
Pro: You see the shot hit the target
Contra: Projectile is delayed

In Halo the shot on client and server are being made simultaneously but only if the virtual projectile on the server hits the target you get a hit.
Pro: You see the projectile + all effects perfectly
Contra: You don't see the projectile hitting the target always (leading)

One thing you said..."the code is incomplete" or something along the line...well...it's quite obvious that they won't spend time writing AI syncing if there is no AI to sync in the fist place. The engine has been optimized (from Bungie, I bet GBX still had AI syncing code implemented) for the Halo Franchise which doesn't include AI on multiplayer.

Peer-To-Peer...
Pro: Looks perfect
Contra: Easily hacked...and this is the biggest issue. The bigger the game the more likely it is for it to get hacked. Small games may use this but since you are basically the server or everyone else you can modify the memory unless it's protected of course.

But overall pretty good...I never knew Peer-To-Peer netcode even existed. Something new to learn everyday :D

Cortexian
March 20th, 2008, 04:31 PM
I think Crysis uses Peer-to-Peer doesn't it? I never have to lead any of my shots with the Guass rifle. Only have to lead long shots from guns with slower projectiles.

MNC
March 20th, 2008, 06:58 PM
Very good video.

Pyong Kawaguchi
March 20th, 2008, 07:27 PM
Great video, Very informative.
Also, Hooray for sauerbraten ^.^

Phopojijo
March 20th, 2008, 08:26 PM
There are some extra issues involving Peer to Peer (Lockstep) netcode.

http://unreal.epicgames.com/Network.htm (From Tim Sweeney, CEO of Epic Games himself... back in 1999)

The major one being if two machines are not equal. If the game "tickrate" between two machines are not synchronized, you can have issues. The problem with Lockstep netcode is that everyone needs to know what each other is doing.

This is fine for 2-on-2 and similar games where you have very little data to transfer. However, the stress increases non-linearly with each player added. You would not be able to run a 64 player game in lockstep. You may not even be able to run a 16 player game in lockstep without serious bandwidth.

Another issue is you need to have all computers involved run at the same update rate... this is really effin' hard. You would need to install code to slow down fast computers to the lowest acceptable denominator -- and boot off all peers whose machines cannot run fast enough.

So Lockstep has issues... which is why Client/Server was created. To get away from Lockstep.

It still has it's place though: It's simple and accurate... so it's easy to program (probably why the free games use it)... and all clients see exactly the same thing (which is why it's popular with fighter games)

Also -- a lot of client/server netcodes allow for client-side hit detection on certain weapons. This basically means the client will take the shot, see if it's a hit, and tell the server plainly "I shot him". This is easy to be hacked of course "false-positives are client's authority" -- but it's usually in 3rd party mods for games like UT2k4... like UTCOMP I believe.

But overall pretty good...I never knew Peer-To-Peer netcode even existed. Something new to learn everyday :DIt's what Doom and Duke Nukem ran.

t3h m00kz
March 20th, 2008, 09:28 PM
Hmm... The form of peer-to-peer you've linked to there seems to be much more primitive than what I've seen.

According to that, with peer to peer, framerate is shared between two computers, and the players have to start at the same time. In the games I listed, Sauerbraten and WolfTeam, framerate is not affected at all, and you can join rooms and play without any problem.

Sauerbraten has rooms of up to 64 people and although I've never played with that many, I've played with 20 with no problem.

Call of Duty 3 also uses peer-to-peer, and some of the largest games can have very, very decent connections. It's true that most of the larger games have two star connections, but some of them have four or five stars.

The code COD3 uses is PERFECT for XBox 360 games in my honest opinion, seeing as nobody can really hack the shit out of 360 games at this point. Every shot lands, and there's not really any BS. It's simple and effective.

So maybe it's not actually Peer-To-Peer that these games use...?

Phopojijo
March 20th, 2008, 09:39 PM
Hmm... The form of peer-to-peer you've linked to there seems to be much more primitive than what I've seen.

According to that, with peer to peer, framerate is shared between two computers, and the players have to start at the same time. In the games I listed, Sauerbraten and WolfTeam, framerate is not affected at all, and you can join rooms and play without any problem.

Sauerbraten has rooms of up to 64 people and although I've never played with that many, I've played with 20 with no problem.

Call of Duty 3 also uses peer-to-peer, and some of the largest games can have very, very decent connections. It's true that most of the larger games have two star connections, but some of them have four or five stars.

The code COD3 uses is PERFECT for XBox 360 games in my honest opinion. Every shot lands, and there's not really any BS. It's simple and effective.

So maybe it's not actually Peer-To-Peer that these games use...?Not *framerate* -- tick rate.

There's always loops running in the processor to check if you press a button or whatever. How often THEY refresh is what matters... not how many frames get output to the monitor. That's all smoke and mirrors (with particles and realtime reflections -- quite literally :p) Physics calculations, particularly at the amount PhysX wants... could cause some issues. Some people say going TO lockstep is the best course of action, some say Client/Server is the only sane way to go. I -- don't know :p I'm not an engineer. I'd assume client/server for relevancy-factors -- but I don't know.

Tim Sweeney was talking during the time that 33.6KBaud dialup was common.

The fact still remains though -- as you add extra players -- the amount of bandwidth required to synchronize expand immensely.

Also in client/server models you can declare relevancy: You may want to update player positions a lot (100Hz in UnrealEngine)... but if someone presses a button to open a door... you may want to only check that like -- 5x per second. In lockstep -- EVERYTHING needs to be synchronized.

I got a feeling the games you mentioned aren't running entirely lockstep if you said you can fit 64P in it... that or they lock their tickrate REALLY low (15-20Hz) instead of UnrealEngine which is like -- 100Hz for high-relevancy exchanges.

For UnrealEngine2/3 --

Class.............................UpdateFreq
Actor............................100 Hz
Pawn............................100 Hz when possessed, or 5 Hz when unpossessed
Mover...........................1 Hz
Pickup...........................0.1 Hz, or 8 Hz when just dropped
PlayerReplicationInfo........1 Hz

That being said -- you probably *could* run certain things in lockstep, and certain other things in Client/Server. Not sure if weaponfire can be considered that though.

t3h m00kz
March 21st, 2008, 12:23 AM
So basically, what you're saying is that everything that happens between every player is synced based on the tickrate.. such as, if one person moves in a 20 person server, every other person will see that person move at the same time, or something along those lines?

Well I can see how people would prefer client/server over "lockstep" in some cases, especially large, populated games. However, another point I'm trying to make is the code worked really well for Call of Duty 3, I saw little to no problems with the connections in that game save for some glitchy, flippy vehicles and occasional "Game session no longer available" messages, so why couldn't something similar have been implimented for say, Halo 3, or even Halo 2? Everyone always complained about Halo 2's host advantage and whatnot, and the sweep sniping and shot leading were total BS in many people's opinions as well. Not to mention the whole "HOLY CRAP I SHOT THAT GUY A SECOND BEFORE HE KILLED ME AND IT DIDN'T DO ANYTHING!" scenario. Even with Halo 3, there are shots that don't register, I'm assuming because of packet loss in the whole client-to-server-to-client connection.

Most games in Halo 3 never have more than 10 people unless you go BTB, which is unranked anyway. I don't know much about it, but wouldn't lockstep be able to support that pretty easilly?

Gotta axe kweschins to get that nawlij


I think Crysis uses Peer-to-Peer doesn't it? I never have to lead any of my shots with the Guass rifle. Only have to lead long shots from guns with slower projectiles.

I wouldn't know... only played Crysis online a few times before getting pissy at how people would camp with snipers while the ARs and stuff were totally worthless compared to them ;[ But I'm pretty sure it's enhanced client/server.



Maybe you should have gone more into Pro/Contra...

In UT the server responds first then the shot is being made....
Pro: You see the shot hit the target
Contra: Projectile is delayed

In Halo the shot on client and server are being made simultaneously but only if the virtual projectile on the server hits the target you get a hit.
Pro: You see the projectile + all effects perfectly
Contra: You don't see the projectile hitting the target always (leading)

One thing you said..."the code is incomplete" or something along the line...well...it's quite obvious that they won't spend time writing AI syncing if there is no AI to sync in the fist place. The engine has been optimized (from Bungie, I bet GBX still had AI syncing code implemented) for the Halo Franchise which doesn't include AI on multiplayer.

Peer-To-Peer...
Pro: Looks perfect
Contra: Easily hacked...and this is the biggest issue. The bigger the game the more likely it is for it to get hacked. Small games may use this but since you are basically the server or everyone else you can modify the memory unless it's protected of course.

But overall pretty good...I never knew Peer-To-Peer netcode even existed. Something new to learn everyday :D

I agree that the pro/con should have probably been in the video but I only had like ten minutes, and I was stretching it. ;[

The thing with Halo's netcode that I will point out is the fact that although they look perfect on your screen, there's a huge learning curve to it. With UT, you get all the effects, and they come out perfectly, but they're just lagged. Understandably so. In halo, the bullets still lag, but you don't see them lag. And if you set them to server side like they are in UT, they're glitchy as hell. ;[

Not to mention UT2004 supports AI enemies in Invasion mode.

There's more pro with UT's netcode than Halo's imo

Phopojijo
March 21st, 2008, 02:17 AM
You can have bots in more than just invasion.

You can have any form of bot you wish in any gametype... provided you can code it right.

t3h m00kz
March 21st, 2008, 02:40 AM
True, true.

UT's netcode > HPC's netcode

Phopojijo
March 21st, 2008, 03:38 AM
True, true.

UT's netcode > HPC's netcodeYea that's obvious. Gearbox was attempting to make an engine they didn't create convert LAN netcode into 56K.

UnrealEngine2+ netcode plain and simple just had a better opportunity.

If you want, however; check out Unreal 1 (not UT, Unreal) netcode :) Allegedly *that* is the sucks.

t3h m00kz
March 21st, 2008, 12:53 PM
I have Unreal: Gold that came with the Anthology, but I couldn't join any servers... every server I tried to join said I needed Unreal Tournament. I was like wtf?

Halo PC could have been so much worse. If you've ever played XBox Connect with Halo 1 you'd see how absolutely laggy and insane it was. The lag was so bad your movements were server-side. However one thing that I did like about it was the gun fire/projectiles showed up as they did in the server.

But to be honest that was just the LAN system that wasn't even made for Live with 150+ latency anyway.

Zeph
March 21st, 2008, 05:47 PM
You're wrong when talking about Halo's netcode concerning the bots. They were never designed to work over a networked connection. For example, if you join a server with bots and kill one, the server can only tell if the projectiles line up.

t3h m00kz
March 21st, 2008, 07:26 PM
So, if a server has AI, they're going to by synced, but to kill them you still have to lead your shots?

That's what I'm getting from what you're saying. Unless you're talking about what I said in the video about it being a feature.

They don't sync, that's what I said in the video. I mentioned it may have been a feature that wasn't implimented, but I do say they don't sync.

Area 53/54/whatever is a good example... try playing that online, not very fun ;[

ExAm
March 23rd, 2008, 01:34 AM
I think Crysis uses Peer-to-Peer doesn't it? I never have to lead any of my shots with the Guass rifle. Only have to lead long shots from guns with slower projectiles.
Also there have apparently been issues with players editing their own files and cheating online. I'd say you're right about Crysis and P2P netcode.

Sel
March 23rd, 2008, 12:15 PM
UT2004 has lead?

I never noticed :D which is a good thing

Also, UT2004 is only 10$ canadian :O

Zeph
March 23rd, 2008, 01:02 PM
So, if a server has AI, they're going to by synced, but to kill them you still have to lead your shots?

That's what I'm getting from what you're saying. Unless you're talking about what I said in the video about it being a feature.

They don't sync, that's what I said in the video. I mentioned it may have been a feature that wasn't implimented, but I do say they don't sync.

Area 53/54/whatever is a good example... try playing that online, not very fun ;[

Yes, they dont synch because they're not intended for network play. The server doesn't know how to synch the bots. There are no calls made to say where they are, what they are doing, or even if they are alive or dead. The only thing the server can do it tell everyone what the bots are doing on its machine. So if you've got a server running with bots running all over the level, dont expect clients to be able to see them in the exact same spot. The only way the server can link a clients actions to the bots in inadvertent at that. If you shoot, you tell the server that you shot and what the vector was from your local position. The server makes you shoot at your server-sided position, sees if you hit anything, then relays the results to everyone else in the server. If the server sees you randomly hit a running bot in the head, it will kill that bot and tell everyone in the server that bot died. The bot's location was never synched, so somewhere else randomly on the map for everyone, that bot will die.

If someone joins after that, the server doesn't know how to tell that new player where the bots are or which ones are dead or alive, so that new player will see the bots start just as if it were new.

Yes, you say they dont work, but you speak of it as if it's a broken feature. It's something that was just never supposed to happen in the first place and wasn't locked out because developers knew to never do it in the first place.