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.
Just face it.. The game is never going to run on a 3 year old pc... Just get with the times and dip into your wallet
i have i5 3570k @4.2 , zotac gtx 680 4gb edition. its not even a years old. cpu could use an upgrade but i53570k is still a decent cpu but still i see 35 fps. if i were to buy parts for a decent fps in this game i would have to eat my wallet after it.
don't misinform people and try to find excuses at their end. the game has issues with performance end of the story.
When it affects the playability of the game to the point where players do not/can not continue playing, its not that ridiculous. I know several personal examples of players who stopped playing, before even complaining about the gameplay (for reference, I have some scrubby friends).
There are obviously advantages to going the route that uwe did, but you can not ignore the problems of performance.
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.
from the players' point of view, it's kind of ridiculous that the only way to get 60 fps is to overclock high-end hardware... forget about 120...
and this isn't even a pretty game or a particularly complicated one... it's a somewhat small-scale multiplayer game in an arena - a problem that was more or less solved 15 years ago
using the game it was specifically made for (which happens to be the only game using it) is usually the most generous way to judge an engine...
maybe Spark is amazing at some other type of game? that still doesn't mean it works out for NS2...
as a programmer, I can see the value in having something slower but more flexible for development
that would allow a small team to make a huge game or to iterate extremely rapidly
but UWE is a small team making a tiny game (in terms of actual game logic) that barely changes at all
smaller teams using technology from 20 years ago made entire games in the time it took to add babblers, gorge tunnels, and a railgun to spark
if entities are the problem, why would someone add babblers to the game?
does not compute
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.
Having played the game since the engine test, I can safely say that NS2 wouldn't have been released yet had UWE stuck with Source. I don't think people who haven't touched the spark editor/decoda realize how much easier it makes game development.
When it affects the playability of the game to the point where players do not/can not continue playing, its not that ridiculous.
Whether you mean to or not, you are putting up a straw man, to make me look like I said something I didn't. No one at UWE, not me not anyone, questions the assertion that late game performance in Natural Selection 2 is not as good as it should be.
What I said was, judging an entire game engine by the way a particular game runs in a particular situation is... Ridiculous! You could take the late-game logic of Natural Selection 2 and put it into CryEngine 3 (Which, like Spark, is written in C++ and uses Lua for game logic) and watch machines struggle to keep up. You are confusing game with engine.
Well, seeing as you are a programmer, you won't have much trouble showing me a game made using twenty year old tech that is bigger in scope, more complicated in execution, and richer in intricate logic and interdependencies than NS2. I went through a few Id-Tech 1 games in my head... Came up empty. I have subscribed to this thread and eagerly await your reply!
Bought 4 extra copies for my friends, all 4 stopped playing after day 1 because they complained about the performance issues. Even though I get 10 fps late game, I still play often because NS2 is that great of a game.
Ns2 is a diamond in the rough, just needs performance issue polishing and it will shine better than any other game out there.
NS2 runs fine for me. I also bought a new computer the day NS2 came out. Regardless it's bogus to say with absolute certainty that EVERYONE has the same issue with performance that you do. I wish the game would run better for my friends with less amazing computers too but that doesn't mean the game is broken.
An easy place to start is to remove clutter from the maps. You guys did a great job making the maps very detailed, but having 20+ individual cups in cafe or 100+ servers in server room can't be helping performance. I have no idea how many things could be removed or replaced with flat textures, or even if it would give a noticeable performance increase but maybe it's worth a shot.
I think when you get to this stage in the game's lifetime, most players are here for the gameplay and not the ooohh shiny things
As stated in this thread and many others, people are having issues with performance mid to late game. Most do not have a problem running at an acceptable frame rate at the beginning of the game, so it is not the level of detail in the maps that are the main culprit. And in fact, the benchmarks we've done show that the rendering time on high detail areas is really not a noticeable factor in the framerate, and the Spark engine can push around a surprising amount of poly detail. Clearly, if you look at extremes - a greybox map vs a fully textured and prop detailed one -- there will be framerate differences, but anything much short of that is not going to be a win for performance, compared to the loss in visual quality and time spent to make all those changes.
On the visual side, lighting probably has the most impact on framerate, as well as the various layers of effects such as ambient occlusion, but beyond that, it is largely the game that is running on top of the graphics engine that is hurting performance the most, and and where we have spent and are spending a lot of our time optimizing.
and this isn't even a pretty game or a particularly complicated one... it's a somewhat small-scale multiplayer game in an arena - a problem that was more or less solved 15 years ago
Well, naturally I take exception to the comment that NS2 is not a pretty game. Running it at full quality, I think it can hold up quite well to most games out there, in level of detail, texture quality, etc. And NS2 is by no means a small - scale multiplayer game, when you really get into the level of complexity that is in the game, compared to many other FPS shooters. Sure, some may be able to support more players - different versions of the same guys running around with guns, basically - but they don't have to deal with stuff like dynamic infestation, and all the structure entities for both sides, and commander mode, etc. If we made the game into a marine vs marine and removed the RTS side, and thus all the structures and other entities that are always needing to be updated in the game code, there would likely be far fewer, if any, complaints about performance.
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.
So true. Though saying it was a total success is absolutely foolish. it hasn't reached the stage of total success yet. So Mf's comment is semi correct. though a little rude and uneducated (as usual).
Spoken like a true games developer, hugh! You're getting into the curve. soon you'll be more than just spokesman.
An easy place to start is to remove clutter from the maps. You guys did a great job making the maps very detailed, but having 20+ individual cups in cafe or 100+ servers in server room can't be helping performance. I have no idea how many things could be removed or replaced with flat textures, or even if it would give a noticeable performance increase but maybe it's worth a shot.
I think when you get to this stage in the game's lifetime, most players are here for the gameplay and not the ooohh shiny things
Polygon count is the least problem in today's games. It's more about how much stuff is visible at the same time. And things may look like 100+ servers to you, but the question is whether each server is an individual mesh that got duplicated or whether it's just a few meshes that look like 25+ servers combined. Because that makes quite a difference for the GPU in terms of draw calls and batching.
I think it wouldn't be a bad idea to make NSL maps the default maps of the game. Having in mind that the game has horrible performance, I guess most people would prefer more fps above "cool lights".
An easy place to start is to remove clutter from the maps. You guys did a great job making the maps very detailed, but having 20+ individual cups in cafe or 100+ servers in server room can't be helping performance. I have no idea how many things could be removed or replaced with flat textures, or even if it would give a noticeable performance increase but maybe it's worth a shot.
I think when you get to this stage in the game's lifetime, most players are here for the gameplay and not the ooohh shiny things
What you're suggesting would result in reduced graphics quality for all NS2 players (including those who don't suffer from performance problems). Let's be real here, guys - That's simply not an option. I'm surprised you guys would actually think twice about such an unrealistic proposal, let alone make a post about it.
and this isn't even a pretty game or a particularly complicated one... it's a somewhat small-scale multiplayer game in an arena
The part about the game not being pretty is a matter of opinion and I disagree with you. I find NS2's graphics very enjoyable and aesthetically pleasing. The graphics are also technically excellent. There are very few current games that surpass NS2's graphics from a technical standpoint.
As for the level of complexity - most FPS games are not simultaneously RTS games. Suggesting that NS2 is small-scale and uncomplicated is naive.
I have to admit that I no longer play this game due to the massively unrealistic requirements that are placed on the hardware.
No game developer can expect to create a product with such requirements, have their fans all purchase new top-of-the-line computers, and increase the player base. It's a simple fact that most people are casual players. They don't care to pay a large sum of money to play one game when there are several fun alternatives available that run very well on their current computers.
That being said, it was certainly brave to create their own engine. Particularly true when considering the routes available for implementation as a mod, both official and unofficial (like NS1). I mean, Garry of Garry's Mod, for example, has sales ranging over $20,000,000.00 and exemplary stability, performance, and flexibility.
My questions are, if anyone from the development crew are listening:
1. Have you tried implementing multi-threading into your CPU taxing Lua?
2. Have you tried implementing your Lua as C or C++? (I'm not asking _why_ you chose Lua..I think I know why )
And, after reading some of the posts here, it seems like many people are very correct in their assertions of this issue. Even those that are directly focused for comment by developers. For example, it is fair to judge an engine by the way it performs in game (what else are we going to judge it by?). If you were to say that the Lua could be removed and the engine would perform differently......then that's exactly what you should do with the game.
Well, seeing as you are a programmer, you won't have much trouble showing me a game made using twenty year old tech that is bigger in scope, more complicated in execution, and richer in intricate logic and interdependencies than NS2. I went through a few Id-Tech 1 games in my head... Came up empty. I have subscribed to this thread and eagerly await your reply!
I said games that were bigger than anything NS2 has done since launch (basically the Gorgeous update), not NS2 in its entirety
from a dev standpoint it's awesome to be able to create things quickly, but I disagree that it was the best outcome for NS2. performance woes did permanent harm to the game's chances.
"it worked out spectacularly well" is just a lie based on the hardware configurations gamers actually have. has anyone actually benchmarked the game on minimum/recommended specs? let's not pretend they are sufficient when people with far superior computers are struggling
as for the graphics looking great on higher settings, I wouldn't know because higher settings are not even part of the game until I can run the lower settings at 120 fps...
My questions are, if anyone from the development crew are listening:
1. Have you tried implementing multi-threading into your CPU taxing Lua?
2. Have you tried implementing your Lua as C or C++? (I'm not asking _why_ you chose Lua..I think I know why )
And, after reading some of the posts here, it seems like many people are very correct in their assertions of this issue. Even those that are directly focused for comment by developers. For example, it is fair to judge an engine by the way it performs in game (what else are we going to judge it by?). If you were to say that the Lua could be removed and the engine would perform differently......then that's exactly what you should do with the game.
I emailed them in the past and got a pretty good answer about the whole C++ thing:
"Rewriting all of the game play code would be a major undertaking during which we would have no time to fix existing bugs and optimize inefficiencies that we have already identified. Worse, a rewrite would inevitably introduce many new bugs and break existing high level optimizations. Basically after doing months of busy work rewriting everything in C++ we'd have a much buggier, less flexible and slower code base than if we'd spend that time optimizing and fixing what we already have (plus we'd break all the mods).
Lua gets a lot of hate but the benefits of using it far outweigh the costs. We will continue to work hard on improving performance for the foreseeable future and the late game framerate is high up on our hit list."
Ns2 may struggle barely on 3 year old computers. A 2 year old sandy bridge 3ghz+ quad core does just great even at stock clocks.
going to have to disagree, though obviously what is great is subjective. I have above what you suggest(3.2ghz) and get an average of 45ish fps, and it still feels quite choppy as a skulk or marine.
What I said was, judging an entire game engine by the way a particular game runs in a particular situation is... Ridiculous! You could take the late-game logic of Natural Selection 2 and put it into CryEngine 3 (Which, like Spark, is written in C++ and uses Lua for game logic) and watch machines struggle to keep up. You are confusing game with engine.
I seriously doubt your claim that other engines would fall apart is accurate. CryEngine3 specifically *might* if it is as comprehensive in using LUA, but CryEngine 3 isn't really used for logic-heavy games like an RTS. The people writing the engine didn't have complex logic in mind when developing it. There are other engines out there that do not have trouble with logic. Late game is specifically slowed down due to the game either being poorly written or relying too heavily on LUA. Think of how much actually goes on late game. Is it a lot? It isn't. If you compare NS2 to an RTS game like Starcraft 2 you'll notice how ridiculous the claim that NS2 is logic-heavy is. NS2 doesn't have a lot going on at all. Imagine 600 moving entities in NS2. The CPU would ignite. There's a serious bottleneck on the CPU side of things that other engines do not experience. It definitely has nothing to do with poly count, shaders, particles or anything to do with rendering. One can stare into a corner the entire game and the framerate will drop into late game as well.
I also want to double the point that "it worked out spectacularly well" is definitely wrong. While you guys have had a lot of success, you've definitely also lost a large amount of sales simply because the CPU requirements for the game are bizarrely ridiculous. Computer sales are falling. Most people do not have CPUs from the last 2 or 3 years, those being required to play the game at a decent framerate. The other poster is right. The bulk of computers people own are in the *casual* range. Notebooks have outsold desktops for a long time, and they always have CPUs significantly weaker than desktops. The largest target audience was simply missed.
My questions are, if anyone from the development crew are listening:
1. Have you tried implementing multi-threading into your CPU taxing Lua?
2. Have you tried implementing your Lua as C or C++? (I'm not asking _why_ you chose Lua..I think I know why )
And, after reading some of the posts here, it seems like many people are very correct in their assertions of this issue. Even those that are directly focused for comment by developers. For example, it is fair to judge an engine by the way it performs in game (what else are we going to judge it by?). If you were to say that the Lua could be removed and the engine would perform differently......then that's exactly what you should do with the game.
I emailed them in the past and got a pretty good answer about the whole C++ thing:
"Rewriting all of the game play code would be a major undertaking during which we would have no time to fix existing bugs and optimize inefficiencies that we have already identified. Worse, a rewrite would inevitably introduce many new bugs and break existing high level optimizations. Basically after doing months of busy work rewriting everything in C++ we'd have a much buggier, less flexible and slower code base than if we'd spend that time optimizing and fixing what we already have (plus we'd break all the mods).
Lua gets a lot of hate but the benefits of using it far outweigh the costs. We will continue to work hard on improving performance for the foreseeable future and the late game framerate is high up on our hit list."
Additionally, the complete rewrite is a programmer's nightmare. It's generally frowned upon and quite rightly ridiculed because these types of issues should have been uncovered during the planning phase.
However, I have encountered a few of these situations. On one hand we have what we've already done, but it doesn't actually meet our project's scope as we've planned. We also have issues where this implementation has limitations on what can actually be improved. Then on the other hand, we have something that is not easy to do and introduces more issues, but can actually be the drastic improvement we're looking for.
In the enterprise environment, this situation is cause to replace engineers. We should have had the foresight and planning that eliminated this risk. Unfortunately, with so much time invested we then need to weigh our options: what is the potential of one versus the other? is the sky the limit for one option? is one option limited by power when performing logic?
Quite honestly, the frame rate issues are most likely a side-effect of the problem. The problem being a requirement on real-time processing of scripts that in turn causes input lag, frame lag, and just general performance issues. Aside from waiting for faster processors, there's only so much "optimization" you can do to a script.
I also really hate to sound negative because I really like this game and people that have the ambition to strike out on their own. However, it does not inspire confidence when there are oversights during initial planning that have negative effect like this in the long term. I mean, will this game run better when we all have 6Ghz processors? Or, will the game be expanded to press the limits of its capability as well?
Ultimately, I have to believe UWE wants "investors." Why else would they decide to create a highly mod-capable engine? Yet, these investors are likely to weigh options and it may become difficult to rationalize an investment here, given the options available in our current environment.
Although NS2 runs okay on my machine, I still think the server performance needs a huge tweak, running an overclocked i5/i7 for a server is just insane
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.
Do you expect me, as a consumer and player, to hold the value spark has to UWE higher than the value it has to me?
The performance of the game is only barely acceptable to me as I have an overclocked system. Most people do not and while some crazy people on these forums think 30 - 40 fps is acceptable, it really isn't. Is someone who plays TF2 at 120 fps going to be more or less inclined to play this game when they have to lose so many frames to have the honour to do so?
Seriously though, some have have already noted it and I think it's worthy of further mention: Lower the server cap (or add one into the client) so people can experience the game as it's meant to be played, and not these 12 on 12+ clusterf*cks. There is a reason UWE servers are 16 slots, as servers just get taxed too heavily by these large games where performance consistency goes right out the window.
In additon, I think a ping cap should be implemented (and mandatory) where the user's ping is tracked for the first 10 seconds for connection stability. It's frustrating to stare at the player scoreboard and see half the players on a team having pings of 200+.
Seriously though, some have have already noted it and I think it's worthy of further mention: Lower the server cap (or add one into the client) so people can experience the game as it's meant to be played, and not these 12 on 12+ clusterf*cks. There is a reason UWE servers are 16 slots, as servers just get taxed too heavily by these large games where performance consistency goes right out the window.
In additon, I think a ping cap should be implemented (and mandatory) where the user's ping is tracked for the first 10 seconds for connection stability. It's frustrating to stare at the player scoreboard and see half the players on a team having pings of 200+.
I have a hard enough time trying to join the 24man servers.
Comments
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.
i have i5 3570k @4.2 , zotac gtx 680 4gb edition. its not even a years old. cpu could use an upgrade but i53570k is still a decent cpu but still i see 35 fps. if i were to buy parts for a decent fps in this game i would have to eat my wallet after it.
don't misinform people and try to find excuses at their end. the game has issues with performance end of the story.
There are obviously advantages to going the route that uwe did, but you can not ignore the problems of performance.
from the players' point of view, it's kind of ridiculous that the only way to get 60 fps is to overclock high-end hardware... forget about 120...
and this isn't even a pretty game or a particularly complicated one... it's a somewhat small-scale multiplayer game in an arena - a problem that was more or less solved 15 years ago
using the game it was specifically made for (which happens to be the only game using it) is usually the most generous way to judge an engine...
maybe Spark is amazing at some other type of game? that still doesn't mean it works out for NS2...
as a programmer, I can see the value in having something slower but more flexible for development
that would allow a small team to make a huge game or to iterate extremely rapidly
but UWE is a small team making a tiny game (in terms of actual game logic) that barely changes at all
smaller teams using technology from 20 years ago made entire games in the time it took to add babblers, gorge tunnels, and a railgun to spark
if entities are the problem, why would someone add babblers to the game?
does not compute
Whether you mean to or not, you are putting up a straw man, to make me look like I said something I didn't. No one at UWE, not me not anyone, questions the assertion that late game performance in Natural Selection 2 is not as good as it should be.
What I said was, judging an entire game engine by the way a particular game runs in a particular situation is... Ridiculous! You could take the late-game logic of Natural Selection 2 and put it into CryEngine 3 (Which, like Spark, is written in C++ and uses Lua for game logic) and watch machines struggle to keep up. You are confusing game with engine.
Well, seeing as you are a programmer, you won't have much trouble showing me a game made using twenty year old tech that is bigger in scope, more complicated in execution, and richer in intricate logic and interdependencies than NS2. I went through a few Id-Tech 1 games in my head... Came up empty. I have subscribed to this thread and eagerly await your reply!
Ns2 is a diamond in the rough, just needs performance issue polishing and it will shine better than any other game out there.
On the visual side, lighting probably has the most impact on framerate, as well as the various layers of effects such as ambient occlusion, but beyond that, it is largely the game that is running on top of the graphics engine that is hurting performance the most, and and where we have spent and are spending a lot of our time optimizing. Well, naturally I take exception to the comment that NS2 is not a pretty game. Running it at full quality, I think it can hold up quite well to most games out there, in level of detail, texture quality, etc. And NS2 is by no means a small - scale multiplayer game, when you really get into the level of complexity that is in the game, compared to many other FPS shooters. Sure, some may be able to support more players - different versions of the same guys running around with guns, basically - but they don't have to deal with stuff like dynamic infestation, and all the structure entities for both sides, and commander mode, etc. If we made the game into a marine vs marine and removed the RTS side, and thus all the structures and other entities that are always needing to be updated in the game code, there would likely be far fewer, if any, complaints about performance.
So true. Though saying it was a total success is absolutely foolish. it hasn't reached the stage of total success yet. So Mf's comment is semi correct. though a little rude and uneducated (as usual).
Spoken like a true games developer, hugh! You're getting into the curve. soon you'll be more than just spokesman.
Polygon count is the least problem in today's games. It's more about how much stuff is visible at the same time. And things may look like 100+ servers to you, but the question is whether each server is an individual mesh that got duplicated or whether it's just a few meshes that look like 25+ servers combined. Because that makes quite a difference for the GPU in terms of draw calls and batching.
Think about it. UWE would have to re-do all their marketing screenshots and videos in order to avoid being accused of false advertising. Just look what happened with Aliens: Colonial Marines.
The part about the game not being pretty is a matter of opinion and I disagree with you. I find NS2's graphics very enjoyable and aesthetically pleasing. The graphics are also technically excellent. There are very few current games that surpass NS2's graphics from a technical standpoint.
As for the level of complexity - most FPS games are not simultaneously RTS games. Suggesting that NS2 is small-scale and uncomplicated is naive.
No game developer can expect to create a product with such requirements, have their fans all purchase new top-of-the-line computers, and increase the player base. It's a simple fact that most people are casual players. They don't care to pay a large sum of money to play one game when there are several fun alternatives available that run very well on their current computers.
That being said, it was certainly brave to create their own engine. Particularly true when considering the routes available for implementation as a mod, both official and unofficial (like NS1). I mean, Garry of Garry's Mod, for example, has sales ranging over $20,000,000.00 and exemplary stability, performance, and flexibility.
My questions are, if anyone from the development crew are listening:
1. Have you tried implementing multi-threading into your CPU taxing Lua?
2. Have you tried implementing your Lua as C or C++? (I'm not asking _why_ you chose Lua..I think I know why
And, after reading some of the posts here, it seems like many people are very correct in their assertions of this issue. Even those that are directly focused for comment by developers. For example, it is fair to judge an engine by the way it performs in game (what else are we going to judge it by?). If you were to say that the Lua could be removed and the engine would perform differently......then that's exactly what you should do with the game.
I said games that were bigger than anything NS2 has done since launch (basically the Gorgeous update), not NS2 in its entirety
from a dev standpoint it's awesome to be able to create things quickly, but I disagree that it was the best outcome for NS2. performance woes did permanent harm to the game's chances.
"it worked out spectacularly well" is just a lie based on the hardware configurations gamers actually have. has anyone actually benchmarked the game on minimum/recommended specs? let's not pretend they are sufficient when people with far superior computers are struggling
as for the graphics looking great on higher settings, I wouldn't know because higher settings are not even part of the game until I can run the lower settings at 120 fps...
Sorry, i guess i misunderstood your post.
I emailed them in the past and got a pretty good answer about the whole C++ thing:
"Rewriting all of the game play code would be a major undertaking during which we would have no time to fix existing bugs and optimize inefficiencies that we have already identified. Worse, a rewrite would inevitably introduce many new bugs and break existing high level optimizations. Basically after doing months of busy work rewriting everything in C++ we'd have a much buggier, less flexible and slower code base than if we'd spend that time optimizing and fixing what we already have (plus we'd break all the mods).
Lua gets a lot of hate but the benefits of using it far outweigh the costs. We will continue to work hard on improving performance for the foreseeable future and the late game framerate is high up on our hit list."
going to have to disagree, though obviously what is great is subjective. I have above what you suggest(3.2ghz) and get an average of 45ish fps, and it still feels quite choppy as a skulk or marine.
I also want to double the point that "it worked out spectacularly well" is definitely wrong. While you guys have had a lot of success, you've definitely also lost a large amount of sales simply because the CPU requirements for the game are bizarrely ridiculous. Computer sales are falling. Most people do not have CPUs from the last 2 or 3 years, those being required to play the game at a decent framerate. The other poster is right. The bulk of computers people own are in the *casual* range. Notebooks have outsold desktops for a long time, and they always have CPUs significantly weaker than desktops. The largest target audience was simply missed.
Additionally, the complete rewrite is a programmer's nightmare. It's generally frowned upon and quite rightly ridiculed because these types of issues should have been uncovered during the planning phase.
However, I have encountered a few of these situations. On one hand we have what we've already done, but it doesn't actually meet our project's scope as we've planned. We also have issues where this implementation has limitations on what can actually be improved. Then on the other hand, we have something that is not easy to do and introduces more issues, but can actually be the drastic improvement we're looking for.
In the enterprise environment, this situation is cause to replace engineers. We should have had the foresight and planning that eliminated this risk. Unfortunately, with so much time invested we then need to weigh our options: what is the potential of one versus the other? is the sky the limit for one option? is one option limited by power when performing logic?
Quite honestly, the frame rate issues are most likely a side-effect of the problem. The problem being a requirement on real-time processing of scripts that in turn causes input lag, frame lag, and just general performance issues. Aside from waiting for faster processors, there's only so much "optimization" you can do to a script.
I also really hate to sound negative because I really like this game and people that have the ambition to strike out on their own. However, it does not inspire confidence when there are oversights during initial planning that have negative effect like this in the long term. I mean, will this game run better when we all have 6Ghz processors? Or, will the game be expanded to press the limits of its capability as well?
Ultimately, I have to believe UWE wants "investors." Why else would they decide to create a highly mod-capable engine? Yet, these investors are likely to weigh options and it may become difficult to rationalize an investment here, given the options available in our current environment.
Do you expect me, as a consumer and player, to hold the value spark has to UWE higher than the value it has to me?
The performance of the game is only barely acceptable to me as I have an overclocked system. Most people do not and while some crazy people on these forums think 30 - 40 fps is acceptable, it really isn't. Is someone who plays TF2 at 120 fps going to be more or less inclined to play this game when they have to lose so many frames to have the honour to do so?
In additon, I think a ping cap should be implemented (and mandatory) where the user's ping is tracked for the first 10 seconds for connection stability. It's frustrating to stare at the player scoreboard and see half the players on a team having pings of 200+.
I have a hard enough time trying to join the 24man servers.
is this because nobody will be playing, or are we having high hopes here
edit: welp, forgot I posted in this thread, otherwise I would have edited this into the last post.