puzlThe Old FirmJoin Date: 2003-02-26Member: 14029Retired Developer, NS1 Playtester, Forum Moderators, Constellation
half-life 1 also has client side hit prediction and server side hit calculations with lag compensation. The source mechanism is not wildly different from the half-life one.
Another great blog update guys. Ensuring consistency on the client might be best achieved by having the server transmit the client side components during map initialisation. This would have the added benefit of allowing server side lua mod developers to customise the client side components.
I too share moultano's concern, in that some of the focus of the initial development will be on maturing the lua platform. We use abstraction layers a lot at the day job, and our golden rule is to never allow a limitation in an abstraction layer to deter you from a preferred solution to a problem.
Great entry again. While I'm excited that users will be able to contribute new features to the game, I'm a bit worried that NS servers will overflow with unnecessary addons. It's hard to find CS servers these days that don't have a Warcraft mod, statistics, and a bunch of Quake-like sounds which take 5 minutes to load - I would hate to see that happen to NS.
If you allow networking between client- and server side scripts, isn't the communication limited to a defined API?
The server always expects a defined payload or am I wrong?
So why should a client be able to alter the client-side communication?
The only benefit would be to be able to directly react on server-side messages on the client side.
So you could write a message each time the server tells you, that you aren't synchronized, or similar.
Changeing topic: How do you make sure every client, who joins a server has the right client-side scripts, to react on server-side mods? Or are you planning to limit server-side scripts to the same amount like NS1 Mods are limited now? (Like if a server supports a special command, each client has to bind it himself)
Very great post, please continue to report your progress to the community!
<!--quoteo(post=1634803:date=Jun 20 2007, 03:58 AM:name=puzl)--><div class='quotetop'>QUOTE(puzl @ Jun 20 2007, 03:58 AM) [snapback]1634803[/snapback]</div><div class='quotemain'><!--quotec--> half-life 1 also has client side hit prediction and server side hit calculations with lag compensation. The source mechanism is not wildly different from the half-life one.
Another great blog update guys. Ensuring consistency on the client might be best achieved by having the server transmit the client side components during map initialisation. This would have the added benefit of allowing server side lua mod developers to customise the client side components.
I too share moultano's concern, in that some of the focus of the initial development will be on maturing the lua platform. We use abstraction layers a lot at the day job, and our golden rule is to never allow a limitation in an abstraction layer to deter you from a preferred solution to a problem. <!--QuoteEnd--></div><!--QuoteEEnd-->
Puzl are you talking about the new "cl_pure 1" command for Source that forces certain settings on the client? Or am i completely off?
puzlThe Old FirmJoin Date: 2003-02-26Member: 14029Retired Developer, NS1 Playtester, Forum Moderators, Constellation
edited June 2007
No, I'm talking about an addition to the engine that would result in the server transmitting the script to the client as part of the precache. The scripts present in the client side assets would simply by ignored when connecting to a server, and lua mod writers would have an easy job enhancing client side scripting because they would only need to deploy their mod on the server. It might make sense to lock out client customisations completely, but I think there is room for a certain amount of flexibility on the client. For example, the game client could define a set of hooks that are invoked at various stages. These hooks would be implemented as a set of lua scripts in a the users configuration. For example, a script could be executed when a player switches role, passing the name of the new role as an argument. This would allow the user to select a variety of customisations including, and not limited to key bindings and visibility of hud components.
<b>Suggestion: Client enhanced effects</b> Make some client side scripting available, which would allow 3rd party effects and animations for certain events.
I am pretty sure you would get the attention of the community if people could make their own "death scripts" with home-grown animations and sounds. I personally like to play Skulk ... and I would give a lot to see custom effects when I chew up a marine. Extra gory effects and screams, bodies cut in half, on the floor, etc. All just as extra client-side “bonus” which doesn’t bother the game in any way – it just enhances the gaming experience for the player.
I realise you deliberately made the game “less-gory”, but allowing people to make custom client-side scripts with these effects could go a long way... and since nobody has done this before, it would be the second time you introduced new and cutting-edge concepts for the FPS genre. That kind of thing generally gives good publicity.
There is loads of stuff which could enhance the game in this way. And allowing the community to make these things themselves would save you guys a ton of work – and make people happier at the same time. Everybody wins. …! Buildings crashing when they are destroyed, aliens splattered by grenades, marines inhaling gas, offence chambers firing … personally I would probably even consider buying these effects from the developers.
Awesome blog update! <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /> Client side and server-side scripts would be quite the same wouldn't they? They should both keep track of amount of bullets, reloading and that stuff, but in the end the client side code is only there to prevent the server from being hammered with shooting events if the player is reloading and to make the game feel responsive to any action taken even though its effects takes about 50-100+ milliseconds to be verified.
Clientside = prettyness - tells the player what the server told it Serverside = where the party is at! - verifies that the info sent from the client is valid and updates game-state and tells all other clients.
<!--quoteo(post=1634781:date=Jun 20 2007, 07:13 AM:name=Reese)--><div class='quotetop'>QUOTE(Reese @ Jun 20 2007, 07:13 AM) [snapback]1634781[/snapback]</div><div class='quotemain'><!--quotec--> 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. <!--QuoteEnd--></div><!--QuoteEEnd--> Yes, so this confirms that you can't write a game engine in Lua, but that it works fine for small applications. Thanks Reese. I wonder what the JavaScript equivalent would be <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
JavaScript is slower, and either some of the things available in Lua are nonexistent, or are implemented rather strangely. The NS team is probably better able to change Lua to support the kind of development they want to do than they can JavaScript. Sorry if I am kind of dominating this thread, I'm a bit of a language buff and am really excited when I see for-profit companies using languages that I find interesting. (or at least trading the speed of C++ for better language features where they can)
<!--quoteo(post=1634764:date=Jun 19 2007, 10:46 PM:name=AnimeLOL)--><div class='quotetop'>QUOTE(AnimeLOL @ Jun 19 2007, 10:46 PM) [snapback]1634764[/snapback]</div><div class='quotemain'><!--quotec--> I was just wondering because "scripts" are a very large category, including JavaScript (which, based on my experiences with Java, must be terribly slow). <!--QuoteEnd--></div><!--QuoteEEnd-->
Despite the name, Javascript and Java are entirely seperate languages. The only thing shared between the two is the name. (Which came from an early Netscape/Sun deal or something and stuck.) ECMAScript is its official standardized name.
Edit: Since I'm horribly off topic, just check out the <a href="http://en.wikipedia.org/wiki/Javascript" target="_blank">Wikipedia entry</a> for more infos!
So am I right in believing now that server operators will now have the option to provide fully customised weapons & structures? Can these scripts be downloaded from the server and installed automatically by my client like other game resources?
eg. Could I join a superman custom server, which gives every player a cape of flight and an eye-laser weapon whenever they use the superifying building (which all have custom models and sound effects), without having to download or install anything manually? And I can have a custom UI that doesn't interfere with that to boot?
Hmmn, out of curiousity MaX, if you guys have tested at all yet, how does the LUA CPU usage stack up to the equivilent built into the engine through C++? Taking Garry's mod as an example, the LUA scripting is an entire exponential level worse on the server end, and noticeably worse on client as well, though many of the things that are LUA coded in Gmod are what might be termed as 'experimental', so it's not the best reference.
And only somewhat related, is any level of modifaction 'too much' to give to users in your/the development team's perspective? Gmod for instance has virtually all of its elements open to modification, where as other mods/games that allow user created content have some level of limits on them.
Interesting read. Especially the part about client-server interaction. Do you have an approach on the "delayed" death we have often seen in HL1 (and of course NS).
While the average player kills a skulk with the first 15 LMG rounds he normally fires an additional 10 rounds, because the death notice needs to actually be transmitted from server to client and is not predicted.
GISPBattle GorgeDenmarkJoin Date: 2004-03-20Member: 27460Members, Playtest Lead, Forum Moderators, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, NS2 Map Tester, Reinforced - Onos, WC 2013 - Gold, Subnautica Playtester, Forum staff
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec--> 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.<!--QuoteEnd--></div><!--QuoteEEnd-->
Meaning a single player expansion is out of the question, or not hapeing in relativ "neer future"after the release?
<!--quoteo(post=1635400:date=Jun 23 2007, 07:34 AM:name=GISP)--><div class='quotetop'>QUOTE(GISP @ Jun 23 2007, 07:34 AM) [snapback]1635400[/snapback]</div><div class='quotemain'><!--quotec--> Meaning a single player expansion is out of the question, or not hapeing in relativ "neer future"after the release? <!--QuoteEnd--></div><!--QuoteEEnd-->
Right. Single player would be a huge amount of work.
<!--quoteo(post=1634731:date=Jun 19 2007, 11:03 PM:name=cerberus5)--><div class='quotetop'>QUOTE(cerberus5 @ Jun 19 2007, 11:03 PM) [snapback]1634731[/snapback]</div><div class='quotemain'><!--quotec--> 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. <!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec--> 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-->
Just to let you know the source you quoted doesnt know what he is talking about.
He should research what he is on about before he goes around calling people ignorant
Aimbots arent based on network communication, they are based on what is on the screen (looking at models and colours), entirely client side on any game.
<!--quoteo(post=1634731:date=Jun 19 2007, 11:03 PM:name=cerberus5)--><div class='quotetop'>QUOTE(cerberus5 @ Jun 19 2007, 11:03 PM) [snapback]1634731[/snapback]</div><div class='quotemain'><!--quotec--> 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. <!--QuoteEnd--></div><!--QuoteEEnd-->
Again, I assumed you have come to that conclusion from reading this: <a href="http://forums.filefront.com/battlefield-2-general-discussion/199233-server-side-client-side-hit-detection.html" target="_blank">http://forums.filefront.com/battlefield-2-...-detection.html</a>
A one-shot "tranquilliser dart". It makes sense that this may fit on a pistol and can add a cool new feature to the Pistol. I envision it slowing an enemy Alien down for X seconds. To keep it from being overpowered give it a 2 or 3 second time to take effect.
Possible Variants: -It could have a stronger effect on smaller Aliens (ie immobilising them for a short time). -Could slow fire rate of an Alien defensive structure that's hit. -Could drain Alien "Energy Bar" instead of slowing the Alien.
I'm thinking that for most encounters this would not have a huge impact on gameplay; however, in certain situations it could be just what the Marines need. For example: a rampaging early game Onos that chages in and out of a marine base could be tranq'd. It would have a harder tame continually popping back out of the marine base to go heal. Similarly a Blinking Fade that bounces around marine base wiping everyone out then Blinking out to heal could be slowed down by a tranq and give marines a chance at taking him down before he gets away.
Often the marine that fires off the tranq might not survive the encounter, but he gives his teammates a chance of taking out the big threat.
I'm sure there are some other big pro's and con's for an alt-fire like this (It may be a pain in the ass to impelment for all I know). Let's hear your thoughts!
Comments
Another great blog update guys. Ensuring consistency on the client might be best achieved by having the server transmit the client side components during map initialisation. This would have the added benefit of allowing server side lua mod developers to customise the client side components.
I too share moultano's concern, in that some of the focus of the initial development will be on maturing the lua platform. We use abstraction layers a lot at the day job, and our golden rule is to never allow a limitation in an abstraction layer to deter you from a preferred solution to a problem.
If you allow networking between client- and server side scripts, isn't the communication limited to a defined API?
The server always expects a defined payload or am I wrong?
So why should a client be able to alter the client-side communication?
The only benefit would be to be able to directly react on server-side messages on the client side.
So you could write a message each time the server tells you, that you aren't synchronized, or similar.
Changeing topic:
How do you make sure every client, who joins a server has the right client-side scripts, to react on server-side mods? Or are you planning to limit server-side scripts to the same amount like NS1 Mods are limited now? (Like if a server supports a special command, each client has to bind it himself)
Very great post, please continue to report your progress to the community!
half-life 1 also has client side hit prediction and server side hit calculations with lag compensation. The source mechanism is not wildly different from the half-life one.
Another great blog update guys. Ensuring consistency on the client might be best achieved by having the server transmit the client side components during map initialisation. This would have the added benefit of allowing server side lua mod developers to customise the client side components.
I too share moultano's concern, in that some of the focus of the initial development will be on maturing the lua platform. We use abstraction layers a lot at the day job, and our golden rule is to never allow a limitation in an abstraction layer to deter you from a preferred solution to a problem.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Puzl are you talking about the new "cl_pure 1" command for Source that forces certain settings on the client? Or am i completely off?
Make some client side scripting available, which would allow 3rd party effects and animations for certain events.
I am pretty sure you would get the attention of the community if people could make their own "death scripts" with home-grown animations and sounds. I personally like to play Skulk ... and I would give a lot to see custom effects when I chew up a marine. Extra gory effects and screams, bodies cut in half, on the floor, etc. All just as extra client-side “bonus” which doesn’t bother the game in any way – it just enhances the gaming experience for the player.
I realise you deliberately made the game “less-gory”, but allowing people to make custom client-side scripts with these effects could go a long way... and since nobody has done this before, it would be the second time you introduced new and cutting-edge concepts for the FPS genre. That kind of thing generally gives good publicity.
There is loads of stuff which could enhance the game in this way. And allowing the community to make these things themselves would save you guys a ton of work – and make people happier at the same time. Everybody wins. …! Buildings crashing when they are destroyed, aliens splattered by grenades, marines inhaling gas, offence chambers firing … personally I would probably even consider buying these effects from the developers.
:-)
- Jesper
Client side and server-side scripts would be quite the same wouldn't they? They should both keep track of amount of bullets, reloading and that stuff, but in the end the client side code is only there to prevent the server from being hammered with shooting events if the player is reloading and to make the game feel responsive to any action taken even though its effects takes about 50-100+ milliseconds to be verified.
Clientside = prettyness - tells the player what the server told it
Serverside = where the party is at! - verifies that the info sent from the client is valid and updates game-state and tells all other clients.
I love hearing more about the development process than the actual game right now...
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.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, so this confirms that you can't write a game engine in Lua, but that it works fine for small applications. Thanks Reese. I wonder what the JavaScript equivalent would be <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
I was just wondering because "scripts" are a very large category, including JavaScript (which, based on my experiences with Java, must be terribly slow).
<!--QuoteEnd--></div><!--QuoteEEnd-->
Despite the name, Javascript and Java are entirely seperate languages. The only thing shared between the two is the name. (Which came from an early Netscape/Sun deal or something and stuck.) ECMAScript is its official standardized name.
Edit: Since I'm horribly off topic, just check out the <a href="http://en.wikipedia.org/wiki/Javascript" target="_blank">Wikipedia entry</a> for more infos!
eg. Could I join a superman custom server, which gives every player a cape of flight and an eye-laser weapon whenever they use the superifying building (which all have custom models and sound effects), without having to download or install anything manually? And I can have a custom UI that doesn't interfere with that to boot?
And only somewhat related, is any level of modifaction 'too much' to give to users in your/the development team's perspective? Gmod for instance has virtually all of its elements open to modification, where as other mods/games that allow user created content have some level of limits on them.
While the average player kills a skulk with the first 15 LMG rounds he normally fires an additional 10 rounds, because the death notice needs to actually be transmitted from server to client and is not predicted.
Meaning a single player expansion is out of the question, or not hapeing in relativ "neer future"after the release?
Meaning a single player expansion is out of the question, or not hapeing in relativ "neer future"after the release?
<!--QuoteEnd--></div><!--QuoteEEnd-->
Right. Single player would be a huge amount of work.
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.
<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->
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-->
Just to let you know the source you quoted doesnt know what he is talking about.
He should research what he is on about before he goes around calling people ignorant
Aimbots arent based on network communication, they are based on what is on the screen (looking at models and colours), entirely client side on any game.
<!--quoteo(post=1634731:date=Jun 19 2007, 11:03 PM:name=cerberus5)--><div class='quotetop'>QUOTE(cerberus5 @ Jun 19 2007, 11:03 PM) [snapback]1634731[/snapback]</div><div class='quotemain'><!--quotec-->
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.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Again, I assumed you have come to that conclusion from reading this: <a href="http://forums.filefront.com/battlefield-2-general-discussion/199233-server-side-client-side-hit-detection.html" target="_blank">http://forums.filefront.com/battlefield-2-...-detection.html</a>
A one-shot "tranquilliser dart". It makes sense that this may fit on a pistol and can add a cool new feature to the Pistol. I envision it slowing an enemy Alien down for X seconds. To keep it from being overpowered give it a 2 or 3 second time to take effect.
Possible Variants:
-It could have a stronger effect on smaller Aliens (ie immobilising them for a short time).
-Could slow fire rate of an Alien defensive structure that's hit.
-Could drain Alien "Energy Bar" instead of slowing the Alien.
I'm thinking that for most encounters this would not have a huge impact on gameplay; however, in certain situations it could be just what the Marines need. For example: a rampaging early game Onos that chages in and out of a marine base could be tranq'd. It would have a harder tame continually popping back out of the marine base to go heal. Similarly a Blinking Fade that bounces around marine base wiping everyone out then Blinking out to heal could be slowed down by a tranq and give marines a chance at taking him down before he gets away.
Often the marine that fires off the tranq might not survive the encounter, but he gives his teammates a chance of taking out the big threat.
I'm sure there are some other big pro's and con's for an alt-fire like this (It may be a pain in the ass to impelment for all I know). Let's hear your thoughts!