Natural Selection 2 News Update - Optimizing NS2
Flayra
Game Director, Unknown Worlds EntertainmentSan Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
Game Director, Unknown Worlds EntertainmentSan Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
Comments
According to some people: this is how optimization goes.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->#include <iostream>
#include "game.h"
using namespace std;
int main()
{
optimize.Game();
return 0;
}<!--c2--></div><!--ec2-->
+1
Optimising is an ongoing process where timing is crucial. One needs to monitor and profile all the time and act on the right time.
Many optimising tasks have not been able to be done earlier because it has not been the correct time. It is just not worth it to spend days optimising stuff that can not be surely incorporated in the final product.
I did enjoy the video, it is also great to see how you are developing NS2.
In fairness it is a <b>developer blog</b> and not a <b>game progress</b> blog.
<a href="http://upload.wikimedia.org/wikipedia/commons/thumb/9/93/KPatience.png/738px-KPatience.png" target="_blank">patience</a>
You're a disgrace to England.
Don't get me wrong though: they seem like they can handle it <b>just fine</b>! However, from my experience, interpreted languages that compile into bytecode always appear fantastic on paper and may perform well in specific test cases, but in practice they just don't perform as well as their pre-compiled, compiler-optimized counterparts. Its a tragedy, really, because I adore interpreted languages.
Regardless, by the time the game is released, most people will have a CPU powerful enough to just rip through all the game code anyway :P
It is used in other game engines.
plenty of game engines use some sort of scripting.
It is easy to change and makes changes faster.
I seem to remember they built hotloading of scripts into their engine.
that means someone could write code for a feature.
test it ...realize what they forgot...add it...test that...and then check it in
this cuts out compiles and game startups from iterating until a feature (or bug fix) is complete.
Plus they got some GREAT ideas from the community.
They may choose to move more code into C/C++ land now that they are nearing feature completion.
But as an overall investment LUA is still worth it.
It is used in other game engines.
plenty of game engines use some sort of scripting.
It is easy to change and makes changes faster.
I seem to remember they built hotloading of scripts into their engine.
that means someone could write code for a feature.
test it ...realize what they forgot...add it...test that...and then check it in
this cuts out compiles and game startups from iterating until a feature (or bug fix) is complete.
Plus they got some GREAT ideas from the community.
They may choose to move more code into C/C++ land now that they are nearing feature completion.
But as an overall investment LUA is still worth it.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think this as well, though it is sad that they can't leverage luajit due to binding optimization. i was wondering why charlie made the comment about discussions of writing a lua interpreter. there will be more optimization in this space for sure.
True, but they are bearing some of the benefits of going with lua <a href="http://www.unknownworlds.com/ns2/forums/index.php?showforum=106" target="_blank">right now</a>.
That said, great post! It's always fun to watch people try to give accessible explanations of concepts that are difficult to explain to other programmers. From what I can tell you did a good job.
And that is due to them trying to build a state of the art engine that first used a state of the art culling method (which did not work) and now uses a Frostbite like approach (which still does not work). I personally do not get that arms race with the big league. I do not care about graphics that much. I just want a playable game! Why not go with something a little more proven? I mean it does not have to look like *insert big studio game here*.
The graphics rendering in Spark is very fast actually, it is the game code/lua that is holding back performance right now. But they are getting faster with each patch :)
Being an indie doesn't mean it has to look crappy... It already looks awesome and when other filters are introduced it will be even more awesome!
So you are saying that engines that need a precomputation (shadow maps, visibility) step like source engine, unreal engine and ID engine do not have a decent lifetime - or that you cannot build a game quickly there?
Having a sandbox like editor may have its advantages and may be very modern - but the focus should be on delivering something playable and finished. And modders and other companies shouldn't be the focus either.
Back at the FarCry days I tried to make a mod for the CryTek 1 engine. That engine is similar in that it uses LUA and a sandbox editor. And it was godawful because you could really see that they moved LUA code back into C++ and what was left was an inconsise mess. That does not matter though because they were able to finish the game and deliver.
Same thing happend here. I think: We need the level designers/game designers to be able to change the game -> Let's do the game part in an easy language that they can learn easily -> level/game designers produce messy, slow lua code -> Programmers have to fix it (costly). Because they like C++ more they move it back there
Now, with regard to decent lifetime, I was referring to the more "modern" features - an engine that is full of outdated technology when it is released is not attractive to modders, developers, or, more importantly, prospective customers either. A scripting "layer" built on top of the engine was one design decision that creates accessibility for modders, and allows for instant changes in-game. The others you know: dynamic lighting, no pre-compiling, etc. More than being marketed towards modders and developers, the decisions were made so that UWE could import, edit and test lots of assets and features in a very quick period of time, <b>without also requiring a very large team</b>. It was UWE's belief that the benefits outweighed the costs, and they still believe they will get it to work. Honestly, this was all explained by UWE the day they announced the decision to switch from Source to the as-yet-unnamed engine that became Spark (and by Max in one of the recent NS2HD interviews), and I'm just regurgitating it for your benefit. Your frustration is misdirected.
Now, with regard to decent lifetime, I was referring to the more "modern" features - an engine that is full of outdated technology when it is released is not attractive to modders, developers, or, more importantly, prospective customers either. A scripting "layer" built on top of the engine was one design decision that creates accessibility for modders, and allows for instant changes in-game. The others you know: dynamic lighting, no pre-compiling, etc. More than being marketed towards modders and developers, the decisions were made so that UWE could import, edit and test lots of assets and features in a very quick period of time, <b>without also requiring a very large team</b>. It was UWE's belief that the benefits outweighed the costs, and they still believe they will get it to work. Honestly, this was all explained by UWE the day they announced the decision to switch from Source to the as-yet-unnamed engine that became Spark (and by Max in one of the recent NS2HD interviews), and I'm just regurgitating it for your benefit. Your frustration is misdirected.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nobody will want to play a game that is not playable because it is unfinished, unpolished and does not run smoothly, regardless how good it is for modders and developers. And modders and developers are not the customers here. They do not pay the bills. Players do not care if UWE can test or import assets, or change the game while it is running. Of course they care about the visuals, but people play TF2 don't they?
If I remember correctly they switched to Spark also because Source hat some limitations with regard to dynamic lighting and dynamic infestation. We have yet to see dynamic infestation (as shown in the teaser) and I think some maps are not played because dynamic lighting does not perform well.
If I read "Fixed a networking bug with acknowledging reliable packets" in the changelog then I'm asking myself: Why are they not using a network libary for that. They are wasting time reinventing the wheel here. This goes for the whole engine.
Don't get me wrong. I don't think the technology decisions are wrong. They just all cost time getting right now. I think that they should concentrate on finishing the game. They are not Valve. They do not have unlimited time. The first teaser announced it for fall 2009! And frankly I'm afraid they are going to run out of money before the game is finished. And I want to play that game!
Of course it is too late now to revert some decisions. But why, for example, did they add those atmospheric effects? Nobody requested them. Nobody would have missed them. They caused performance problems. They do not add much value to the game.
Or constantly twiddling on the balancing while nobody can aim, the hit registration does not work, server tick rate goes down in the late game and so on. Get that to work first. Publishing statistics and analysing them is a joke otherwise.
See above.
r_fog 0
r_shadow 0
r_bloom 0
r_atmospherics 0
r_instancing 0 *not sure what this suppose to do*
These commands need to be entered every time you change server and even if you change sides. They may not make a huge difference in your base but in combat I notice a big enough boost. Does anyone know how to turn off the marine hud? I'm getting about 5fps higher as an alien and would like to see if it's causing the problem.
net_stats will display the server preformance, network and fps very helpful in seeing where the problem is
r_stats shows your fps and other graphics related info
The odd thing is though, I don't see any difference in FPS between alien or marine view... Was it because you're in your base mostly so you have to render a lot more onscreen?
The odd thing is though, I don't see any difference in FPS between alien or marine view... Was it because you're in your base mostly so you have to render a lot more onscreen?<!--QuoteEnd--></div><!--QuoteEEnd-->
Na I tested this by joining an empty server had a tick rate of 32 and running around the map. I've never notice a difference before though.
Just tested with the gui on/off at different points on the map and there is a fps gain by turning it off. I did the test on the new map with the above commands off with net_stats running if anyone else wants to take a look and see if you get the same result.
I tested removing the gui as an alien and also received a small fps boost. I ran fraps this time with net_stats and noticed a slight fps gain by not having net_stats running (standing still).