Source is terrible, 1) You have to pay to be punished by its badness 2) the GFX( even orange box version) are outdated and sparks are much better both in lighting and texture POV 3)Ingame Movement,the engine runs FPS games like utter junk its the clunkiest fps engine i've ever played on. GoldSRC is the standard people should be looking too and valve did NOT make that they just modded the Quake teams work. 5) Investment, instead of paying for a substandard engine like source UWE will have other companies probably even valve paying them to license Spark.
<!--quoteo(post=1805129:date=Nov 10 2010, 01:51 AM:name=maesse)--><div class='quotetop'>QUOTE (maesse @ Nov 10 2010, 01:51 AM) <a href="index.php?act=findpost&pid=1805129"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What kind of physics are you talking about? And or why does Quake/Source solve it in a bad/outdated way?<!--QuoteEnd--></div><!--QuoteEEnd-->
Bullets. Arcing. Stuffs.
One of the best examples: older quakes had fixed pattern for the shotgun. Newer games now quasi-randomize where the bullets come out. So, instead of the game checking a set pattern of bullets, the client generates 12-20 bullets and has to tell the server where they all are going, then the server tracks and sees what they hit, etc.
Mostly physics back then were collisions using very simple algorithms. Stuff shoot in straight line. Now people are trying to model weapons, players, and environments with a higher degree of accuracy introducing noise to the flights and arc angles, using more detailed trajectories of a thrown grenade and how it bounces and rolls, etc. Plus, bullets are simulated as smaller projectiles in proportion to the hitboxes.
Also, way more geometry to handle in terms of hitreg. You don't just have a bounding box. If you shoot at someone's legs in midstride it _should_ go between them and inflict 0 damage for most modern games. Going back far enough, you had a single rectangular box around you (maybe a second one for your head) and if something hit that region it counted.
One of the best examples: older quakes had fixed pattern for the shotgun. Newer games now quasi-randomize where the bullets come out. So, instead of the game checking a set pattern of bullets, the client generates 12-20 bullets and has to tell the server where they all are going, then the server tracks and sees what they hit, etc.
Mostly physics back then were collisions using very simple algorithms. Stuff shoot in straight line. Now people are trying to model weapons, players, and environments with a higher degree of accuracy introducing noise to the flights and arc angles, using more detailed trajectories of a thrown grenade and how it bounces and rolls, etc. Plus, bullets are simulated as smaller projectiles in proportion to the hitboxes.
Also, way more geometry to handle in terms of hitreg. You don't just have a bounding box. If you shoot at someone's legs in midstride it _should_ go between them and inflict 0 damage for most modern games. Going back far enough, you had a single rectangular box around you (maybe a second one for your head) and if something hit that region it counted.<!--QuoteEnd--></div><!--QuoteEEnd-->
Pretty sure you have no clue what you're talking about, the client would not send all this information to the server. The client sends, hey i fired a bullet, then the server does all those calculations, not the client. If the client did all those calculations before sending packet then the game would be EASILY hackable and insecure, all computation is SERVER SIDE. If you've ever teleported when you lag its because its the server telling you where your player is, the server does not need to "calculate your physics", your client can do that heavy lifting.....
Netcode is pretty simple.
Oh, and I'm one of those "computer engineers" mentioned a few posts up, LOL. I work for a company that does the CCD cameras on the mars rover and such :)
maesse pretty much hit the nail on the head with this one, completely agree with him.
Kouji_SanSr. Hινε UÏкεεÏεг - EUPT DeputyThe NetherlandsJoin Date: 2003-05-13Member: 16271Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1805168:date=Nov 10 2010, 09:55 PM:name=Spektor56)--><div class='quotetop'>QUOTE (Spektor56 @ Nov 10 2010, 09:55 PM) <a href="index.php?act=findpost&pid=1805168"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Oh, and I'm one of those "computer engineers" mentioned a few posts up, LOL. I work for a company that does the CCD cameras on the mars rover and such :)<!--QuoteEnd--></div><!--QuoteEEnd--> So, when do we get boats to sail to Mars anyways, I had an appointment with a Martian about a few years ago. I'm delayed I told him. Little do they know we only have a Space Shuttle, incapable to go there (manned)
<!--quoteo(post=1805168:date=Nov 10 2010, 01:55 PM:name=Spektor56)--><div class='quotetop'>QUOTE (Spektor56 @ Nov 10 2010, 01:55 PM) <a href="index.php?act=findpost&pid=1805168"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Pretty sure you have no clue what you're talking about, the client would not send all this information to the server. The client sends, hey i fired a bullet, then the server does all those calculations, not the client. If the client did all those calculations before sending packet then the game would be EASILY hackable and insecure, all computation is SERVER SIDE. If you've ever teleported when you lag its because its the server telling you where your player is, the server does not need to "calculate your physics", your client can do that heavy lifting.....
Netcode is pretty simple.
Oh, and I'm one of those "computer engineers" mentioned a few posts up, LOL. I work for a company that does the CCD cameras on the mars rover and such :)
maesse pretty much hit the nail on the head with this one, completely agree with him.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, most of the heavy lifting is done server-side and netcode just says "X event happens". However, there is more and more stuff we have to keep track of now.
Back to the shotgun example, all you had to say in Quake was "I fired a gun at XYZ and in this direction" and instantly both the client and server knew where the bullets would go because it was a set pattern. Now, you need to say "I fired guns at XYZ in this direction and this was the sets of bullets that came out" and start rendering them client-side, while the server goes "huh, that makes sense, let me check if you hit things" per bullet. If you're hacking paranoid, the client can generate a "random" spread to render on the client and the real spread occurs only on the server and we expect the player can't tell the difference of 2 pellets versus 1 pellet hitting on the client versus server, and if the client was wrong the server has to correct for it. I'm pretty sure most games use a mix where the client kinda knows where stuff should go and tries to render it, but the server obviously has final say, and we just assume the player can't see stuff (or we update fast enough it's unnoticeable).
The real problem with netcode is not the packets but the complexity of accuracy. You have to reconcile when the event happened according to the client, which is different from when you got the packet, which also has to reconcile with how the world looks now, etc. Keeping track of more things and backtracking what goes where gets harder and harder the more stuff you're keeping track of. The brain-dead version is "when the packet is received, that is where the action occurred". However, that would mean with enough lag you become unhittable (as would everyone else). With more interesting versions of physics, more geometry interactions, and higher accuracy the reconciling step becomes extremely hard.
Also, lag isn't just a function of internet speed. It is actually a function of update round-time. So, if the server only receives packets and never sends out game states, you have infinite lag. If you send out a game state every 0.1ms, the server never has time to update its own gamestate internally. Finding the happy medium plus some optimizations for when a particular client isn't interacting a lot is the real trick for netcode.
<!--quoteo(post=1805167:date=Nov 10 2010, 11:10 PM:name=spellman23)--><div class='quotetop'>QUOTE (spellman23 @ Nov 10 2010, 11:10 PM) <a href="index.php?act=findpost&pid=1805167"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Going back far enough, you had a single rectangular box around you (maybe a second one for your head) and if something hit that region it counted.<!--QuoteEnd--></div><!--QuoteEEnd--> you mean like it is in ns1 right now...
<!--quoteo(post=1805178:date=Nov 11 2010, 01:05 AM:name=spellman23)--><div class='quotetop'>QUOTE (spellman23 @ Nov 11 2010, 01:05 AM) <a href="index.php?act=findpost&pid=1805178"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yes, most of the heavy lifting is done server-side and netcode just says "X event happens". However, there is more and more stuff we have to keep track of now.
Back to the shotgun example, all you had to say in Quake was "I fired a gun at XYZ and in this direction" and instantly both the client and server knew where the bullets would go because it was a set pattern. Now, you need to say "I fired guns at XYZ in this direction and this was the sets of bullets that came out" and start rendering them client-side, while the server goes "huh, that makes sense, let me check if you hit things" per bullet. If you're hacking paranoid, the client can generate a "random" spread to render on the client and the real spread occurs only on the server and we expect the player can't tell the difference of 2 pellets versus 1 pellet hitting on the client versus server, and if the client was wrong the server has to correct for it. I'm pretty sure most games use a mix where the client kinda knows where stuff should go and tries to render it, but the server obviously has final say, and we just assume the player can't see stuff (or we update fast enough it's unnoticeable).<!--QuoteEnd--></div><!--QuoteEEnd--> Quake2+ and GoldSrc does this. The shared (a lot of movement/weapon code is shared by the client and server, so because the code is the same, you get the same results, aka. good client prediction) code senses that the player pressed fire. The server handles the final decision of all bullets/pellets (like from a shotgun). Because the client runs more or less the same code, it knows when the server would allow a bullet to be fired, therefore it can predict it - it doesn't know the final spread as you say, so it just does it best and that's good enough.
Haven't looked at old Quake1 code, so can't really comment on any of that.
<!--quoteo(post=1805178:date=Nov 11 2010, 01:05 AM:name=spellman23)--><div class='quotetop'>QUOTE (spellman23 @ Nov 11 2010, 01:05 AM) <a href="index.php?act=findpost&pid=1805178"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The real problem with netcode is not the packets but the complexity of accuracy. You have to reconcile when the event happened according to the client, which is different from when you got the packet, which also has to reconcile with how the world looks now, etc. Keeping track of more things and backtracking what goes where gets harder and harder the more stuff you're keeping track of. The brain-dead version is "when the packet is received, that is where the action occurred". However, that would mean with enough lag you become unhittable (as would everyone else). With more interesting versions of physics, more geometry interactions, and higher accuracy the reconciling step becomes extremely hard.<!--QuoteEnd--></div><!--QuoteEEnd--> Quake solved this by simply not doing backwards reconciliation ;) Players just got used to leading they aim according to their ping, and I'm sure there's lots of old quakers that swears to that solutions. GoldSrc introduced backwards reconciliation to the netcode, so players wouldn't feed tricked out on a hit. The server already knows the ping of each client, how every client moved past the last second and the clients frametimes.. - so all in all a good amount of detailed infomation. Valve has an article on this, although it's about source, the prediction code is pretty much the same as GoldSrc. <a href="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation" target="_blank">http://developer.valvesoftware.com/wiki/So...ag_compensation</a>
I kind of feel bad about reviving a thread with this name :/
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited November 2010
<!--quoteo(post=1805215:date=Nov 10 2010, 07:02 PM:name=maesse)--><div class='quotetop'>QUOTE (maesse @ Nov 10 2010, 07:02 PM) <a href="index.php?act=findpost&pid=1805215"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Quake solved this by simply not doing backwards reconciliation ;) Players just got used to leading they aim according to their ping, and I'm sure there's lots of old quakers that swears to that solutions. GoldSrc introduced backwards reconciliation to the netcode, so players wouldn't feed tricked out on a hit. The server already knows the ping of each client, how every client moved past the last second and the clients frametimes.. - so all in all a good amount of detailed infomation. Valve has an article on this, although it's about source, the prediction code is pretty much the same as GoldSrc. <a href="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation" target="_blank">http://developer.valvesoftware.com/wiki/So...ag_compensation</a>
I kind of feel bad about reviving a thread with this name :/<!--QuoteEnd--></div><!--QuoteEEnd--> Quake also had a hit success noise which makes all the difference... It provided a definitive feedback to the player to let them know if they were aiming right. I still believe that this is the #1 reason why everyone thought Quake 3 Arena's online play was so tight.
Also, it's not just that the server rolls it back. The client simulation actually runs at a 50-100 ms lag itself (slight input buffering), though the data is immediately sent to the server. This helps to disguise the latency between server and client even further by hopefully having the message get to the server before the client has even finished acting upon it.
<!--quoteo(post=1803638:date=Oct 29 2010, 01:26 AM:name=NS2HD)--><div class='quotetop'>QUOTE (NS2HD @ Oct 29 2010, 01:26 AM) <a href="index.php?act=findpost&pid=1803638"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->1. Source costs money. What, do you think UWE gets it for free?<!--QuoteEnd--></div><!--QuoteEEnd-->
Spark is by no means free. It's actually the most expensive part of the build process as it's still continually being created 3 years or so on, as it's not a fully functioning basic game engine being upgraded, it's still not complete of basic function fit for a retail game use.
The figure for the amount of money expended on the project already would be interesting to see, as you also mentioned U3E/UDK which, having a rough idea of the games industry and not an amazingly in-depth one, is potentially a much cheaper and stable option. Not that it matters, as it's all on Spark anyway, just a nice little interesting sidetrack.
<!--quoteo(post=1805215:date=Nov 10 2010, 07:02 PM:name=maesse)--><div class='quotetop'>QUOTE (maesse @ Nov 10 2010, 07:02 PM) <a href="index.php?act=findpost&pid=1805215"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Quake2+ and GoldSrc does this. The shared (a lot of movement/weapon code is shared by the client and server, so because the code is the same, you get the same results, aka. good client prediction) code senses that the player pressed fire. The server handles the final decision of all bullets/pellets (like from a shotgun). Because the client runs more or less the same code, it knows when the server would allow a bullet to be fired, therefore it can predict it - it doesn't know the final spread as you say, so it just does it best and that's good enough.
Haven't looked at old Quake1 code, so can't really comment on any of that.
Quake solved this by simply not doing backwards reconciliation ;) Players just got used to leading they aim according to their ping, and I'm sure there's lots of old quakers that swears to that solutions. GoldSrc introduced backwards reconciliation to the netcode, so players wouldn't feed tricked out on a hit. The server already knows the ping of each client, how every client moved past the last second and the clients frametimes.. - so all in all a good amount of detailed infomation. Valve has an article on this, although it's about source, the prediction code is pretty much the same as GoldSrc. <a href="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation" target="_blank">http://developer.valvesoftware.com/wiki/So...ag_compensation</a>
I kind of feel bad about reviving a thread with this name :/<!--QuoteEnd--></div><!--QuoteEEnd-->
Yay history!
And don't feel bad. There have been worse threads in the history of this forum...
<!--quoteo(post=1805001:date=Nov 9 2010, 06:35 AM:name=Dalin Seivewright)--><div class='quotetop'>QUOTE (Dalin Seivewright @ Nov 9 2010, 06:35 AM) <a href="index.php?act=findpost&pid=1805001"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Sorry, but you're saying a machine designed from the ground up to perform two argument math calculations and send them over the internet to a small screen is superior to a machine designed from the ground up to perform variable argument math calculations that draws a graph, calculates different formulas to arrive at the same answer and then sending the data over the internet.
Gaming was a different place back then. You needed to send a great deal less data and probably less frequently as well. To compare the netcode from an older game that ran very well to a newer game that might not run as well just isn't a fair comparison.
That being said, I agree for the most part. IMHO the game industry is lacking actual engineers[1] that work with the underlying technology and understand what they are doing. I'm not engineer, but I would love to toy with stuff like this, but nothing I would produce would come close to what an engineer heavily trained in that area could accomplish. And besides, I don't think netcode is a "MY NET CODE WORKS FOR EVERYTHING" sort of deal. The game requirements have to be assessed and the best option needs to be implemented at an engine level. I don't think many game developers are doing this.
[1] Or the engineers who are trying to do things the proper way are being shot down by management, which, could quite possibly be the case.<!--QuoteEnd--></div><!--QuoteEEnd-->
I agree with you to an extent, I wasn't saying that everyone should be recyling the same netcode (well it did work for HL / CS / DOD etc) but fast forward a couple of decades and the average connection has a hell of a lot more bandwidth to allow for larger entity counts and updates and I don't know how many times more factors of processing power and ram to do all that pesky math stuff. The point I was making was that good netcode (distingusing this from graphics / gameplay engine related FPS issues) should allow any user who is participating in the game feel like everything they are doing / seeing is happening real time to their computer. Even factoring in things like massive entity counts, games like serious sam have numbers of enemies in the player region sometimes bordering on the silly and yet I have to play a co-op game that felt like I was on a 2 second delay to the action, yet I have played BF2 & 2142 at LANS (I do a LOT of LANS) and felt that the game was playing just a poorly as it would had I been on a net connection. (and with regards to 2142 being the worst BF game, feelings for the game itself is irrelevant when discussing netcode, the fact remains that it was the only BF game who's netcode didn't suck b**** although it did take them 5 patches and pretty much a community wide ban on moving titans. Sorry but Bad Company 2's netcode currently is REALLY poor, at super close ranges bullet reg is at best intermittent and the number of times I have been killed after moving to a safe area only for the server to bump me off because I was actually killed half a second ago I deeply annoying (it really shouldn't be the case in 2010 when a games players are considered to have "good" pings which are higher then late 90's 56K quake pings).
My thanks also to maesse for posting the whole thing about ping compensation / client prediction.
<!--quoteo(post=1805196:date=Nov 10 2010, 08:07 PM:name=weezl)--><div class='quotetop'>QUOTE (weezl @ Nov 10 2010, 08:07 PM) <a href="index.php?act=findpost&pid=1805196"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->you mean like it is in ns1 right now...<!--QuoteEnd--></div><!--QuoteEEnd--> Yep. NS1 was a 2002 mod of a game made in 1998.
Comments
Bullets. Arcing. Stuffs.
One of the best examples: older quakes had fixed pattern for the shotgun. Newer games now quasi-randomize where the bullets come out. So, instead of the game checking a set pattern of bullets, the client generates 12-20 bullets and has to tell the server where they all are going, then the server tracks and sees what they hit, etc.
Mostly physics back then were collisions using very simple algorithms. Stuff shoot in straight line. Now people are trying to model weapons, players, and environments with a higher degree of accuracy introducing noise to the flights and arc angles, using more detailed trajectories of a thrown grenade and how it bounces and rolls, etc. Plus, bullets are simulated as smaller projectiles in proportion to the hitboxes.
Also, way more geometry to handle in terms of hitreg. You don't just have a bounding box. If you shoot at someone's legs in midstride it _should_ go between them and inflict 0 damage for most modern games. Going back far enough, you had a single rectangular box around you (maybe a second one for your head) and if something hit that region it counted.
One of the best examples: older quakes had fixed pattern for the shotgun. Newer games now quasi-randomize where the bullets come out. So, instead of the game checking a set pattern of bullets, the client generates 12-20 bullets and has to tell the server where they all are going, then the server tracks and sees what they hit, etc.
Mostly physics back then were collisions using very simple algorithms. Stuff shoot in straight line. Now people are trying to model weapons, players, and environments with a higher degree of accuracy introducing noise to the flights and arc angles, using more detailed trajectories of a thrown grenade and how it bounces and rolls, etc. Plus, bullets are simulated as smaller projectiles in proportion to the hitboxes.
Also, way more geometry to handle in terms of hitreg. You don't just have a bounding box. If you shoot at someone's legs in midstride it _should_ go between them and inflict 0 damage for most modern games. Going back far enough, you had a single rectangular box around you (maybe a second one for your head) and if something hit that region it counted.<!--QuoteEnd--></div><!--QuoteEEnd-->
Pretty sure you have no clue what you're talking about, the client would not send all this information to the server. The client sends, hey i fired a bullet, then the server does all those calculations, not the client. If the client did all those calculations before sending packet then the game would be EASILY hackable and insecure, all computation is SERVER SIDE. If you've ever teleported when you lag its because its the server telling you where your player is, the server does not need to "calculate your physics", your client can do that heavy lifting.....
Netcode is pretty simple.
Oh, and I'm one of those "computer engineers" mentioned a few posts up, LOL. I work for a company that does the CCD cameras on the mars rover and such :)
maesse pretty much hit the nail on the head with this one, completely agree with him.
So, when do we get boats to sail to Mars anyways, I had an appointment with a Martian about a few years ago. I'm delayed I told him. Little do they know we only have a Space Shuttle, incapable to go there (manned)
Netcode is pretty simple.
Oh, and I'm one of those "computer engineers" mentioned a few posts up, LOL. I work for a company that does the CCD cameras on the mars rover and such :)
maesse pretty much hit the nail on the head with this one, completely agree with him.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, most of the heavy lifting is done server-side and netcode just says "X event happens". However, there is more and more stuff we have to keep track of now.
Back to the shotgun example, all you had to say in Quake was "I fired a gun at XYZ and in this direction" and instantly both the client and server knew where the bullets would go because it was a set pattern. Now, you need to say "I fired guns at XYZ in this direction and this was the sets of bullets that came out" and start rendering them client-side, while the server goes "huh, that makes sense, let me check if you hit things" per bullet. If you're hacking paranoid, the client can generate a "random" spread to render on the client and the real spread occurs only on the server and we expect the player can't tell the difference of 2 pellets versus 1 pellet hitting on the client versus server, and if the client was wrong the server has to correct for it. I'm pretty sure most games use a mix where the client kinda knows where stuff should go and tries to render it, but the server obviously has final say, and we just assume the player can't see stuff (or we update fast enough it's unnoticeable).
The real problem with netcode is not the packets but the complexity of accuracy. You have to reconcile when the event happened according to the client, which is different from when you got the packet, which also has to reconcile with how the world looks now, etc. Keeping track of more things and backtracking what goes where gets harder and harder the more stuff you're keeping track of. The brain-dead version is "when the packet is received, that is where the action occurred". However, that would mean with enough lag you become unhittable (as would everyone else). With more interesting versions of physics, more geometry interactions, and higher accuracy the reconciling step becomes extremely hard.
Also, lag isn't just a function of internet speed. It is actually a function of update round-time. So, if the server only receives packets and never sends out game states, you have infinite lag. If you send out a game state every 0.1ms, the server never has time to update its own gamestate internally. Finding the happy medium plus some optimizations for when a particular client isn't interacting a lot is the real trick for netcode.
i hope anyone who says "why aren't you using the source engine" is using Dos and loading from tape drives..
welcome to the future.. go play CS cos that was amazing
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/i3bPjEbenew"></param><embed src="http://www.youtube.com/v/i3bPjEbenew" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center><!--QuoteEnd--></div><!--QuoteEEnd-->
Source "Push it to the Limit" and it does go insanely beautiful though "Past the point of no return"
you mean like it is in ns1 right now...
Back to the shotgun example, all you had to say in Quake was "I fired a gun at XYZ and in this direction" and instantly both the client and server knew where the bullets would go because it was a set pattern. Now, you need to say "I fired guns at XYZ in this direction and this was the sets of bullets that came out" and start rendering them client-side, while the server goes "huh, that makes sense, let me check if you hit things" per bullet. If you're hacking paranoid, the client can generate a "random" spread to render on the client and the real spread occurs only on the server and we expect the player can't tell the difference of 2 pellets versus 1 pellet hitting on the client versus server, and if the client was wrong the server has to correct for it. I'm pretty sure most games use a mix where the client kinda knows where stuff should go and tries to render it, but the server obviously has final say, and we just assume the player can't see stuff (or we update fast enough it's unnoticeable).<!--QuoteEnd--></div><!--QuoteEEnd-->
Quake2+ and GoldSrc does this. The shared (a lot of movement/weapon code is shared by the client and server, so because the code is the same, you get the same results, aka. good client prediction) code senses that the player pressed fire. The server handles the final decision of all bullets/pellets (like from a shotgun). Because the client runs more or less the same code, it knows when the server would allow a bullet to be fired, therefore it can predict it - it doesn't know the final spread as you say, so it just does it best and that's good enough.
Haven't looked at old Quake1 code, so can't really comment on any of that.
<!--quoteo(post=1805178:date=Nov 11 2010, 01:05 AM:name=spellman23)--><div class='quotetop'>QUOTE (spellman23 @ Nov 11 2010, 01:05 AM) <a href="index.php?act=findpost&pid=1805178"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The real problem with netcode is not the packets but the complexity of accuracy. You have to reconcile when the event happened according to the client, which is different from when you got the packet, which also has to reconcile with how the world looks now, etc. Keeping track of more things and backtracking what goes where gets harder and harder the more stuff you're keeping track of. The brain-dead version is "when the packet is received, that is where the action occurred". However, that would mean with enough lag you become unhittable (as would everyone else). With more interesting versions of physics, more geometry interactions, and higher accuracy the reconciling step becomes extremely hard.<!--QuoteEnd--></div><!--QuoteEEnd-->
Quake solved this by simply not doing backwards reconciliation ;) Players just got used to leading they aim according to their ping, and I'm sure there's lots of old quakers that swears to that solutions. GoldSrc introduced backwards reconciliation to the netcode, so players wouldn't feed tricked out on a hit. The server already knows the ping of each client, how every client moved past the last second and the clients frametimes.. - so all in all a good amount of detailed infomation. Valve has an article on this, although it's about source, the prediction code is pretty much the same as GoldSrc. <a href="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation" target="_blank">http://developer.valvesoftware.com/wiki/So...ag_compensation</a>
I kind of feel bad about reviving a thread with this name :/
I kind of feel bad about reviving a thread with this name :/<!--QuoteEnd--></div><!--QuoteEEnd-->
Quake also had a hit success noise which makes all the difference... It provided a definitive feedback to the player to let them know if they were aiming right. I still believe that this is the #1 reason why everyone thought Quake 3 Arena's online play was so tight.
Also, it's not just that the server rolls it back. The client simulation actually runs at a 50-100 ms lag itself (slight input buffering), though the data is immediately sent to the server. This helps to disguise the latency between server and client even further by hopefully having the message get to the server before the client has even finished acting upon it.
Spark is by no means free. It's actually the most expensive part of the build process as it's still continually being created 3 years or so on, as it's not a fully functioning basic game engine being upgraded, it's still not complete of basic function fit for a retail game use.
The figure for the amount of money expended on the project already would be interesting to see, as you also mentioned U3E/UDK which, having a rough idea of the games industry and not an amazingly in-depth one, is potentially a much cheaper and stable option. Not that it matters, as it's all on Spark anyway, just a nice little interesting sidetrack.
Haven't looked at old Quake1 code, so can't really comment on any of that.
Quake solved this by simply not doing backwards reconciliation ;) Players just got used to leading they aim according to their ping, and I'm sure there's lots of old quakers that swears to that solutions. GoldSrc introduced backwards reconciliation to the netcode, so players wouldn't feed tricked out on a hit. The server already knows the ping of each client, how every client moved past the last second and the clients frametimes.. - so all in all a good amount of detailed infomation. Valve has an article on this, although it's about source, the prediction code is pretty much the same as GoldSrc. <a href="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation" target="_blank">http://developer.valvesoftware.com/wiki/So...ag_compensation</a>
I kind of feel bad about reviving a thread with this name :/<!--QuoteEnd--></div><!--QuoteEEnd-->
Yay history!
And don't feel bad. There have been worse threads in the history of this forum...
Gaming was a different place back then. You needed to send a great deal less data and probably less frequently as well. To compare the netcode from an older game that ran very well to a newer game that might not run as well just isn't a fair comparison.
That being said, I agree for the most part. IMHO the game industry is lacking actual engineers[1] that work with the underlying technology and understand what they are doing. I'm not engineer, but I would love to toy with stuff like this, but nothing I would produce would come close to what an engineer heavily trained in that area could accomplish. And besides, I don't think netcode is a "MY NET CODE WORKS FOR EVERYTHING" sort of deal. The game requirements have to be assessed and the best option needs to be implemented at an engine level. I don't think many game developers are doing this.
[1] Or the engineers who are trying to do things the proper way are being shot down by management, which, could quite possibly be the case.<!--QuoteEnd--></div><!--QuoteEEnd-->
I agree with you to an extent, I wasn't saying that everyone should be recyling the same netcode (well it did work for HL / CS / DOD etc) but fast forward a couple of decades and the average connection has a hell of a lot more bandwidth to allow for larger entity counts and updates and I don't know how many times more factors of processing power and ram to do all that pesky math stuff.
The point I was making was that good netcode (distingusing this from graphics / gameplay engine related FPS issues) should allow any user who is participating in the game feel like everything they are doing / seeing is happening real time to their computer.
Even factoring in things like massive entity counts, games like serious sam have numbers of enemies in the player region sometimes bordering on the silly and yet I have to play a co-op game that felt like I was on a 2 second delay to the action, yet I have played BF2 & 2142 at LANS (I do a LOT of LANS) and felt that the game was playing just a poorly as it would had I been on a net connection.
(and with regards to 2142 being the worst BF game, feelings for the game itself is irrelevant when discussing netcode, the fact remains that it was the only BF game who's netcode didn't suck b**** although it did take them 5 patches and pretty much a community wide ban on moving titans. Sorry but Bad Company 2's netcode currently is REALLY poor, at super close ranges bullet reg is at best intermittent and the number of times I have been killed after moving to a safe area only for the server to bump me off because I was actually killed half a second ago I deeply annoying (it really shouldn't be the case in 2010 when a games players are considered to have "good" pings which are higher then late 90's 56K quake pings).
My thanks also to maesse for posting the whole thing about ping compensation / client prediction.
Yep. NS1 was a 2002 mod of a game made in 1998.