<!--quoteo(post=0:date=:name=Twitter)--><div class='quotetop'>QUOTE (Twitter)</div><div class='quotemain'><!--quotec-->Max and Dushan are scaring me with their talk of hand-writing a new Lua VM in assembly, to hyper-optimize NS2. Monsters.<!--QuoteEnd--></div><!--QuoteEEnd--> A new VM again? (see Build 171-2-3 or so), and in assembly no less? Seems a bit non-sensical for several reasons. You mustn't have been sitting close enough while eavesdropping.
<!--quoteo(post=0:date=:name=Twitter)--><div class='quotetop'>QUOTE (Twitter)</div><div class='quotemain'><!--quotec-->Brian just removed tons of unnecessary network messages by moving footstep sounds to the client<!--QuoteEnd--></div><!--QuoteEEnd--> I suppose that's not so much of an issue in NS2. I wonder how it was handled in NS1, although I would guess server-side, as hearing foot-steps formed an incredibly important gameplay-factor which you couldn't afford to let the clients handle themselfs (with all the inevitable inconsistencies).
<!--quoteo(post=1885605:date=Nov 18 2011, 07:29 PM:name=player)--><div class='quotetop'>QUOTE (player @ Nov 18 2011, 07:29 PM) <a href="index.php?act=findpost&pid=1885605"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I suppose that's not so much of an issue in NS2. I wonder how it was handled in NS1, although I would guess server-side, as hearing foot-steps formed an incredibly important gameplay-factor which you couldn't afford to let the clients handle themselfs (with all the inevitable inconsistencies).<!--QuoteEnd--></div><!--QuoteEEnd-->
Not sure it would be that inconsistent, you just need the clients to know the locations/velocities of other players (which they should know anyhow) then the client can decide when/where to play footstep noises.
Correct, however not all clients have 0ms of lag and a 0% packet-loss, so tiny variations of player-positions\behaviour\speed\whatnot will always happen, and sometimes that could certainly lead to one client hearing a single foot-step, while the other one does not, which was\is unacceptable in NS1.
It's not a perfect world, and you kind of need to build your game expecting crappy internet-connections.
ZeikkoJoin Date: 2007-12-16Member: 63179Members, Squad Five Blue, NS2 Map Tester
<!--quoteo(post=1885607:date=Nov 19 2011, 03:41 AM:name=player)--><div class='quotetop'>QUOTE (player @ Nov 19 2011, 03:41 AM) <a href="index.php?act=findpost&pid=1885607"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Correct, however not all clients have 0ms of lag and a 0% packet-loss, so tiny variations of player-positions\behaviour\speed\whatnot will always happen, and sometimes that could certainly lead to one client hearing a single foot-step, while the other one does not, which was\is unacceptable in NS1.
It's not a perfect world, and you kind of need to build your game expecting crappy internet-connections.<!--QuoteEnd--></div><!--QuoteEEnd--> How is this different if the footstep messages are received as messages from the server? Those messages can be lost and delayed aswell.
I may have misheard about the VM, but they can fill you in on the details when and if it's happening. We do know that Lua performance is the biggest culprit at the moment so we're willing to do a lot to reduce it's execution time.
<!--quoteo(post=1885614:date=Nov 18 2011, 07:49 PM:name=Flayra)--><div class='quotetop'>QUOTE (Flayra @ Nov 18 2011, 07:49 PM) <a href="index.php?act=findpost&pid=1885614"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I may have misheard about the VM, but they can fill you in on the details when and if it's happening. We do know that Lua performance is the biggest culprit at the moment so we're willing to do a lot to reduce it's execution time.<!--QuoteEnd--></div><!--QuoteEEnd-->
Is it really straight-up execution time that's the issue? I thought most of the hitching issues were a result of the garbage collector running, but I guess that would be solved with a new VM too. Anyhow, that sounds like a pretty cool idea. You guys would basically have straight-up remade the lua language from the ground up for optimized use in game scripting. Sounds highly licensable ;)
ASM programming? Don't envy you. That's like trying to build a car by welding iron filings together.
Although I was under the impression that assembly language is unique to every processor? Didn't know you could write a generic assembly program.
<!--quoteo(post=1885619:date=Nov 19 2011, 02:04 AM:name=cmc5788)--><div class='quotetop'>QUOTE (cmc5788 @ Nov 19 2011, 02:04 AM) <a href="index.php?act=findpost&pid=1885619"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Is it really straight-up execution time that's the issue? I thought most of the hitching issues were a result of the garbage collector running, but I guess that would be solved with a new VM too. Anyhow, that sounds like a pretty cool idea. You guys would basically have straight-up remade the lua language from the ground up for optimized use in game scripting. Sounds highly licensable ;)<!--QuoteEnd--></div><!--QuoteEEnd-->
From what I understand about how games work, they have to feed the game code to the lua interpreter, the virtual machine, which feeds them to the engine, which feeds it to the APIs, which feed it to the computer.
Most games don't have the lua layer, it's adding a whole set of complications on top of the engine itself.
It's like if you'e ever done anything in java or flash, they run in their own weird player thing, which is why they're both really inefficient. It means they're easy to write for and fairly cross-platform, but it incurs a running cost.
Leastways that's how I was under the impression it worked.
<!--quoteo(post=1885622:date=Nov 18 2011, 08:14 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Nov 18 2011, 08:14 PM) <a href="index.php?act=findpost&pid=1885622"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->ASM programming? Don't envy you. That's like trying to build a car by welding iron filings together.
Although I was under the impression that assembly language is unique to every processor? Didn't know you could write a generic assembly program.
From what I understand about how games work, they have to feed the game code to the lua interpreter, the virtual machine, which feeds them to the engine, which feeds it to the APIs, which feed it to the computer.
Most games don't have the lua layer, it's adding a whole set of complications on top of the engine itself.
It's like if you'e ever done anything in java or flash, they run in their own weird player thing, which is why they're both really inefficient. It means they're easy to write for and fairly cross-platform, but it incurs a running cost.
Leastways that's how I was under the impression it worked.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah I know what a virtual machine is, sorry if I gave the impression that I didn't. I don't know enough about NS2 to make specific claims, but it seems to me like game logic tends to generate a lot of garbage very quickly, which is why garbage collector hitching would be a big deal. The mere fact of code running in a VM doesn't necessarily make the language a great deal more inefficient -- some JIT implementations can run faster than compiled code in specific circumstances.
Most games have some scripting layer. The Unreal engine being the most heavily used engine on the planet.
Have you reevaluated ALL common code patterns to see if more can be offloaded into C/C++ land? A common theme with Unreal Engine licensees is to build too much of the game in UnrealScript and then start moving parts into the engine.
Is it primarily execution...or is it still a problem with actual GC? This was a great article on LUA GC management...and tracking hotspots. <a href="http://altdevblogaday.com/2011/08/09/fixing-memory-issues-in-lua/" target="_blank">http://altdevblogaday.com/2011/08/09/fixin...-issues-in-lua/</a>
Can the coders be educated to write better code? I know when I learned more about assembly I wrote better code. I know when I learned more about IL I wrote better C# code.
Most games have SOME scripting but they don't generally write the entire game code in it. UWE are doing that for ease of programming and also so the game is entirely moddable. It's having some understandable side effects.
The tweet is a bit misleading. I've been investigating a number of different options related to Lua performance for the past few months, but I'm not ready to talk about them yet.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
I never understood why luajit was dropped. Ok, there was the custom c++/lua interface max wrote, but the switch from luajit to lua+custom c++ interface did not change the performance when i recal correctly. On the other hand from what i see, luajit is actively developed and gets faster with every release. Shouldn't it be tried again?
<!--quoteo(post=1885656:date=Nov 19 2011, 09:29 AM:name=Asraniel)--><div class='quotetop'>QUOTE (Asraniel @ Nov 19 2011, 09:29 AM) <a href="index.php?act=findpost&pid=1885656"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I never understood why luajit was dropped. Ok, there was the custom c++/lua interface max wrote, but the switch from luajit to lua+custom c++ interface did not change the performance when i recal correctly. On the other hand from what i see, luajit is actively developed and gets faster with every release. Shouldn't it be tried again?<!--QuoteEnd--></div><!--QuoteEEnd--> LuaJIT was one of the main reasons why I thought it to be a bit silly to dive into assembly. Assembly would be one of the last things you could try in a desperate attempt to speed up code, and current-gen compilers are very good indeed at generating assembly, so the chances you could write a faster asm routine than the compiler (!! and which warrants the effort you have to put in !!) are not that high. Usually doing that is reserved for some very specific algorithm or possible some functionality that isn't properly exposed by a high-level language API yet.
<!--quoteo(post=0:date=:name=kingmob)--><div class='quotetop'>QUOTE (kingmob)</div><div class='quotemain'><!--quotec-->Can the coders be educated to write better code?<!--QuoteEnd--></div><!--QuoteEEnd--> Yyyyyyes! /heavy There are a number of articles out there that demonstrate very subtle chances to the Lua-script that can yield a surprising amount of performance\less memory-usage. Of course this also depends on how the VM behaves, which I believe NS2 has a custom-version of already.
<!--quoteo(post=0:date=:name=Syli)--><div class='quotetop'>QUOTE (Syli)</div><div class='quotemain'><!--quotec-->but you can also give the modder a API over c++ or c or even .net. clearly harder but performence wise (i think) better<!--QuoteEnd--></div><!--QuoteEEnd--> And a +1 to that If only for some of the functionality that is locked in the engine. Speed-wise there isn't that much to gain I think (usually you're mostly interacting with the game-logic to do your thing, which is simply Lua).
<!--quoteo(post=0:date=:name=Zeikko )--><div class='quotetop'>QUOTE (Zeikko )</div><div class='quotemain'><!--quotec-->How is this different if the footstep messages are received as messages from the server? Those messages can be lost and delayed aswell.<!--QuoteEnd--></div><!--QuoteEEnd--> True I guess, perhaps they're sent realiably and are allowed to arrive late to the party.
[EDIT] Just to clarify, with realiably I mean those packets are in fact sent multiple times over in case 1 or 2 of them are lost. Spark does this too with at least the chat-messages\tooltips.
fsfodukJoin Date: 2004-04-09Member: 27810Members, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Subnautica Playtester, NS2 Community Developer, Pistachionauts
<!--quoteo(post=1885656:date=Nov 19 2011, 08:29 AM:name=Asraniel)--><div class='quotetop'>QUOTE (Asraniel @ Nov 19 2011, 08:29 AM) <a href="index.php?act=findpost&pid=1885656"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I never understood why luajit was dropped. Ok, there was the custom c++/lua interface max wrote, but the switch from luajit to lua+custom c++ interface did not change the performance when i recal correctly. On the other hand from what i see, luajit is actively developed and gets faster with every release. Shouldn't it be tried again?<!--QuoteEnd--></div><!--QuoteEEnd-->
This is my sentiment exactly. I don't think ns2 got much of the its lua code jited when it was using luajit because lua C function __index'ers obliterate any chance for luajit to jit code this could be avoided by using pure lua __index'ers and use luajits ffi system to interface to the engine code
This is example of a lot of <a href="http://pastebin.com/3YpzA2an" target="_blank">failed traces</a> for the server vm because of C __index functions or normal C lua functions
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
<!--quoteo(post=1885711:date=Nov 19 2011, 05:55 PM:name=fsfod)--><div class='quotetop'>QUOTE (fsfod @ Nov 19 2011, 05:55 PM) <a href="index.php?act=findpost&pid=1885711"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->This is my sentiment exactly. I don't think ns2 got much of the its lua code jited when it was using luajit because lua C function __index'ers obliterate any chance for luajit to jit code this could be avoided by using pure lua __index'ers and use luajits ffi system to interface to the engine code
This is example of a lot of <a href="http://pastebin.com/3YpzA2an" target="_blank">failed traces</a> for the server vm because of C __index functions or normal C lua functions<!--QuoteEnd--></div><!--QuoteEEnd-->
Interesting, can you tell me what i'm looking at here? how can i create the same trace? so that i can google for more information.
<!--quoteo(post=1885656:date=Nov 19 2011, 01:29 AM:name=Asraniel)--><div class='quotetop'>QUOTE (Asraniel @ Nov 19 2011, 01:29 AM) <a href="index.php?act=findpost&pid=1885656"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I never understood why luajit was dropped. Ok, there was the custom c++/lua interface max wrote, but the switch from luajit to lua+custom c++ interface did not change the performance when i recal correctly. On the other hand from what i see, luajit is actively developed and gets faster with every release. Shouldn't it be tried again?<!--QuoteEnd--></div><!--QuoteEEnd--> We lost some performance by switching away from luajit, but we gained performance by using our custom binding layer. The net was a slight performance improvement and much better garbage collection behavior.
Because of the nature of our system (lots of mixed Lua and C++), the benefit of luajit isn't the actual JIT part which will not run, it's the fact that the VM is written in assembly with SIMD support and direct threading, and they use a smaller value type which is good for the cache (Lua 5.2 beta also has this). The problem with luajit is that the code is incredibly complicated and dense and modifying it is out of the question.
The reason I want to by able to modify the Lua VM, is to get beyond the ~2x-4x performance you get from these core optimizations for running the VM, we need to be able to do some special things with how we transition between C++ and Lua.
<!--quoteo(post=1885683:date=Nov 19 2011, 06:31 AM:name=player)--><div class='quotetop'>QUOTE (player @ Nov 19 2011, 06:31 AM) <a href="index.php?act=findpost&pid=1885683"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->LuaJIT was one of the main reasons why I thought it to be a bit silly to dive into assembly. Assembly would be one of the last things you could try in a desperate attempt to speed up code, and current-gen compilers are very good indeed at generating assembly, so the chances you could write a faster asm routine than the compiler (!! and which warrants the effort you have to put in !!) are not that high. Usually doing that is reserved for some very specific algorithm or possible some functionality that isn't properly exposed by a high-level language API yet.<!--QuoteEnd--></div><!--QuoteEEnd--> That's exactly what we use assembly for, SIMD and <a href="http://en.wikipedia.org/wiki/Threaded_code" target="_blank">direct threading</a> which cannot be done in C. I'm not writing huge amounts of asm, that would be a waste of time.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
<!--quoteo(post=1885743:date=Nov 19 2011, 09:00 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Nov 19 2011, 09:00 PM) <a href="index.php?act=findpost&pid=1885743"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That's exactly what we use assembly for, SIMD and <a href="http://en.wikipedia.org/wiki/Threaded_code" target="_blank">direct threading</a> which cannot be done in C. I'm not writing huge amounts of asm, that would be a waste of time.<!--QuoteEnd--></div><!--QuoteEEnd-->
I once had to optimize a function. Somebody wrote a pure assembler version of it. In the end, i recoded it in C, using instrincs to use the SIMD commands, and it was faster than the hand written assembler code. So i'm just posting this to make sure you know about instrincts, because then you can get away without writing any assemble code, and it will be better optimized by the compiler (usually). Here is the visualstudio reference, gcc uses the same if i remember correctly: <a href="http://msdn.microsoft.com/en-us/library/26td21ds.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/26td21ds.aspx</a>
<!--quoteo(post=0:date=:name= Twitter)--><div class='quotetop'>QUOTE ( Twitter)</div><div class='quotemain'><!--quotec-->Brian just removed tons of unnecessary network messages by moving footstep sounds to the client<!--QuoteEnd--></div><!--QuoteEEnd--> Cool! Are decals and particle effects totally on the client, too?
<!--quoteo(post=1885757:date=Nov 19 2011, 02:44 PM:name=juice)--><div class='quotetop'>QUOTE (juice @ Nov 19 2011, 02:44 PM) <a href="index.php?act=findpost&pid=1885757"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Cool! Are decals and particle effects totally on the client, too?<!--QuoteEnd--></div><!--QuoteEEnd-->
They are both technically only Client side (for rendering) but the Server still sends messages to Clients to tell them to play a particle effect. Decals are triggering entirely Client side right now as far as I can remember.
In some cases (such as footsteps) we can move them entirely to the Client. We can do this whenever the Client already knows when an event happens (such as playing the walk animation for foot steps). In other cases the Server must tell the Client to play a sound or particle effect because it has no other information of the event (such as one player damaging another player).
Great thread. It’s been a while since I’ve written ASM and I stopped coding about ten years ago but I still believe that well written ASM code is still the fastest and most bug free. There needs to be a good reason to do it because it’s time consuming and the attention to detail has to border on compulsion.
I really like the idea of the infestation being the primary way that aliens heal. I guess they will need to sit still on it for a certain amount of time for the healing to begin so that they aren't being constantly healed while dodging marine fire.
Some nice Ideas going on with the infestation. The 3. proto model was most interesting one including the cyst sacrifece and forwarding the mainheal on the infestation. That would change alot in the alien battle dinamic.
Changing the crag passive healing to a lvl 3 cysts would also bring a bigger difference, like Brian mentioned, in the correct chose of alot of lvl 1 or a couple of lvl 3 at the front.
I'm sure those infestation protos are wort't a test. And if you implement tesselation the marinestatues would come true.
I like the only healing on infestation ability, it lends to the aliens being extremely mobile. It also gives the gorge an even more active role on the team.
Some suggesstions:
Each cyst adds a certain amount of infestation, how it spreads is controlled by the player. Let's say I put a cyst at the foot of a doorwar, but I don't want the infestation to spread into the next room. I could tell the infestation to only spread backwards or up a wall.
You wanted some way to show that the infestation was healing. How about slight atmospheric mist that rises above the infestation? You already have some atmospheric effects that you previewed in a previous tweet.
Was there any talk about adding any passive effects for aliens on infestation? Coming from the DC/MC/SC mindset from NS1, you could have a slight armor boost, slight speed boost, or slight damage boost for aliens on creep.
I do like the dynamic infestation becoming a large part of the alien gameplay. You tout it as one of the bigger, more unique features to Natural Selection and this is a great way to do it. Reminiscent of the creep in SC2.
IeptBarakatThe most difficult name to speak ingame.Join Date: 2009-07-10Member: 68107Members, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow
edited November 2011
Could give the crag the heal gas cloud like what is planned for the gorge. Then give the lerk umbra again. :V
Also with the infestation healing, maybe 5-8 seconds of sitting still or sneaking on infestation and being out of harms way, the aliens would start a vastly increased regeneration as if the tentacles on the aliens connected to the infestation to be healed by the hive network. Which would be interrupted by taking damage or moving.
It would be great if the commander could choose what bonus you get on infestation: Like in ns with up to 3 MC/DC/SC.
If commander chose crag as first chamber you get additional healing on infestation and with every additional crag the healing strength(limited count of crags boosting). Crag only heals armor but if the Commander triggers active Heal it sends a healing wave through the infestation. The effect decreases on distance.
Same for shade or whip it boosts the DI. shade does cloaking(more shades --> cloaks faster) when not moving on DI or whip gives extra dmg.
I think my main objection to infestation is that it's too binary.
I really don't like the 'drop cyst, infestation comes out, but cyst is the point of failure' idea, it feels too... not dynamic at all.
I don't know if you ever played black and white 2, but it had a lovely click and drag feature for walls and roads which let you build lovely snaking patterns, I think infestation should work like that, you paint it on the world, not click to drop blobs.
But obviously you do need infestation to still be vulnerable to attack by conventional weapons...
I think either infestation should grow cysts all over it, basically turning it into a very high density version of what you have now, but rather than two or three cysts in a hallway, you'd have maybe 20 or so all over the walls ceiling, and floor, as part of the infestation, not a sepearate thing. Killing a cyst would cause a small patch of infestatiion to die, so you could go down the corridor, and burn a firebreak to sever it from all the surfaces and kill the stuff further back, or shoot the cysts to achieve the same, but area weapons and particularly fire would be best.
I just really don't like the 'digital' infestation, I know it's a game so obviously everything has to have a degre of discreteness, no round surfaces etc, but infestation REALLY needs as much of it as you can get.
If you can't do a much more dense and therefore analog placement system, go further the other way, make cysts much tougher and much bigger, make them like placeable power nodes, or more like NS1 turret factories, with a big area of effect. In that area infestation behaves cosmetically analog, but computationally it is highly discrete. You don't attack the infestation network most of the time, that would be something you do when clearing out a room with a major attack, so there is a lot less of the 'cyst gets dropped, blob grows, cyst dies, blob dies' thing that just feels so not atmospheric.
You could then of course add a more analog behaviour for the surrounding infestation, with it responding to fire and explosions and such, and dying off but regrowing, that sort of thing, but the commander doesn't need to keep interfering with the network. Cyst network maintenence is not a very fun thing to be doing, because when the commander interferes the infestation loses its organic feel.
If you want stuff for the comm to do, give them powers they can trigger from the infestation, or something, but the actual growth of it should be automated and smoothed out as much as possible, less clicking.
I think the dynamic part of the infestation stems from the fact that the front lines of the infestation will always be changing. I'm not totally sure on this but I think Flayra envisions the infestation edge to be something of a contested area with a lot of action concentrated there to control territory. Honestly, how it looks right now and how it is deployed shouldn't be a top priority. How it affects the gameplay should be paramount.
Comments
A new VM again? (see Build 171-2-3 or so), and in assembly no less? Seems a bit non-sensical for several reasons. You mustn't have been sitting close enough while eavesdropping.
<!--quoteo(post=0:date=:name=Twitter)--><div class='quotetop'>QUOTE (Twitter)</div><div class='quotemain'><!--quotec-->Brian just removed tons of unnecessary network messages by moving footstep sounds to the client<!--QuoteEnd--></div><!--QuoteEEnd-->
I suppose that's not so much of an issue in NS2. I wonder how it was handled in NS1, although I would guess server-side, as hearing foot-steps formed an incredibly important gameplay-factor which you couldn't afford to let the clients handle themselfs (with all the inevitable inconsistencies).
Not sure it would be that inconsistent, you just need the clients to know the locations/velocities of other players (which they should know anyhow) then the client can decide when/where to play footstep noises.
It's not a perfect world, and you kind of need to build your game expecting crappy internet-connections.
It's not a perfect world, and you kind of need to build your game expecting crappy internet-connections.<!--QuoteEnd--></div><!--QuoteEEnd-->
How is this different if the footstep messages are received as messages from the server? Those messages can be lost and delayed aswell.
Not sure why it would be non-sensical...
Is it really straight-up execution time that's the issue? I thought most of the hitching issues were a result of the garbage collector running, but I guess that would be solved with a new VM too. Anyhow, that sounds like a pretty cool idea. You guys would basically have straight-up remade the lua language from the ground up for optimized use in game scripting. Sounds highly licensable ;)
Although I was under the impression that assembly language is unique to every processor? Didn't know you could write a generic assembly program.
<!--quoteo(post=1885619:date=Nov 19 2011, 02:04 AM:name=cmc5788)--><div class='quotetop'>QUOTE (cmc5788 @ Nov 19 2011, 02:04 AM) <a href="index.php?act=findpost&pid=1885619"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Is it really straight-up execution time that's the issue? I thought most of the hitching issues were a result of the garbage collector running, but I guess that would be solved with a new VM too. Anyhow, that sounds like a pretty cool idea. You guys would basically have straight-up remade the lua language from the ground up for optimized use in game scripting. Sounds highly licensable ;)<!--QuoteEnd--></div><!--QuoteEEnd-->
From what I understand about how games work, they have to feed the game code to the lua interpreter, the virtual machine, which feeds them to the engine, which feeds it to the APIs, which feed it to the computer.
Most games don't have the lua layer, it's adding a whole set of complications on top of the engine itself.
It's like if you'e ever done anything in java or flash, they run in their own weird player thing, which is why they're both really inefficient. It means they're easy to write for and fairly cross-platform, but it incurs a running cost.
Leastways that's how I was under the impression it worked.
Although I was under the impression that assembly language is unique to every processor? Didn't know you could write a generic assembly program.
From what I understand about how games work, they have to feed the game code to the lua interpreter, the virtual machine, which feeds them to the engine, which feeds it to the APIs, which feed it to the computer.
Most games don't have the lua layer, it's adding a whole set of complications on top of the engine itself.
It's like if you'e ever done anything in java or flash, they run in their own weird player thing, which is why they're both really inefficient. It means they're easy to write for and fairly cross-platform, but it incurs a running cost.
Leastways that's how I was under the impression it worked.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah I know what a virtual machine is, sorry if I gave the impression that I didn't. I don't know enough about NS2 to make specific claims, but it seems to me like game logic tends to generate a lot of garbage very quickly, which is why garbage collector hitching would be a big deal. The mere fact of code running in a VM doesn't necessarily make the language a great deal more inefficient -- some JIT implementations can run faster than compiled code in specific circumstances.
The Unreal engine being the most heavily used engine on the planet.
Have you reevaluated ALL common code patterns to see if more can be offloaded into C/C++ land?
A common theme with Unreal Engine licensees is to build too much of the game in UnrealScript
and then start moving parts into the engine.
Is it primarily execution...or is it still a problem with actual GC?
This was a great article on LUA GC management...and tracking hotspots.
<a href="http://altdevblogaday.com/2011/08/09/fixing-memory-issues-in-lua/" target="_blank">http://altdevblogaday.com/2011/08/09/fixin...-issues-in-lua/</a>
Can the coders be educated to write better code?
I know when I learned more about assembly I wrote better code.
I know when I learned more about IL I wrote better C# code.
A new VM sounds like a heavy undertaking.
The Tribes 2 game engine (Torque) is/was downloadable to take a look at how they did it, and the game ran fine.
LuaJIT was one of the main reasons why I thought it to be a bit silly to dive into assembly. Assembly would be one of the last things you could try in a desperate attempt to speed up code, and current-gen compilers are very good indeed at generating assembly, so the chances you could write a faster asm routine than the compiler (!! and which warrants the effort you have to put in !!) are not that high. Usually doing that is reserved for some very specific algorithm or possible some functionality that isn't properly exposed by a high-level language API yet.
<!--quoteo(post=0:date=:name=kingmob)--><div class='quotetop'>QUOTE (kingmob)</div><div class='quotemain'><!--quotec-->Can the coders be educated to write better code?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yyyyyyes! /heavy
There are a number of articles out there that demonstrate very subtle chances to the Lua-script that can yield a surprising amount of performance\less memory-usage. Of course this also depends on how the VM behaves, which I believe NS2 has a custom-version of already.
<!--quoteo(post=0:date=:name=Syli)--><div class='quotetop'>QUOTE (Syli)</div><div class='quotemain'><!--quotec-->but you can also give the modder a API over c++ or c or even .net. clearly harder but performence wise (i think) better<!--QuoteEnd--></div><!--QuoteEEnd-->
And a +1 to that If only for some of the functionality that is locked in the engine. Speed-wise there isn't that much to gain I think (usually you're mostly interacting with the game-logic to do your thing, which is simply Lua).
<!--quoteo(post=0:date=:name=Zeikko )--><div class='quotetop'>QUOTE (Zeikko )</div><div class='quotemain'><!--quotec-->How is this different if the footstep messages are received as messages from the server? Those messages can be lost and delayed aswell.<!--QuoteEnd--></div><!--QuoteEEnd-->
True I guess, perhaps they're sent realiably and are allowed to arrive late to the party.
[EDIT]
Just to clarify, with realiably I mean those packets are in fact sent multiple times over in case 1 or 2 of them are lost. Spark does this too with at least the chat-messages\tooltips.
This is my sentiment exactly. I don't think ns2 got much of the its lua code jited when it was using luajit because lua C function __index'ers obliterate any chance for luajit to jit code
this could be avoided by using pure lua __index'ers and use luajits ffi system to interface to the engine code
This is example of a lot of <a href="http://pastebin.com/3YpzA2an" target="_blank">failed traces</a> for the server vm because of C __index functions or normal C lua functions
this could be avoided by using pure lua __index'ers and use luajits ffi system to interface to the engine code
This is example of a lot of <a href="http://pastebin.com/3YpzA2an" target="_blank">failed traces</a> for the server vm because of C __index functions or normal C lua functions<!--QuoteEnd--></div><!--QuoteEEnd-->
Interesting, can you tell me what i'm looking at here? how can i create the same trace? so that i can google for more information.
We lost some performance by switching away from luajit, but we gained performance by using our custom binding layer. The net was a slight performance improvement and much better garbage collection behavior.
Because of the nature of our system (lots of mixed Lua and C++), the benefit of luajit isn't the actual JIT part which will not run, it's the fact that the VM is written in assembly with SIMD support and direct threading, and they use a smaller value type which is good for the cache (Lua 5.2 beta also has this). The problem with luajit is that the code is incredibly complicated and dense and modifying it is out of the question.
The reason I want to by able to modify the Lua VM, is to get beyond the ~2x-4x performance you get from these core optimizations for running the VM, we need to be able to do some special things with how we transition between C++ and Lua.
<!--quoteo(post=1885683:date=Nov 19 2011, 06:31 AM:name=player)--><div class='quotetop'>QUOTE (player @ Nov 19 2011, 06:31 AM) <a href="index.php?act=findpost&pid=1885683"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->LuaJIT was one of the main reasons why I thought it to be a bit silly to dive into assembly. Assembly would be one of the last things you could try in a desperate attempt to speed up code, and current-gen compilers are very good indeed at generating assembly, so the chances you could write a faster asm routine than the compiler (!! and which warrants the effort you have to put in !!) are not that high. Usually doing that is reserved for some very specific algorithm or possible some functionality that isn't properly exposed by a high-level language API yet.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's exactly what we use assembly for, SIMD and <a href="http://en.wikipedia.org/wiki/Threaded_code" target="_blank">direct threading</a> which cannot be done in C. I'm not writing huge amounts of asm, that would be a waste of time.
I once had to optimize a function. Somebody wrote a pure assembler version of it. In the end, i recoded it in C, using instrincs to use the SIMD commands, and it was faster than the hand written assembler code. So i'm just posting this to make sure you know about instrincts, because then you can get away without writing any assemble code, and it will be better optimized by the compiler (usually).
Here is the visualstudio reference, gcc uses the same if i remember correctly:
<a href="http://msdn.microsoft.com/en-us/library/26td21ds.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/26td21ds.aspx</a>
Cool! Are decals and particle effects totally on the client, too?
They are both technically only Client side (for rendering) but the Server still sends messages to Clients to tell them to play a particle effect. Decals are triggering entirely Client side right now as far as I can remember.
In some cases (such as footsteps) we can move them entirely to the Client. We can do this whenever the Client already knows when an event happens (such as playing the walk animation for foot steps). In other cases the Server must tell the Client to play a sound or particle effect because it has no other information of the event (such as one player damaging another player).
That would change alot in the alien battle dinamic.
Changing the crag passive healing to a lvl 3 cysts would also bring a bigger difference, like Brian mentioned, in the correct chose of alot of lvl 1 or a couple of lvl 3 at the front.
I'm sure those infestation protos are wort't a test. And if you implement tesselation the marinestatues would come true.
Some suggesstions:
Each cyst adds a certain amount of infestation, how it spreads is controlled by the player. Let's say I put a cyst at the foot of a doorwar, but I don't want the infestation to spread into the next room. I could tell the infestation to only spread backwards or up a wall.
You wanted some way to show that the infestation was healing. How about slight atmospheric mist that rises above the infestation? You already have some atmospheric effects that you previewed in a previous tweet.
Was there any talk about adding any passive effects for aliens on infestation? Coming from the DC/MC/SC mindset from NS1, you could have a slight armor boost, slight speed boost, or slight damage boost for aliens on creep.
I do like the dynamic infestation becoming a large part of the alien gameplay. You tout it as one of the bigger, more unique features to Natural Selection and this is a great way to do it. Reminiscent of the creep in SC2.
Also with the infestation healing, maybe 5-8 seconds of sitting still or sneaking on infestation and being out of harms way, the aliens would start a vastly increased regeneration as if the tentacles on the aliens connected to the infestation to be healed by the hive network. Which would be interrupted by taking damage or moving.
If commander chose crag as first chamber you get additional healing on infestation and with every additional crag the healing strength(limited count of crags boosting).
Crag only heals armor but if the Commander triggers active Heal it sends a healing wave through the infestation. The effect decreases on distance.
Same for shade or whip it boosts the DI. shade does cloaking(more shades --> cloaks faster) when not moving on DI or whip gives extra dmg.
I really don't like the 'drop cyst, infestation comes out, but cyst is the point of failure' idea, it feels too... not dynamic at all.
I don't know if you ever played black and white 2, but it had a lovely click and drag feature for walls and roads which let you build lovely snaking patterns, I think infestation should work like that, you paint it on the world, not click to drop blobs.
But obviously you do need infestation to still be vulnerable to attack by conventional weapons...
I think either infestation should grow cysts all over it, basically turning it into a very high density version of what you have now, but rather than two or three cysts in a hallway, you'd have maybe 20 or so all over the walls ceiling, and floor, as part of the infestation, not a sepearate thing. Killing a cyst would cause a small patch of infestatiion to die, so you could go down the corridor, and burn a firebreak to sever it from all the surfaces and kill the stuff further back, or shoot the cysts to achieve the same, but area weapons and particularly fire would be best.
I just really don't like the 'digital' infestation, I know it's a game so obviously everything has to have a degre of discreteness, no round surfaces etc, but infestation REALLY needs as much of it as you can get.
If you can't do a much more dense and therefore analog placement system, go further the other way, make cysts much tougher and much bigger, make them like placeable power nodes, or more like NS1 turret factories, with a big area of effect. In that area infestation behaves cosmetically analog, but computationally it is highly discrete. You don't attack the infestation network most of the time, that would be something you do when clearing out a room with a major attack, so there is a lot less of the 'cyst gets dropped, blob grows, cyst dies, blob dies' thing that just feels so not atmospheric.
You could then of course add a more analog behaviour for the surrounding infestation, with it responding to fire and explosions and such, and dying off but regrowing, that sort of thing, but the commander doesn't need to keep interfering with the network. Cyst network maintenence is not a very fun thing to be doing, because when the commander interferes the infestation loses its organic feel.
If you want stuff for the comm to do, give them powers they can trigger from the infestation, or something, but the actual growth of it should be automated and smoothed out as much as possible, less clicking.