<!--quoteo(post=1889560:date=Dec 9 2011, 07:30 PM:name=Evil_bOb1)--><div class='quotetop'>QUOTE (Evil_bOb1 @ Dec 9 2011, 07:30 PM) <a href="index.php?act=findpost&pid=1889560"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You are not really answering my question :p I understand very well why optimization happens at end of production. My question is:
-Can (and is it common that) end of production optimization multiply performance by a factor of 2, 3 or more?<!--QuoteEnd--></div><!--QuoteEEnd--> Depends on how much optimization there is to be done. It's certainly possible.
DghelneshiAims to surpass Fana in post edits.Join Date: 2011-11-01Member: 130634Members, Squad Five Blue, Reinforced - Shadow
edited December 2011
@Arga: Techercizer summed it up pretty good. It is simply not feasible to focus on performance right now, since they would waste hundreds of hours doing something they will need to completely redo when they want to change anything.
I'm frustrated, too, but any amount of raging or crying won't help (not talking about you!). Of course, not everyone knows about the difficulties of developing a game and especially optimizing it, but what's up with the raging after people tell you it's simply not possible? That's like a little boy throwing a fit because people tell him he can't get a lollipop made out of moon rock.
ZeikkoJoin Date: 2007-12-16Member: 63179Members, Squad Five Blue, NS2 Map Tester
<!--quoteo(post=1889547:date=Dec 10 2011, 02:57 AM:name=Evil_bOb1)--><div class='quotetop'>QUOTE (Evil_bOb1 @ Dec 10 2011, 02:57 AM) <a href="index.php?act=findpost&pid=1889547"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I gots a question for you tech guys. Could end-of-production optimization really multiply by 2/3/4... the performance of the game? Is it something common in software production?<!--QuoteEnd--></div><!--QuoteEEnd--> I have no experience in game development but I will try answer this with my experience in application and web application development.
I would say that the performance can be easily multiplied by 2,3 or 4 times. What I usually do with my projects is that when I first implement a feature I hack it up fast and without much thought put on performance. I just want to get it done in a way that is easy for me to understand, read and modify. That way I can show the result to the client, get his feedback and modify and repair stuff according to the feedback. This is what UWE is doing with the beta here too.
Then after the client is happy with the feature I'll go to implement the next feature and so on. When a feature has been in the test product for some time (days, weeks or months depending on the scale of the project) and the customer is still happy with i will optimize it. I don't do optimization straight after the client has approved a feature because there's a very high chance that he will change his mind.
The optimization can give huge boosts to the performance. For example couple of weeks ago i was working on a particular page of a web application that took 5-30 seconds to load every time. I had it like that for 2 months in the product because the site was evolving all the time. Finally when the client seeemed to be happy with it and didn't come up with new ideas every week I optimized it and now it loads under 100ms everytime. The code used to generate the page is more complex, ugly and harder to read, but it's fast. Now I just hope the client doesn't want any more big modifications on it.
But then again the technologies i use are totally different and I can afford to code stuff in totally unoptimized ways in the beginning which UWE might have not done. All in all i would not be worried about the end product performance as there's not much we can do about it. The faster and better we can help UWE to figure out the game mechanics the faster they can optimize the game as there's often no point optimizing stuff that is not final.
I don't find the comparison accurate Zeikko, Evil_bOb1 was on the money here in my opinion. It isn't as if UWE created their own script-language from the ground up, Lua has been in development for quite some time and is arguably pretty mature. Many builds ago Spark used Luabind (which is also a matured product) which proved to be unable to deliver the performance required, so it isn't always about optimizing, but also about making the right design-descisions at the start of the process.
As I understand it, McGuire wants to keep the Lua runtime-interpreted, which is possible but comes at a steep price in terms of performance. Whether it is indeed possible at all to get it to run fast enough like this is the question at hand right now.
ZeikkoJoin Date: 2007-12-16Member: 63179Members, Squad Five Blue, NS2 Map Tester
<!--quoteo(post=1889640:date=Dec 10 2011, 09:03 PM:name=player)--><div class='quotetop'>QUOTE (player @ Dec 10 2011, 09:03 PM) <a href="index.php?act=findpost&pid=1889640"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't find the comparison accurate Zeikko, Evil_bOb1 was on the money here in my opinion. It isn't as if UWE created their own script-language from the ground up, Lua has been in development for quite some time and is arguably pretty mature. Many builds ago Spark used Luabind (which is also a matured product) which proved to be unable to deliver the performance required, so it isn't always about optimizing, but also about making the right design-descisions at the start of the process.<!--QuoteEnd--></div><!--QuoteEEnd--> My examples were done by using mature non proprietary scripting language too. But UWE might not have done as bad job performance wise in the initial coding as I usually do so same kind of performance gains might not be realistic.
Yes but I'm talking about the scripting-engine itself, not the script written for it (although there may be performance-gains to be gotten there too still). So I don't mean so much as tricks (moving code around, changing structures) to speed things up, but rather fundamental architectural issues.
ArgathorJoin Date: 2011-07-18Member: 110942Members, Squad Five Blue
Just out of interest, are the current client performance issues and server performance issues due to the same problem, lua (crazy CPU requirements)? Or are they completely different problems?
If you've ever played a beta before you know you can get some huge variances in performance. Although to me a beta is feature-complete, I'd still call this beta an alpha.
And what is an alpha? It's when it's no where near the finished article and you'll get not just huge variances in performance.. but broken builds.. so broken and so horrible to some that you may want to go "DELETE" on it.
So if you want to moan about NS2 "beta" performance, pretend or substitute beta for alpha and you will understand.
<!--quoteo(post=1889560:date=Dec 9 2011, 07:30 PM:name=Evil_bOb1)--><div class='quotetop'>QUOTE (Evil_bOb1 @ Dec 9 2011, 07:30 PM) <a href="index.php?act=findpost&pid=1889560"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You are not really answering my question :p I understand very well why optimization happens at end of production. My question is:
-Can (and is it common that) end of production optimization multiply performance by a factor of 2, 3 or more?
------
The reason I ask this is because I am in the construction business. And finding an optimized layout for example is a great part of the design process. If you start thinking about optimization of a building once the construction has started you will end up with a lot of problems. In software production it is very different because, I understand, to optimize code you need the code to be there. But, like in construction, shouldn't there be a first layer of identifying what you want in the game and designing how they are all going to fit together before starting to write the code? Can final optimization really make the whole thing work much faster, or does it just make it run a bit better?<!--QuoteEnd--></div><!--QuoteEEnd--> I want a beta ! I didnt care about development. Dont release sth. that isnt needed ! I would like to play an older build. It rly sucks this way.
natural selection 2 is currently in an 'beta' due to financial problems back then. we had plenty of alpha / beta discussions here in the forums but in the end, it doesnt matter what you call it. the game is in the state that its currently in. many decisions have been made (e.g. own engine vs. licenced one) and blaming something that works not perfectly/good doesnt prove that the decision was a bad idea. performance increased, features went in, maps were made and in a few months ns2 could be feature complete and performance will get much better. and in the end it may was worth it to have an own engine.
i also had less then 10fps while fighting ingame a few patches ago, it doesnt kept me from playing. by now im getting 20-40fps. with 800hours ingame time i played every patch since b160. its getting better, every or every other patch, be just a little more patient, even if its in development for quite some time
I would suggest that UWE renames the new builds to preBeta or even back to alpha. It wouldn't change anything but it would stop ppl crying that this isn't a beta like the AAA games do release today. If you take a look at Americas Army that is at Version 3.1 and it is still a beta. For me each game is a beta as long as I get developler patches for it (f.e. Diablo 2 and his big gamplaybalance patch for a 10 year old game back in 2010!!).
And ppl who are dissapointed about a beta that isn't a beta are dumba..... Isn't it cooler and more exciting to be in a Alpha than in a beta, or aka demo. But who cares the names lets just call it Developlerversion of NS2 or short NS2DV?
<!--quoteo(post=1889772:date=Dec 11 2011, 06:39 PM:name=Floodinator)--><div class='quotetop'>QUOTE (Floodinator @ Dec 11 2011, 06:39 PM) <a href="index.php?act=findpost&pid=1889772"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But who cares the names lets just call it Developlerversion of NS2 or short NS2DV?<!--QuoteEnd--></div><!--QuoteEEnd-->
NS2UO
un-optimised just because the abbreviation looked good even if the game description is terribly flawed.
<!--quoteo(post=1889742:date=Dec 11 2011, 11:58 AM:name=Argathor)--><div class='quotetop'>QUOTE (Argathor @ Dec 11 2011, 11:58 AM) <a href="index.php?act=findpost&pid=1889742"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Just out of interest, are the current client performance issues and server performance issues due to the same problem, lua (crazy CPU requirements)? Or are they completely different problems?<!--QuoteEnd--></div><!--QuoteEEnd--> Same issue, though some clients with really poor graphics-cards may be bottlenecked in that area first, but otherwise it's the Lua bogging down the CPU.
As for the Beta-thing, they're coming closer and closer to what an actual Beta is, so it's a bit late to call that into question again.
Comments
-Can (and is it common that) end of production optimization multiply performance by a factor of 2, 3 or more?<!--QuoteEnd--></div><!--QuoteEEnd-->
Depends on how much optimization there is to be done. It's certainly possible.
Techercizer summed it up pretty good. It is simply not feasible to focus on performance right now, since they would waste hundreds of hours doing something they will need to completely redo when they want to change anything.
I'm frustrated, too, but any amount of raging or crying won't help (not talking about you!).
Of course, not everyone knows about the difficulties of developing a game and especially optimizing it, but what's up with the raging after people tell you it's simply not possible? That's like a little boy throwing a fit because people tell him he can't get a lollipop made out of moon rock.
I have no experience in game development but I will try answer this with my experience in application and web application development.
I would say that the performance can be easily multiplied by 2,3 or 4 times. What I usually do with my projects is that when I first implement a feature I hack it up fast and without much thought put on performance. I just want to get it done in a way that is easy for me to understand, read and modify. That way I can show the result to the client, get his feedback and modify and repair stuff according to the feedback. This is what UWE is doing with the beta here too.
Then after the client is happy with the feature I'll go to implement the next feature and so on. When a feature has been in the test product for some time (days, weeks or months depending on the scale of the project) and the customer is still happy with i will optimize it. I don't do optimization straight after the client has approved a feature because there's a very high chance that he will change his mind.
The optimization can give huge boosts to the performance. For example couple of weeks ago i was working on a particular page of a web application that took 5-30 seconds to load every time. I had it like that for 2 months in the product because the site was evolving all the time. Finally when the client seeemed to be happy with it and didn't come up with new ideas every week I optimized it and now it loads under 100ms everytime. The code used to generate the page is more complex, ugly and harder to read, but it's fast. Now I just hope the client doesn't want any more big modifications on it.
But then again the technologies i use are totally different and I can afford to code stuff in totally unoptimized ways in the beginning which UWE might have not done. All in all i would not be worried about the end product performance as there's not much we can do about it. The faster and better we can help UWE to figure out the game mechanics the faster they can optimize the game as there's often no point optimizing stuff that is not final.
As I understand it, McGuire wants to keep the Lua runtime-interpreted, which is possible but comes at a steep price in terms of performance. Whether it is indeed possible at all to get it to run fast enough like this is the question at hand right now.
My examples were done by using mature non proprietary scripting language too. But UWE might not have done as bad job performance wise in the initial coding as I usually do so same kind of performance gains might not be realistic.
And what is an alpha? It's when it's no where near the finished article and you'll get not just huge variances in performance.. but broken builds.. so broken and so horrible to some that you may want to go "DELETE" on it.
So if you want to moan about NS2 "beta" performance, pretend or substitute beta for alpha and you will understand.
-Can (and is it common that) end of production optimization multiply performance by a factor of 2, 3 or more?
------
The reason I ask this is because I am in the construction business. And finding an optimized layout for example is a great part of the design process. If you start thinking about optimization of a building once the construction has started you will end up with a lot of problems. In software production it is very different because, I understand, to optimize code you need the code to be there. But, like in construction, shouldn't there be a first layer of identifying what you want in the game and designing how they are all going to fit together before starting to write the code? Can final optimization really make the whole thing work much faster, or does it just make it run a bit better?<!--QuoteEnd--></div><!--QuoteEEnd-->
I want a beta ! I didnt care about development. Dont release sth. that isnt needed ! I would like to play an older build. It rly sucks this way.
i also had less then 10fps while fighting ingame a few patches ago, it doesnt kept me from playing. by now im getting 20-40fps. with 800hours ingame time i played every patch since b160. its getting better, every or every other patch, be just a little more patient, even if its in development for quite some time
If you take a look at Americas Army that is at Version 3.1 and it is still a beta.
For me each game is a beta as long as I get developler patches for it (f.e. Diablo 2 and his big gamplaybalance patch for a 10 year old game back in 2010!!).
And ppl who are dissapointed about a beta that isn't a beta are dumba.....
Isn't it cooler and more exciting to be in a Alpha than in a beta, or aka demo.
But who cares the names lets just call it Developlerversion of NS2 or short NS2DV?
NS2UO
un-optimised just because the abbreviation looked good even if the game description is terribly flawed.
Same issue, though some clients with really poor graphics-cards may be bottlenecked in that area first, but otherwise it's the Lua bogging down the CPU.
As for the Beta-thing, they're coming closer and closer to what an actual Beta is, so it's a bit late to call that into question again.