Blog update - Client-side scripting and weapons
Max
Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
Please post your thoughts on the <a href="http://www.unknownworlds.com/blog/2007/06/clientside_scripting_and_weapo_1.html" target="_blank">latest blog entry</a> here.
By the way, the weapon silhouettes you see in the blog entry are the more organic redesigns I mentioned back in <a href="http://www.unknownworlds.com/forums/index.php?s=5244000514606742528&showtopic=101138" target="_blank">this thread</a>.
By the way, the weapon silhouettes you see in the blog entry are the more organic redesigns I mentioned back in <a href="http://www.unknownworlds.com/forums/index.php?s=5244000514606742528&showtopic=101138" target="_blank">this thread</a>.
Comments
all of them? <img src="style_emoticons/<#EMO_DIR#>/wow.gif" style="vertical-align:middle" emoid=":0" border="0" alt="wow.gif" /> wow
and like that green gun =)
These client side scripts how are they controlled? I’m just thinking about how cheat proof these scripts are. If anyone can change there client scripts wouldn’t this be a problem?
Again love these dev posts, keep up the good work <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
It's actually funny, because I completely understood what Max was talking about.
<!--QuoteEnd--></div><!--QuoteEEnd-->
I too find that hilarious!
I like the bottom left gun in the second gun image. The stock is too long but the rest looks pretty neat.
<img src="http://img.photobucket.com/albums/v354/hybridclaw/flamegorge.jpg" border="0" alt="IPB Image" />
I was hoping that the aliens would be the team that would get a flamethrower <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
<img src="http://img.photobucket.com/albums/v354/hybridclaw/flamegorge.jpg" border="0" alt="IPB Image" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
LOL *burp*
nice update max <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Dev posts are great. Although it might just be me, as I'm a programmer, so I kinda like the whole code idea from the beginning <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Many thanks for this additional look behind the scenes. These posts (discussions) are golden.
On another note:
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->With [our scripted entities hooked into the core network system], the engine will instantiate client-side versions of the entities when the server tells them they've come into the player's view.<!--QuoteEnd--></div><!--QuoteEEnd-->My machine isn't anything to write home about, and I always notice that my NS1 hiccups the first time I bring up my minimap after the game's started, or the first time I round a corner and see the first observatory my client loads. I know little about how all of this works, but my assumption is that the delay (negligible though it be) is due to the loading, during my gameplay, of certain models and sprites.
So I ask: is it possible, in NS past or future, to load allllll of the sprites/models/scripts/etc while the map is loading? If not, why (too taxing on the box/network/somethingelse, maybe)?
Great update Max, love the backstory. One question though: if everything is running as scripts and not as compiled code, will there be a slow-down as the script has to be dynamically converted to executions? All the opportunities that scripting allows for customization is great, but what is the cost in terms of system resources?
<!--QuoteEnd--></div><!--QuoteEEnd-->
No, the difference is that these scripts are written out the long way, which is what vanilla Source converts the macros in to when they are compiled. In this case the NS2 scripts aren't macros, they're the actual scripts.
I too was concerned about the script hack problem. If the client side scripted guns are telling the server how much ammo it has left in it's clip, and the server just nods and says "good, thanks for the info", we've got a serious problem. Anyone could make a script for some uber gun that would never run out of ammo and (while we're at it) kill in one bullet. Perhaps we missed a bit of how it works? Is there any security feature included in that, maybe like an option to exclude client-side scripts on a server, selectively (like, allow scripts for Command Console views and such, but do not allow scripts for weapons)?
Dev posts are great. Although it might just be me, as I'm a programmer, so I kinda like the whole code idea from the beginning <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
The important part to remember is that the client's state and the server's state are maintained semi-independently with updates. Say the player starts shooting at a skulk, here is a breakdown of what happens:
1) The client shows the gun firing, does hit detection based on the location of everything for the T amount of time the gun was fired in directions X, Y, and Z. It shows the green goo if it hits.
2) The client sends a message to the server telling it that the user held the mouse for T amount of time while pointed in direction X, Y, Z.
3) The server independently determines if firing for T time in X, Y, and Z would have hit something, and tells the client exactly what happened.
4) The client updates what it is displaying to correspond with what the server is telling it. This is, at least most of the time, how people can shoot you around walls. Your client allowed you to move until the server decided you were dead, and by the time all that happened you had moved past the corner.
Granted, it is probably a little more complicated than this, but that is generally how it works. It would be impossible to make an ubergun or infinite ammo client side as the client is only telling the server what the user did and trying to predict how the server would respond while it waits for an answer. The server is always firmly in charge, so there is no need to worry about it.
The only thing I can think of is that with server-side hit detection, you see what is ACTUALLY happening. If you hide right around a corner, you for a fact know you won't get shot as opposed to client-side hit detection where it "predicts" and cause you to die even if you hide right around a corner. Am I right?
EDIT: Read this, made lots of sense:
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->
Client-side - like HL, Doom, UT and others - means that it is your client (the part of the game that's running on your computer) that decides whether you hit or not. Your client takes the information it currently has (location of the enemies) and it sees if you shot at that location. If your client thinks you did, then it sends information to the server saying that you shot that target. This way, you don't lead targets due to network latency, since the detection is performed on your computer.
With this method however, the server relies on the client (on your computer) to tell it whether you hit or not... and "altered" clients can fool the server and tell the server that you always hit. Hence the abundance of aimbots and "accuracy-hacks" for client-side-detection games.
Server-side - Like BF42 and BFV - means that the server decides whether you scored a hit or not. The client on your computer doesn't tell the server that it hit the target. Instead, the client sends the information to the server specifying where you fired at. Then when the server receives that information, it is the server that checks whethere there is a target at that location or not. If there is a target, then the server registers the hit, and sends you "feeback" (the flashing crosshair) indicating that it had registered the hit.
Problem with this method is that it takes time before the information of where you fired at reaches the server (unlike client-side where the detection happens directly on the client), so when you fired at coordinate, say 10, because the target was at coordinate 10, by the time this information reached the server (your ping time), the target may have moved to coordinate 11, and the server will think that you missed. Hence with server-side hit-detection, you had to lead ahead, account for this delay that takes time for the transfer of information. So, the higher your ping, the more you have to lead by.
This method is more secure though, since there is little ways in which your client could fool the server to think that you hit when it didn't. And hence, any cries of "aimbots" and "accuracy hacks" for BF42 and BFV are completely absurd and only show the ignorance of those that cry about them (they are virtually impossible with server-side hit-detection)
<!--QuoteEnd--></div><!--QuoteEEnd-->
Dunno how many of you played Gears of War, but when you shoot your gun, it takes like a half a second for it to make a dent in the texture. That tells me that it uses server side hit detection, more secure, harder to cope with.
This is also what Reese was talking about: server-side hit detection.
Thank god, NS1 is client side since its hard to kill aliens as it is. Image if you had to lead them. rofl. The drawback: there is more hacking.
Great update Max, love the backstory. One question though: if everything is running as scripts and not as compiled code, will there be a slow-down as the script has to be dynamically converted to executions? All the opportunities that scripting allows for customization is great, but what is the cost in terms of system resources?
<!--QuoteEnd--></div><!--QuoteEEnd-->
As far as scripting languages go, Lua is pretty fast. In general, games can be divided into two parts: rendering and behavior. The rendering is all being done by Source (in compiled code), so we don't really need to worry about that. I'm going to say that behavior includes all of the networking, which the networking tasks are also being handled by Source in compiled code, so it isn't really a problem. The rest of the behavior is the code that governs how the game actually works, this is what is being written in Lua.. (I.E. what happens when the players presses +use on the armory, among other things).
In games with AI behavior code can get memory and/or processor intensive, as sophisticated AI takes a lot of resources. Since natural-selection is an entirely multiplayer game, the behavior is relatively simple. For example, the behavior code is relatively modest compared to the hit detection code used by Source, which is highly advanced and looks at player positions back in time to try and compensate for lag. I can almost guarantee that hit detection is a more expensive task considering how often it happens.
As an added bonus, Lua is a much easier language to write in. Essentially the NS developers are trading speed that they don't really need for a better language to write their code in. One of the benefits here is that Lua practically guarantees that memory is handled correctly, which makes code written in it significantly less likely to experience a memory leak. There are whole classes of potential mistakes (which are easy to make and hard to find in C++) that simply don't exist in Lua. Overall I think this is a very good decision, and have no doubts about the performance we will see from it.
On another note:
My machine isn't anything to write home about, and I always notice that my NS1 hiccups the first time I bring up my minimap after the game's started, or the first time I round a corner and see the first observatory my client loads. I know little about how all of this works, but my assumption is that the delay (negligible though it be) is due to the loading, during my gameplay, of certain models and sprites.
So I ask: is it possible, in NS past or future, to load allllll of the sprites/models/scripts/etc while the map is loading? If not, why (too taxing on the box/network/somethingelse, maybe)?
<!--QuoteEnd--></div><!--QuoteEEnd-->
That's exactly what causes the pauses - caching the models, sounds, sprites, etc. Look at the pistol code. Three of the lines specify when resources should get cached.
It is very possible to load all the resources that could be needed for the duration of the game during load time. The guaranteed drawback is a longer load time while the map launches. Also, more memory would be taken up by the various resources that get loaded. If you precache everything, but not all of it gets used, more memory will be used up than was needed.
Basically, it comes down to load time and memory usage - is it worth it? That becomes preference, in most cases.
So is this where the differences between client-side hit detection vs server-side hit detection really shine? Most games I know are client side (all half life 1 mods and source games) but there are a few that aren't like Gears of War. I sorta know how each works but still sorta confused, lol. Can someone explain to me the pros and cons of each.
The only thing I can think of is that with server-side hit detection, you see what is ACTUALLY happening. If you hide right around a corner, you for a fact know you won't get shot as opposed to client-side hit detection where it "predicts" and cause you to die even if you hide right around a corner. Am I right?
EDIT: Read this, made lots of sense:
Dunno how many of you played Gears of War, but when you shoot your gun, it takes like a half a second for it to make a dent in the texture. That tells me that it uses server side hit detection, more secure, harder to cope with.
This is also what Reese was talking about: server-side hit detection.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Source does not use client-side hit detection. It uses server-side hit detection with client-side "prediction". You can actually turn this off ( "cl_prediction 0" in console) if you want to see what Source games are like without the prediction. The goal of the prediction is to try and smooth over the delay between firing your gun and seeing the results of it. The drawback is that if your client predicts incorrectly the game will magically change when it receives another server update.
I doubt client side prediction could predict that you died and cause it to happen on the server. Updates simply are not pushed from the client to the server. The client may decide your health is "really low", but it will let you run around and send commands until it knows you are dead. The server may decide to ignore any commands you send after it decided you died, but updates generally come fast enough that this isn't really an issue.
You can find detailed information here: <a href="http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html" target="_blank">http://www.valve-erc.com/srcsdk/general/mu...networking.html</a>
Source does not use client-side hit detection. It uses server-side hit detection with client-side "prediction". You can actually turn this off ( "cl_prediction 0" in console) if you want to see what Source games are like without the prediction. The goal of the prediction is to try and smooth over the delay between firing your gun and seeing the results of it. The drawback is that if your client predicts incorrectly the game will magically change when it receives another server update.
I doubt client side prediction could predict that you died and cause it to happen on the server. Updates simply are not pushed from the client to the server. The client may decide your health is "really low", but it will let you run around and send commands until it knows you are dead. The server may decide to ignore any commands you send after it decided you died, but updates generally come fast enough that this isn't really an issue.
You can find detailed information here: <a href="http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html" target="_blank">http://www.valve-erc.com/srcsdk/general/mu...networking.html</a>
<!--QuoteEnd--></div><!--QuoteEEnd-->
I most definitely agree with you, but I was talking about the Half Life 1 engine :/
In terms of security, running scripts on the client doesn't really introduce any new opportunities for cheating. For CS:S, DoD, etc. it's running similar types of code on the client, they're just done in compiled C++ code instead of in Lua. The main reason security isn't an issue is because the client is not authoritative. That is, the client never sends any information to the server other than the input it collects from your mouse and keyboard. The weapon firing code may run on your client, but it doesn't really affect the game state. The result of running the weapon code on the server is what really determines if you hit an enemy. It's also common practice to do a quick check of the files on the client to make sure that they haven't been tampered with, since there are other types of cheating that can be accomplished by monkeying with the local files (like wall hacks or aim bots).
On the topic of performance, Reese summed it up really well. Typically only a small amount of code is performance critical, and that tends to be the lower level stuff like physics simulation and setting up primitives for rendering. If we did find down the road that something we were doing in script was causing a performance drain, we always have the option of converting that to C++ code that we invoke from Lua. Reese also hit the nail on the head about the benefits, and I think I'll be writing some more about that in the near future.
As far as scripting languages go, Lua is pretty fast. In general, games can be divided into two parts: rendering and behavior. The rendering is all being done by Source (in compiled code), so we don't really need to worry about that. I'm going to say that behavior includes all of the networking, which the networking tasks are also being handled by Source in compiled code, so it isn't really a problem. The rest of the behavior is the code that governs how the game actually works, this is what is being written in Lua.. (I.E. what happens when the players presses +use on the armory, among other things).
In games with AI behavior code can get memory and/or processor intensive, as sophisticated AI takes a lot of resources. Since natural-selection is an entirely multiplayer game, the behavior is relatively simple. For example, the behavior code is relatively modest compared to the hit detection code used by Source, which is highly advanced and looks at player positions back in time to try and compensate for lag. I can almost guarantee that hit detection is a more expensive task considering how often it happens.
As an added bonus, Lua is a much easier language to write in. Essentially the NS developers are trading speed that they don't really need for a better language to write their code in. One of the benefits here is that Lua practically guarantees that memory is handled correctly, which makes code written in it significantly less likely to experience a memory leak. There are whole classes of potential mistakes (which are easy to make and hard to find in C++) that simply don't exist in Lua. Overall I think this is a very good decision, and have no doubts about the performance we will see from it.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Thanks for the clarification and illuminating post. I was just wondering because "scripts" are a very large category, including JavaScript (which, based on my experiences with Java, must be terribly slow). Good to hear that Lua is much more efficient. Yeah, without AI, I guess there is a lot of headroom for more resource intensive tasks. I wonder though, if there is a number (2x, 3x, 4x as slow) that compares the performance of compiled C++ to Lua in game.
... It's also common practice to do a quick check of the files on the client to make sure that they haven't been tampered with, since there are other types of cheating that can be accomplished by monkeying with the local files (like wall hacks or aim bots).
<!--QuoteEnd--></div><!--QuoteEEnd-->
so does this mean that only a server can allow client side ui script mods?
Thanks for the clarification and illuminating post. I was just wondering because "scripts" are a very large category, including JavaScript (which, based on my experiences with Java, must be terribly slow). Good to hear that Lua is much more efficient. Yeah, without AI, I guess there is a lot of headroom for more resource intensive tasks. I wonder though, if there is a number (2x, 3x, 4x as slow) that compares the performance of compiled C++ to Lua in game.
<!--QuoteEnd--></div><!--QuoteEEnd-->
It looks like that number is <a href="http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=lua" target="_blank">somewhere in the 25x range</a> That said, as Max mentioned, the Lua code is a small fraction of the entire game, and is nowhere near performance sensitive. Also, don't take that benchmark at face value, there are a lot more smart C++ programmers updating it than there are smart Lua programmers. I'm guessing generally it is 10-15x slower, which is well worth the benefits of having a better language to program in for this case.
It sounds a bit dangerous, in terms of creating too good uis which would be considered hacking, but if you could limit the possibilities so that players could not create "hacks" with scripting, it would be pretty darn good!
- Garo
and year, the cheating point is dangerous.
Because user can made lua scripts that allow complex scripts to use e.g. bunnyhopping by one button or something.
i know the client calls the server, thats the point.
The server don't know if the player pressing buttons or lua?!