Hey guys we should make a 'serious esport' shooter that requires high speed continuous tracking of objects moving on all three axes with 30 fps. Need more fan art competitions.
They took a risk using their own engine, didn't work out.
It worked out spectacularly well, and the future of UWE is brighter for it. The financial, technical, creative, and intellectual freedom that Spark has granted UWE is immeasurably valuable.
Judging the engineering value of an entire game engine by the behaviour of a particular game's late game performance when entities are exploding out of every pore on a is utterly ridiculous.
The engine failed mate, Spark was made FOR NS2 so how else will we judge it. It might of been a success for the financial, technical, creative and intellectual freedom of UWE but from a players perspective it just did not deliver.
- Client Performance: People have to OC to 4+ghz to maintain 60 fps. This STILL does not work late game with people dipping to 40-50
- Server Performance: The game struggles to run on medium spec rack mounted servers (2.2-3.0Ghz). Server operators had to purchase consumer grade desktops, install massive fans/heatsinks and OC to 4.0Ghz to maintain 30 ticks
- Server Performance: 30 ticks is unacceptable for a game this fast paced. I ran 100/100 rates w/ 0.01 interp in NS1 and the feedback/rego was instant. There is atleast a half second delay in damage feedback when playing marines
The number one complaint I have from the 50+ people I convinced to purchase NS2 was that they could not understand why they can run BF3 at 100fps, but NS2 at 40-50fps. Hell, even Planetside 2 runs far better...
UWE took a risk using Max's engine over the source engine to follow their creative idea's about how they wanted NS2 to be played. I'm sure there are a thousand financial / business related decisions regarding this as well that we will never know.
I would of loved to see NS2:source, the game would of been amazing. Shame...
FYI: 99% of the competitive community for Australia played TF2. A fast paced action shooter on the source engine...
"- Server Performance: The game struggles to run on medium spec rack mounted servers (2.2-3.0Ghz). Server operators had to purchase consumer grade desktops, install massive fans/heatsinks and OC to 4.0Ghz to maintain 30 ticks"
This is my main concern, no way this can be viable for the long term survival of the game. I can't see official ISPs hosting these type of servers, and if so, for very long.
Hi all,
We're all aware of the performance issues and are doing our best. In a sense, every week is a performance jam for us. We're always trying things and open to new ideas, and some things work out and some things don't. Believe me, we're not happy about the game's performance either.
--Steve
I remember you saying somewhere in a video that you were working on some performance changes/mumbo jumbo that looked promising, but you weren't going to give any numbers or a time period for release. Has there been any significant progress put into this?
I wonder if Spark is using LUAJIT or if UWE is at least planning to experiment with it. LUAJIT, in addition to JITting code (as opposed to interpreting, which is slower), also enables you to use fibers (kind of lightweight "threads") which might help increase performance on multi-core CPUs depending on how well they're used.
What is it about the game entities that affect performance?
If I was making the game in Unity, pathfinding of 20+ macs/arcs would be one of the main issues (especially if the path mesh is dynamic), and dynamic infestation the other. Everything else (Power Nodes, Armoury, Arms Lab, CC, Upgrades, etc) would have no real performance impact. They should sit there counting and broadcast events when they're done, and when attacked, their health decreases, etc. Unless they're aware of every other object, and the player is aware of them all, then there should be no performance impact.
I still think mappers have gone overkill with the amount of lights they use. And the way the maps are built out of individual quads, with tons of materials slapped all over them, what kind of batching is done on these?
I wonder if Spark is using LUAJIT or if UWE is at least planning to experiment with it. LUAJIT, in addition to JITting code (as opposed to interpreting, which is slower), also enables you to use fibers (kind of lightweight "threads") which might help increase performance on multi-core CPUs depending on how well they're used.
I'd like to hear from UWE about that.
In the interview with Brian they mentioned they're experimenting with LuaJIT.
They took a risk using their own engine, didn't work out.
It worked out spectacularly well, and the future of UWE is brighter for it. The financial, technical, creative, and intellectual freedom that Spark has granted UWE is immeasurably valuable.
Judging the engineering value of an entire game engine by the behaviour of a particular game's late game performance when entities are exploding out of every pore on a is utterly ridiculous.
The engine failed mate, Spark was made FOR NS2 so how else will we judge it. It might of been a success for the financial, technical, creative and intellectual freedom of UWE but from a players perspective it just did not deliver.
I don't see where the engine failed, and you didn't say it either. You are just repeating that while other have posted some value comments about the engine NOT being the problem.
Btw you can test it yourself, I seriously don't think the engine is the problem (at least in terms of pure FPS).
If lighting and logic-heavy things like the powergrid/infestation are the main culprits for bad performance, why on earth do we have them if they affect the #1 reason for dissatisfaction with the game? It seems like an absolutely crazy tradeoff - and that's ignoring the arguments for why those things may actually detract from the game anyway.
UWE took a risk using Max's engine over the source engine to follow their creative idea's about how they wanted NS2 to be played. I'm sure there are a thousand financial / business related decisions regarding this as well that we will never know.
I agree mosty with what you said.
But know this: Source is ridiculously complicated and outdated - especially compared to something like UE3 or CE3 which still apparently do not have all the capabilities that Sparks offers for NS2 (so the game would have been made around these limitations if they used a third party engine).
Why UWE even considered making NS2 on Source, I will never understand. They probably started with Source as it allowed fast prototyping as they were already familiar with it, but not much else.
In short: Source never was a real option.
It was "use best third party engine" or "make own engine" all along.
Lighting currently does hurt performance slightly, but its not the dynamic lighting/powergrid system that appears to cause it. Also, the impacts of infestation in the new builds is quite minimal, even with those elements (powergrid/infestation) stripped out your FPS gain at best would be 5%, and probably less tbh. There seems to be a lot of garbage generated by the lights currently, which is why you see FPS improvements on NSL maps which remove massive amounts of lights, however that does little to help the server performance or the other issues plaguing client performance.
The overall truth is that there hasn't been experiments on a stripped down codebase to see what would be possible in Spark with a vastly simplified game logic AFAIK, really that's something I would have expected to see from the combat team - they could remove massive amounts of game logic. I don't see there being notable improvements in frame rates unless you massively simply the game logic at this point, baring underlying engine changes that speed up the LUA/Renderer. I think they have optimized their current logic close to as far as possible.
Spark on its own is probably actually quite a fast engine, baring the lua aspects however where I do think they could make (and I'm sure they know better than I do) improvements.
They took a risk using their own engine, didn't work out.
It worked out spectacularly well, and the future of UWE is brighter for it. The financial, technical, creative, and intellectual freedom that Spark has granted UWE is immeasurably valuable.
Judging the engineering value of an entire game engine by the behaviour of a particular game's late game performance when entities are exploding out of every pore on a is utterly ridiculous.
The engine failed mate, Spark was made FOR NS2 so how else will we judge it. It might of been a success for the financial, technical, creative and intellectual freedom of UWE but from a players perspective it just did not deliver.
- Client Performance: People have to OC to 4+ghz to maintain 60 fps. This STILL does not work late game with people dipping to 40-50
- Server Performance: The game struggles to run on medium spec rack mounted servers (2.2-3.0Ghz). Server operators had to purchase consumer grade desktops, install massive fans/heatsinks and OC to 4.0Ghz to maintain 30 ticks
- Server Performance: 30 ticks is unacceptable for a game this fast paced. I ran 100/100 rates w/ 0.01 interp in NS1 and the feedback/rego was instant. There is atleast a half second delay in damage feedback when playing marines
The number one complaint I have from the 50+ people I convinced to purchase NS2 was that they could not understand why they can run BF3 at 100fps, but NS2 at 40-50fps. Hell, even Planetside 2 runs far better...
UWE took a risk using Max's engine over the source engine to follow their creative idea's about how they wanted NS2 to be played. I'm sure there are a thousand financial / business related decisions regarding this as well that we will never know.
I would of loved to see NS2:source, the game would of been amazing. Shame...
FYI: 99% of the competitive community for Australia played TF2. A fast paced action shooter on the source engine...
I ran this game off of a 4 year old 2.67 quad core with a 9800 GTX. I had better framerates than what you're claiming here. If you want to be taken seriously, stop and start by using tangible evidence that is not being exaggerated and generalized to try and save face when confronted by others who do. You can't claim that everyone has to overclock to 4+ to achieve decent FPS. That's blatantly false and misleading. Your argument is childish.
I run this game with a stock i5, a stock 660 gtx (not ti) and I get 100+ fps on average. I have never seen it dip below 80. My team runs multiple instances of NS2 server-side on one server machine and tickrates are never bad (save for new builds releasing causing issues with server-side mods).
The first thing I recommend to all players who experience any sort of performance hitches in this game - stop playing on 20+ man servers. They are the reason you think performance is bad and they are the reason you think balance is bad. This game is designed around 6v6-9v9 (highest). I only play on 16-18 man servers. Every once in a while I hop on to a 22 or 24 man server and it's clear as day.
I know what will fix the performance issues!
Everyone buy an i7. Overclock it to 5GHZ and stop bitching
Even this is not a solution. Im running the game with an i7 3770K 4.9 Ghz and I can in a 6v6 game (!!) on a NSL map get down to 40 fps in combat with a lot of entities nearby and as you all know 40 fps in this game feels like 15 fps in any other game which is completly unplayable.
Playing this game competitively 6v6 doing a 4-5 man hive push mid- /lategame with macs/arcs etc in combat there's no way no one can get above 50 fps no matter what specs you have. I think this is very sad and I'd say the performance should be prioritized over everything with regards to developing this game. I'd even approve of changing the actual gameplay of this game to improve the performance, e.g., removing macs, arcs, babblers, etc to remove the amount of entities. I'd rather use ns1 sieges if it would mean a performance increase.
The problem is that the performance issues aren't just holding new players off of this game but the commited player base is shrinking as well because of this issue as well. I know that a large portion of the people of the competitive scene is trying to highlight the importance of this issue to UWE but they seem to fail to realize that more drastic measures need to be taken to address this issue.
I run this game with a stock i5, a stock 660 gtx (not ti) and I get 100+ fps on average. I have never seen it dip below 80. My team runs multiple instances of NS2 server-side on one server machine and tickrates are never near as low as 30.
They certainly don't go any higher than 30, do they? (And yesterday your west coast server was fluctuating around 20-27 ticks, rarely even making it up to 30.. but i have a feeling that's related to the new patch since your servers are usually great)
They took a risk using their own engine, didn't work out.
It worked out spectacularly well, and the future of UWE is brighter for it. The financial, technical, creative, and intellectual freedom that Spark has granted UWE is immeasurably valuable.
Judging the engineering value of an entire game engine by the behaviour of a particular game's late game performance when entities are exploding out of every pore on a is utterly ridiculous.
The engine failed mate, Spark was made FOR NS2 so how else will we judge it. It might of been a success for the financial, technical, creative and intellectual freedom of UWE but from a players perspective it just did not deliver.
I don't see where the engine failed, and you didn't say it either. You are just repeating that while other have posted some value comments about the engine NOT being the problem.
Btw you can test it yourself, I seriously don't think the engine is the problem (at least in terms of pure FPS).
NS2 was in development for about 7 years. If you look a the status of both gameplay and performance/technical features 5, 6 years after start of development and even at the time of the actual release, you cannot deny that obviously the "engineering" part of the game took ALOT (and by this I mean most) of the ressources until at least the year before the release.
I remember that 2 years before release when I bought the game there basically was no gameplay(in consequence there was 1 EU server running) and the performance was abmyssal despite major graphic features not even being implemented.
So even if the engine now was fcking awesome and only the game logics sucked performance wise[As a player I actually dont give a damn which of both sucks because bad performance is bad performance] it is really no exaggeration to say that this whole engine business cost AT LEAST 3 or 4 years of development time AND forced UWE to release a product that was clearly not in the state everyone hoped it to be at that point.
NS2 sold good because it has lots of awesome gameplay ideas and really in theory could be a near perfect teambased Multiplayer game.
NS2 lost alot of(this means most) players within the first weeks after release. Of course you can say this is because it is sooo complicated and hard to learn. I dont think this is true. I strongly believe and experianced first hand that most people quit NS2 because of a) bad performance or b) substantial gameplay flaws and imbalances of the release-version. Or both.
Both a) and b) were directly affected by the decision to try to accomplish with 5 people what other companies manage with more than 100. So even if the engine now was the best there is it still screwed NS2 badly. With a game like NS2 you dont have a virtually infinite potential playerbase which you can tab with NS3 or a nice addon like you have for say CoD or Diablo. I'd say NS2 sold to a substantial part of the potential playerbase for this kind of game and it will be very hard to sell NS3 to these very people who got bitterly disappointed for reasons that are mainly caused by the development of the engine.
So in short: No, it was not a very clever decision not to use a licensed engine.
They took a risk using their own engine, didn't work out.
It worked out spectacularly well, and the future of UWE is brighter for it. The financial, technical, creative, and intellectual freedom that Spark has granted UWE is immeasurably valuable.
Judging the engineering value of an entire game engine by the behaviour of a particular game's late game performance when entities are exploding out of every pore on a is utterly ridiculous.
The engine failed mate, Spark was made FOR NS2 so how else will we judge it. It might of been a success for the financial, technical, creative and intellectual freedom of UWE but from a players perspective it just did not deliver.
I don't see where the engine failed, and you didn't say it either. You are just repeating that while other have posted some value comments about the engine NOT being the problem.
Btw you can test it yourself, I seriously don't think the engine is the problem (at least in terms of pure FPS).
NS2 was in development for about 7 years. If you look a the status of both gameplay and performance/technical features 5, 6 years after start of development and even at the time of the actual release, you cannot deny that obviously the "engineering" part of the game took ALOT (and by this I mean most) of the ressources until at least the year before the release.
It took a lot of resources of course, but it would have cost A FREAKING LOT of resources to adapt an engine that was not made at all for the gameplay nor technology that NS demands.
It would have take a lot of time to tweak to get what Uwe wanted. That topic has already been discussed and covered a lot of times.
Regarding the feeling of low FPS (such as 60 feeling more like 40 compared to some other games, for example), I feel this is the case as well but obviously it's difficult to prove since it's a feeling... until now...
With the introduction of the bots it's very simple to prove this to be plausible. Simply starting a bot game with the default 16 on the Descent gives me 90-100 FPS in the ready room, the in-game FPS counter says, but by moving the camera it's very clearly performing, or "feeling", like no more than 30 FPS and it's so obvious that it's indisputable.
Of course when playing the real game your client won't be calculating bot moves, but to me it shows the FPS counter under some circumstances does not at all represent actual in-game performance, and now that I've seen it very clearly I'm certain these circumstances also exist in real gameplay. Not as extreme, but still very heavily.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
@lwf the ready room should never be used as a reference for anything performance.. its hard to explain but basically its a different universe entirely, far from rendering the rest of the world and even with different physics..
Just fyi.
If you can capture /reproduce ANYTHING to quantify or measure what you are describing though (thats not RR) please please let me or a dev know!
Thanks!
I wonder if Spark is using LUAJIT or if UWE is at least planning to experiment with it. LUAJIT, in addition to JITting code (as opposed to interpreting, which is slower), also enables you to use fibers (kind of lightweight "threads") which might help increase performance on multi-core CPUs depending on how well they're used.
I'd like to hear from UWE about that.
Yes this is something we're actively working on right now. It's complicated, so it'll take time, but we're working on it.
...
I would of loved to see NS2:source, the game would of been amazing. Shame...
FYI: 99% of the competitive community for Australia played TF2.
TF2 (and Borderlands 1,2) have a comic like look, so the graphics doesnt matter so much.
BUT NS2 has a realistic look... the source engine is to old for this, but ok in TF2 it doesnt matter so much.
The Spark Engine looks great (and it has real time lightning!). The problem is not really the Spark-Engine, its
more the use of LUA as an logical game part of it. I guess if it would be all c++, the performance would be fine
and nobody would be complaining about it.
They tried the source-engine for NS2. Years ago there was an infestation-growing video, but i guess they had
their reasons to build up an own engine at this time.
Simply starting a bot game with the default 16 on the Descent gives me 90-100 FPS in the ready room, the in-game FPS counter says, but by moving the camera it's very clearly performing no, or "feeling", so much more like no more than 30 FPS it's indisputable..
Like I said, testing performance from the ready room is *never* a good environment to test from for reasons listed above, so it definitely does matter.
Its worth reproducing this in game, like you said you did.
I appreciate your effort in attempting to reproduce this, i'm looking into it myself right now.
If you find anything further please let me know.
Thanks!
Don't need to go that far to get an accurate representation of things such as hitching or intermittent lag. Simply making a frametime graph sorted from quickest to slowest rendered frame should suffice. That method is mostly useful in investigating hardware/driver fps issues rather than game ones.
it is really no exaggeration to say that this whole engine business cost AT LEAST 3 or 4 years of development time AND forced UWE to release a product that was clearly not in the state everyone hoped it to be at that point.
It IS an exaggeration to say that. Yes, using our own tech did set us back, maybe a year, but using another existing code base (particularly Source) is no picnic either. It can be very time consuming for programmers to try and learn and work through all the layers in those engines, and there is a lot of fighting against stuff that wasn't designed for the kind of game we were making.
Some factors when deciding to go with our own engine. We had almost no money. We could not afford to license an existing engine, and did not want to have to pay out an exorbitant amount of money in royalties down the road. There were also fewer options for game engines then there are now. Additionally we thought we'd still be able to license and use the source tools, like Hammer, even though we were using our own engine, but we found out later that Valve would not allow that. So, we had to spend a lot of time creating our own tools - map editor, FX editor, etc.
And, of course, as is common knowledge, we wanted to use a code base that could make modding for NS2 much easier to do. Some people in this thread say they don't care about the flexibility of the engine, only the final end product game, but the whole idea behind making our engine so moddable WAS to make the end experience better for players. More mods = more options for the playing experience. Yes, we paid a price in performance costs, but early in development there was no real well of telling how much of a cost that would be.
I wonder if Spark is using LUAJIT or if UWE is at least planning to experiment with it. LUAJIT, in addition to JITting code (as opposed to interpreting, which is slower), also enables you to use fibers (kind of lightweight "threads") which might help increase performance on multi-core CPUs depending on how well they're used.
I'd like to hear from UWE about that.
And since you seem to be fairly technically minded, the major challenge we face with LuaJIT is the Lua->C++ API. For LuaJIT to be performant, you have to architect that API in some pretty specific ways, otherwise you will always break the JIT compiles and get almost no benefit from it. Completely changing the API is not an attractive option (rewrite a lot of code..break all the mods..), so we're currently investigating ways of avoiding this.
I love this game to death, I've clocked nearly 600 hours on it since the early beta days but between the horrid mid to late performance and the stale gameplay, there's not much that makes me want to pick up this game at the moment. So yeah, here's to hoping Sewlek's balance patch ever makes it into the full game, accompanied by some more much needed optimisations.
And since you seem to be fairly technically minded, the major challenge we face with LuaJIT is the Lua->C++ API. For LuaJIT to be performant, you have to architect that API in some pretty specific ways, otherwise you will always break the JIT compiles and get almost no benefit from it. Completely changing the API is not an attractive option (rewrite a lot of code..break all the mods..), so we're currently investigating ways of avoiding this.
Tell us more! Reading about things like this gives me a "break out the profiler" itch. It's exciting. Is there a performance sensitive subset you could rewrite, and assume the remainder will fall back to being interpreted?
Comments
The engine failed mate, Spark was made FOR NS2 so how else will we judge it. It might of been a success for the financial, technical, creative and intellectual freedom of UWE but from a players perspective it just did not deliver.
- Client Performance: People have to OC to 4+ghz to maintain 60 fps. This STILL does not work late game with people dipping to 40-50
- Server Performance: The game struggles to run on medium spec rack mounted servers (2.2-3.0Ghz). Server operators had to purchase consumer grade desktops, install massive fans/heatsinks and OC to 4.0Ghz to maintain 30 ticks
- Server Performance: 30 ticks is unacceptable for a game this fast paced. I ran 100/100 rates w/ 0.01 interp in NS1 and the feedback/rego was instant. There is atleast a half second delay in damage feedback when playing marines
The number one complaint I have from the 50+ people I convinced to purchase NS2 was that they could not understand why they can run BF3 at 100fps, but NS2 at 40-50fps. Hell, even Planetside 2 runs far better...
UWE took a risk using Max's engine over the source engine to follow their creative idea's about how they wanted NS2 to be played. I'm sure there are a thousand financial / business related decisions regarding this as well that we will never know.
I would of loved to see NS2:source, the game would of been amazing. Shame...
FYI: 99% of the competitive community for Australia played TF2. A fast paced action shooter on the source engine...
This is my main concern, no way this can be viable for the long term survival of the game. I can't see official ISPs hosting these type of servers, and if so, for very long.
I'd like to hear from UWE about that.
If I was making the game in Unity, pathfinding of 20+ macs/arcs would be one of the main issues (especially if the path mesh is dynamic), and dynamic infestation the other. Everything else (Power Nodes, Armoury, Arms Lab, CC, Upgrades, etc) would have no real performance impact. They should sit there counting and broadcast events when they're done, and when attacked, their health decreases, etc. Unless they're aware of every other object, and the player is aware of them all, then there should be no performance impact.
I still think mappers have gone overkill with the amount of lights they use. And the way the maps are built out of individual quads, with tons of materials slapped all over them, what kind of batching is done on these?
Btw you can test it yourself, I seriously don't think the engine is the problem (at least in terms of pure FPS).
But know this: Source is ridiculously complicated and outdated - especially compared to something like UE3 or CE3 which still apparently do not have all the capabilities that Sparks offers for NS2 (so the game would have been made around these limitations if they used a third party engine).
Why UWE even considered making NS2 on Source, I will never understand. They probably started with Source as it allowed fast prototyping as they were already familiar with it, but not much else.
In short: Source never was a real option.
It was "use best third party engine" or "make own engine" all along.
The overall truth is that there hasn't been experiments on a stripped down codebase to see what would be possible in Spark with a vastly simplified game logic AFAIK, really that's something I would have expected to see from the combat team - they could remove massive amounts of game logic. I don't see there being notable improvements in frame rates unless you massively simply the game logic at this point, baring underlying engine changes that speed up the LUA/Renderer. I think they have optimized their current logic close to as far as possible.
Spark on its own is probably actually quite a fast engine, baring the lua aspects however where I do think they could make (and I'm sure they know better than I do) improvements.
I ran this game off of a 4 year old 2.67 quad core with a 9800 GTX. I had better framerates than what you're claiming here. If you want to be taken seriously, stop and start by using tangible evidence that is not being exaggerated and generalized to try and save face when confronted by others who do. You can't claim that everyone has to overclock to 4+ to achieve decent FPS. That's blatantly false and misleading. Your argument is childish.
I run this game with a stock i5, a stock 660 gtx (not ti) and I get 100+ fps on average. I have never seen it dip below 80. My team runs multiple instances of NS2 server-side on one server machine and tickrates are never bad (save for new builds releasing causing issues with server-side mods).
The first thing I recommend to all players who experience any sort of performance hitches in this game - stop playing on 20+ man servers. They are the reason you think performance is bad and they are the reason you think balance is bad. This game is designed around 6v6-9v9 (highest). I only play on 16-18 man servers. Every once in a while I hop on to a 22 or 24 man server and it's clear as day.
Even this is not a solution. Im running the game with an i7 3770K 4.9 Ghz and I can in a 6v6 game (!!) on a NSL map get down to 40 fps in combat with a lot of entities nearby and as you all know 40 fps in this game feels like 15 fps in any other game which is completly unplayable.
Playing this game competitively 6v6 doing a 4-5 man hive push mid- /lategame with macs/arcs etc in combat there's no way no one can get above 50 fps no matter what specs you have. I think this is very sad and I'd say the performance should be prioritized over everything with regards to developing this game. I'd even approve of changing the actual gameplay of this game to improve the performance, e.g., removing macs, arcs, babblers, etc to remove the amount of entities. I'd rather use ns1 sieges if it would mean a performance increase.
The problem is that the performance issues aren't just holding new players off of this game but the commited player base is shrinking as well because of this issue as well. I know that a large portion of the people of the competitive scene is trying to highlight the importance of this issue to UWE but they seem to fail to realize that more drastic measures need to be taken to address this issue.
They certainly don't go any higher than 30, do they? (And yesterday your west coast server was fluctuating around 20-27 ticks, rarely even making it up to 30.. but i have a feeling that's related to the new patch since your servers are usually great)
NS2 was in development for about 7 years. If you look a the status of both gameplay and performance/technical features 5, 6 years after start of development and even at the time of the actual release, you cannot deny that obviously the "engineering" part of the game took ALOT (and by this I mean most) of the ressources until at least the year before the release.
I remember that 2 years before release when I bought the game there basically was no gameplay(in consequence there was 1 EU server running) and the performance was abmyssal despite major graphic features not even being implemented.
So even if the engine now was fcking awesome and only the game logics sucked performance wise[As a player I actually dont give a damn which of both sucks because bad performance is bad performance] it is really no exaggeration to say that this whole engine business cost AT LEAST 3 or 4 years of development time AND forced UWE to release a product that was clearly not in the state everyone hoped it to be at that point.
NS2 sold good because it has lots of awesome gameplay ideas and really in theory could be a near perfect teambased Multiplayer game.
NS2 lost alot of(this means most) players within the first weeks after release. Of course you can say this is because it is sooo complicated and hard to learn. I dont think this is true. I strongly believe and experianced first hand that most people quit NS2 because of a) bad performance or b) substantial gameplay flaws and imbalances of the release-version. Or both.
Both a) and b) were directly affected by the decision to try to accomplish with 5 people what other companies manage with more than 100. So even if the engine now was the best there is it still screwed NS2 badly. With a game like NS2 you dont have a virtually infinite potential playerbase which you can tab with NS3 or a nice addon like you have for say CoD or Diablo. I'd say NS2 sold to a substantial part of the potential playerbase for this kind of game and it will be very hard to sell NS3 to these very people who got bitterly disappointed for reasons that are mainly caused by the development of the engine.
So in short: No, it was not a very clever decision not to use a licensed engine.
It would have take a lot of time to tweak to get what Uwe wanted. That topic has already been discussed and covered a lot of times.
With the introduction of the bots it's very simple to prove this to be plausible. Simply starting a bot game with the default 16 on the Descent gives me 90-100 FPS in the ready room, the in-game FPS counter says, but by moving the camera it's very clearly performing, or "feeling", like no more than 30 FPS and it's so obvious that it's indisputable.
Of course when playing the real game your client won't be calculating bot moves, but to me it shows the FPS counter under some circumstances does not at all represent actual in-game performance, and now that I've seen it very clearly I'm certain these circumstances also exist in real gameplay. Not as extreme, but still very heavily.
Just fyi.
If you can capture /reproduce ANYTHING to quantify or measure what you are describing though (thats not RR) please please let me or a dev know!
Thanks!
I don't know how to measure it without an expensive setup such as this one. I don't have that.
http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin
Yes this is something we're actively working on right now. It's complicated, so it'll take time, but we're working on it.
TF2 (and Borderlands 1,2) have a comic like look, so the graphics doesnt matter so much.
BUT NS2 has a realistic look... the source engine is to old for this, but ok in TF2 it doesnt matter so much.
The Spark Engine looks great (and it has real time lightning!). The problem is not really the Spark-Engine, its
more the use of LUA as an logical game part of it. I guess if it would be all c++, the performance would be fine
and nobody would be complaining about it.
They tried the source-engine for NS2. Years ago there was an infestation-growing video, but i guess they had
their reasons to build up an own engine at this time.
Its worth reproducing this in game, like you said you did.
I appreciate your effort in attempting to reproduce this, i'm looking into it myself right now.
If you find anything further please let me know.
Thanks!
No it did not. The real development time was about 3.5 years, with some tech tests being done on the Source engine maybe a year before that.
It IS an exaggeration to say that. Yes, using our own tech did set us back, maybe a year, but using another existing code base (particularly Source) is no picnic either. It can be very time consuming for programmers to try and learn and work through all the layers in those engines, and there is a lot of fighting against stuff that wasn't designed for the kind of game we were making.
Some factors when deciding to go with our own engine. We had almost no money. We could not afford to license an existing engine, and did not want to have to pay out an exorbitant amount of money in royalties down the road. There were also fewer options for game engines then there are now. Additionally we thought we'd still be able to license and use the source tools, like Hammer, even though we were using our own engine, but we found out later that Valve would not allow that. So, we had to spend a lot of time creating our own tools - map editor, FX editor, etc.
And, of course, as is common knowledge, we wanted to use a code base that could make modding for NS2 much easier to do. Some people in this thread say they don't care about the flexibility of the engine, only the final end product game, but the whole idea behind making our engine so moddable WAS to make the end experience better for players. More mods = more options for the playing experience. Yes, we paid a price in performance costs, but early in development there was no real well of telling how much of a cost that would be.
And since you seem to be fairly technically minded, the major challenge we face with LuaJIT is the Lua->C++ API. For LuaJIT to be performant, you have to architect that API in some pretty specific ways, otherwise you will always break the JIT compiles and get almost no benefit from it. Completely changing the API is not an attractive option (rewrite a lot of code..break all the mods..), so we're currently investigating ways of avoiding this.
http://terralang.org/
Tell us more! Reading about things like this gives me a "break out the profiler" itch. It's exciting. Is there a performance sensitive subset you could rewrite, and assume the remainder will fall back to being interpreted?