<!--quoteo(post=2064624:date=Jan 22 2013, 04:56 AM:name=Tweadle)--><div class='quotetop'>QUOTE (Tweadle @ Jan 22 2013, 04:56 AM) <a href="index.php?act=findpost&pid=2064624"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I still think this is a poor excuse. A "D-" is still a "D-" and getting an "F" prior doesn't magically make the "D-" desirable. If I shouldn't expect an Indie Studio to put out a AAA-level game, then UWE shouldn't have attempted to in the first place. As it happens my gripe is not that it can't perform well next to those titles, it's that it tried to in the first place and fell flat. The one thing I expect from <i>every game</i> is for it to run properly and not hitch - perform on a different stage and expect the audience to judge against those that came before you. I only ever make exception when a game is deliberately pushing the frontiers of science to make a point (and only for single-player). Needless to say, NS2 is a world apart from that standard.<!--QuoteEnd--></div><!--QuoteEEnd-->
You got a point there. One major goal was to create this flashy own engine which of course did cost lots of development time (and therefor lots of money). Considering the outcome and looks, I wonder why they did not just use the Source 2 engine. (which to me looks very much like their self made engine)
Of course you will say "cost cost cost" but if you consider the at least 5 years of development time, just calculate for yourself how much this is in manpower cost only. Even if it is done by one person alone it's at least about 200k which would buy a up to date, optimized engine. With the source 2 Engine for example they could have even started as a mod and licence the engine upon release which would really have helped the financial situation.
I mean, lets be honest here: NS2 really is a great game, for me the best there is atm. BUT there are small and not so small issues that tell that the developers did not have enough time to finish the game. Just consider the state of NS1(which was a mod and created by even less people) after 7 Years of development and compare it to NS2. It becomes obvious that the overambitious idea to develop their own, state of the art engine had serious impact on the time spent on the actual game design.
<!--quoteo(post=2064826:date=Jan 22 2013, 08:44 AM:name=matso)--><div class='quotetop'>QUOTE (matso @ Jan 22 2013, 08:44 AM) <a href="index.php?act=findpost&pid=2064826"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yea, that's what I had in mind when I wrote "complex and time-consuming re-architecting". There are some pretty straightforward optimizations possible when it comes to multi-threading, but they require capabilities that are not part of the standard Lua VMs, and it would also require a partial rewrite of the ns2 lua code.
I used to think so to. But for games like NS2, event based coding is just to complex, fragile and costly - timed checks turns out to be much easier to code and understand, and there is no clear case for it being significantly slower.
If you check the profiler, OnUpdate() for the various classes is not a dominant cost (any longer; costly OnUpdate() fixes belongs to the class of "easy" optimizations that has already been done). The real cost is processing moves and updating physics/animations, which are mostly in C++.<!--QuoteEnd--></div><!--QuoteEEnd-->
So basically netcode improvements would yield greater performance? Still though I think most of us observe server side lag to become worse in the late game when ent count is the highest. ARCs and other things that need waypoints seem to still eat a lot of resources.
As for the event coding I do not see how that would be more complex as it would be much easier to read. Here are two examples as to how such a system could be used which should not be complex to implement.
Create method such as OnPowerDown(node) where as node is a unique value that represents a given power node. Structures know what node they were placed on when constructed and thus: OnPowerDown(node) { if(node=mynode) { powerdown(); } }
Now we have a method that runs only when a power node is lost vs every game frame. This is also much easier to read than a bunch of loops for every ent and can be bug fixed easier like when structures are on some maps coming in on the wrong node. (Right side of warehouse has this issue sometimes)
Now things are a bit more complex for cycrs honestly this is where I understand the current method b/c an event based trigger would still need to use some loops to crawl over some some arrays before it could do anything and as every single crys would need to do this the only advantage to performance is really when they are not being attacked which is fairly rare. In addition such a method with these would also open things up to new bugs due to the complexity.
So I can and can not see what your saying about the event coding. Honestly for things like power node I think it would help a lot and be great for mods. For example I think the ability to have that call back and find the types of structures that lost power could be cool for stats programs to reward points to players who killed a base power vs some random power node.
Lastly on the note of OnUpdate() I also wonder if this is being loaded heavier late game due to FPS drops from clients? If this is the case than as I stated at first better netcode optimization or client side fps improvements should reduce the amount of perdition the server needs to perform to correct for errors.
<!--quoteo(post=2064924:date=Jan 22 2013, 05:48 PM:name=CommunistWithAGun)--><div class='quotetop'>QUOTE (CommunistWithAGun @ Jan 22 2013, 05:48 PM) <a href="index.php?act=findpost&pid=2064924"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If he bought it under the 1.0 version listed requirements, he isn't being ignorant. To be frank the real requirements should be more like
Minimum (30-60fps) 3.0Ghz Quadcore nvidia 600 series ati 6000 series 4GB RAM 7200 RPM HD
Recommended would be i5 or higher, 8gb ram, SSD, etc etc etc<!--QuoteEnd--></div><!--QuoteEEnd-->
Someone here said that using more than 2 cores is useless for NS2 because of UWE being unable to write code to run on multiple cores using Lua, but instead higher GHz sees greater improvement.
More relevant to the discussion above: isn't it possible to recreate C# events in C++ and Lua? They work really well, like this:
1. You define an event (delegate), which is a field which stores references to methods conforming to a specific signature. 2. Another class 'subscribes' to the event by adding the method (in its class) it wants called to the field. 3. The class containing the event calls each method referenced in the event field when a particular branch of code executes.
I've used this whenever writing UI code and it works incredibly well and is very tidy.
<!--quoteo(post=2064965:date=Jan 22 2013, 12:48 PM:name=nsguy)--><div class='quotetop'>QUOTE (nsguy @ Jan 22 2013, 12:48 PM) <a href="index.php?act=findpost&pid=2064965"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Someone here said that using more than 2 cores is useless for NS2 because of UWE being unable to write code to run on multiple cores using Lua, but instead higher GHz sees greater improvement.<!--QuoteEnd--></div><!--QuoteEEnd-->
Maybe. If true, yet another reason why LUA was a bad idea. Im not a programmer, at all, but why not place things like logic from entities on a third or fourth core?
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=2064624:date=Jan 21 2013, 07:56 PM:name=Tweadle)--><div class='quotetop'>QUOTE (Tweadle @ Jan 21 2013, 07:56 PM) <a href="index.php?act=findpost&pid=2064624"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I still think this is a poor excuse. A "D-" is still a "D-" and getting an "F" prior doesn't magically make the "D-" desirable. If I shouldn't expect an Indie Studio to put out a AAA-level game, then UWE shouldn't have attempted to in the first place. As it happens my gripe is not that it can't perform well next to those titles, it's that it tried to in the first place and fell flat. The one thing I expect from <i>every game</i> is for it to run properly and not hitch - perform on a different stage and expect the audience to judge against those that came before you. I only ever make exception when a game is deliberately pushing the frontiers of science to make a point (and only for single-player). Needless to say, NS2 is a world apart from that standard.
I respect the difficulty of creating a title like NS2 for a small team such as UWE but I wish, perhaps, they had feared it!<!--QuoteEnd--></div><!--QuoteEEnd--> I guess my standard is more pushing the boundaries of the existing, stale state of AAA gaming. The type of genre blending that NS2 does (FPS/RTS) is the sort of experimental game development I'd like to see more of, which is why I'm willing to put up with more bugs, crashes, and lag than with more mainstream titles.
Also, I'd rather see NS2 fall short of high expectations than to overperform low ones. You don't have great successes if you always set the bar low enough that you can trip over it.
Don't get me wrong, I'm after that too! In fact, that's exactly why I'm not concerned about aesthetic realism or pretty entities. It's precisely <i>because</i> I want what NS2 does (fps/rts etc.) that I am so frustrated with the unrealistic target they've failed to reach. I can't find a concept this good anywhere else which is why I'm desperate to be able to play it smoothly here. As it is, the peformance/animation/hitreg trio is getting in the way of an experience I really want to have.
Comments
You got a point there. One major goal was to create this flashy own engine which of course did cost lots of development time (and therefor lots of money). Considering the outcome and looks, I wonder why they did not just use the Source 2 engine. (which to me looks very much like their self made engine)
Of course you will say "cost cost cost" but if you consider the at least 5 years of development time, just calculate for yourself how much this is in manpower cost only. Even if it is done by one person alone it's at least about 200k which would buy a up to date, optimized engine.
With the source 2 Engine for example they could have even started as a mod and licence the engine upon release which would really have helped the financial situation.
I mean, lets be honest here: NS2 really is a great game, for me the best there is atm.
BUT there are small and not so small issues that tell that the developers did not have enough time to finish the game. Just consider the state of NS1(which was a mod and created by even less people) after 7 Years of development and compare it to NS2. It becomes obvious that the overambitious idea to develop their own, state of the art engine had serious impact on the time spent on the actual game design.
I used to think so to. But for games like NS2, event based coding is just to complex, fragile and costly - timed checks turns out to be much easier to code and understand, and there is no clear case for it being significantly slower.
If you check the profiler, OnUpdate() for the various classes is not a dominant cost (any longer; costly OnUpdate() fixes belongs to the class of "easy" optimizations that has already been done). The real cost is processing moves and updating physics/animations, which are mostly in C++.<!--QuoteEnd--></div><!--QuoteEEnd-->
So basically netcode improvements would yield greater performance? Still though I think most of us observe server side lag to become worse in the late game when ent count is the highest. ARCs and other things that need waypoints seem to still eat a lot of resources.
As for the event coding I do not see how that would be more complex as it would be much easier to read. Here are two examples as to how such a system could be used which should not be complex to implement.
Create method such as OnPowerDown(node) where as node is a unique value that represents a given power node. Structures know what node they were placed on when constructed and thus:
OnPowerDown(node)
{
if(node=mynode)
{
powerdown();
}
}
Now we have a method that runs only when a power node is lost vs every game frame. This is also much easier to read than a bunch of loops for every ent and can be bug fixed easier like when structures are on some maps coming in on the wrong node. (Right side of warehouse has this issue sometimes)
Now things are a bit more complex for cycrs honestly this is where I understand the current method b/c an event based trigger would still need to use some loops to crawl over some some arrays before it could do anything and as every single crys would need to do this the only advantage to performance is really when they are not being attacked which is fairly rare. In addition such a method with these would also open things up to new bugs due to the complexity.
So I can and can not see what your saying about the event coding. Honestly for things like power node I think it would help a lot and be great for mods. For example I think the ability to have that call back and find the types of structures that lost power could be cool for stats programs to reward points to players who killed a base power vs some random power node.
Lastly on the note of OnUpdate() I also wonder if this is being loaded heavier late game due to FPS drops from clients? If this is the case than as I stated at first better netcode optimization or client side fps improvements should reduce the amount of perdition the server needs to perform to correct for errors.
Minimum (30-60fps)
3.0Ghz Quadcore
nvidia 600 series
ati 6000 series
4GB RAM
7200 RPM HD
Recommended would be i5 or higher, 8gb ram, SSD, etc etc etc<!--QuoteEnd--></div><!--QuoteEEnd-->
Someone here said that using more than 2 cores is useless for NS2 because of UWE being unable to write code to run on multiple cores using Lua, but instead higher GHz sees greater improvement.
More relevant to the discussion above: isn't it possible to recreate C# events in C++ and Lua? They work really well, like this:
1. You define an event (delegate), which is a field which stores references to methods conforming to a specific signature.
2. Another class 'subscribes' to the event by adding the method (in its class) it wants called to the field.
3. The class containing the event calls each method referenced in the event field when a particular branch of code executes.
I've used this whenever writing UI code and it works incredibly well and is very tidy.
Maybe. If true, yet another reason why LUA was a bad idea. Im not a programmer, at all, but why not place things like logic from entities on a third or fourth core?
I respect the difficulty of creating a title like NS2 for a small team such as UWE but I wish, perhaps, they had feared it!<!--QuoteEnd--></div><!--QuoteEEnd-->
I guess my standard is more pushing the boundaries of the existing, stale state of AAA gaming. The type of genre blending that NS2 does (FPS/RTS) is the sort of experimental game development I'd like to see more of, which is why I'm willing to put up with more bugs, crashes, and lag than with more mainstream titles.
Also, I'd rather see NS2 fall short of high expectations than to overperform low ones. You don't have great successes if you always set the bar low enough that you can trip over it.