Developing NS2 is all fun and games
Faskalia
Wechsellichtzeichenanlage Join Date: 2004-09-12 Member: 31651Members, Constellation
Wechsellichtzeichenanlage Join Date: 2004-09-12 Member: 31651Members, Constellation
<div class="IPBDescription">or ist it?</div>This post is dedicated to the majority of forumees, complaining about the lack of performance and advancement regarding the current NS2 development.
Keep in mind that the UWE is pretty small compared to your average high profile developer and yet they still have to tackle the same problems, especially because they are creating their own engine from scratch.
Difficulties that they have to overcome:
Server-Client architecture:
Sounds pretty simple, doesn't it? The clients send data to the server who does some computing and sends data back. Well, it would be simple if NS2 was a round based game with long reaction times like chess. But what we have is a game where you can feel the difference between a 10 ms and a 20 ms delay. Lets look at it from the clients POV. The Client needs to draw at least 30 frames a seconds to create the impression of smooth gameplay. This also means that he needs 30 updates a seconds about the position of movable entities like other players. Especially fast moving entities need to be updated even more often to ensure smooth movement and eliminate stuttering.
So for one client to be able to play the game he needs 30 updates a second from other clients. This could be done with a peer to peer architecture but then cheating would go rampant, cause there is no neutral 3d party (the server) who can confirm wheter a certain action was legit or not. In a peer to peer shooter I could simply tell all clients *BAM I shot you*. I can do the same in a client-server game, but the server can remove me from the game if the send data doe not make send. In a peer to peer game you could do the same, but punishment for false data and verification of data would only be reliable if you quorum them creating a huge strain on every individual client.
Ok fine, we have a architecture and everyone is sending updates about their own position 30 times a second and the server is distributing those updates to every other client. Unfortunately the client wont be able to reliably send 30 updates every second. The reason for this is the basic nature of the Internet. Routes change. Individual packages get lost or packet number 10 arrives before packet 4 because of a mid-communication route change. Some clients might even not be able to deliver 30 updates a second because of computing or bandwidth limitations. The server could simply remove clients from the game that fail to deliver. But this would mean that only people who buy a static route to their favorite server could play on that server :P
So instead UWE has to introduce a mechanism that allows the server to compute missing information if a client fails to deliver. Lets say Flayras last 3 known positions are (1,1,1) (2,2,2) and (3,3,3). Too bad that update 4 and 5 do not arrive in time. No worry the server could extrapolate that missing updates based on the previous ones. So the server sends the positions (4,4,4) and (5,5,5) to all other clients. So good so well, but only if Flayra actually continued his previous movement. But what happens when Flayras update 4 and 5 finally arive at the server and look something like this (4,4,4) and (7,7,7) because he started a leap/sprint with update 4.The server will move Flayra from his falsely calculated position (5,5,5) to (7,7,7). Flayra will appear to have been teleported.
K, so we got basic client communication down. Now imagine that every players sends a different amount of updates per second and also wants to receive a different amount of updates per seconds. In addition player latencies range from 50ms to 150ms and 5% of all packages are either lost or arrive out of order. I guess a good comparison would be 12 people trying to throw 30 puzzle-pieces each at you and you have to put them back together. This whole cycle repeats every second.
What UWE needs to do is come up with strategies and put them into code (fast code) that allow the server the handle these messy situations. But that is not all. I just have finished telling you about "non abusive clients". Of course the fastest way for the server to handle all the data is to simply relay it. But this would man client A could send a "i killed the hive, i rock" to the server and the game would end. This is why the server is double checking whether the information makes sense. Questions like: Did the client have a line of view to the hive? come to mind also: At the time A killed B was B actually under As crosshair? Here one of the main problems with fast shooters emerge. A is never shooting at the current B, but at the last position of B known to A. Assuming a ping of 50ms for A and B it takes at least 100ms before the server is able to relay Bs current position to A. But when that info finally arrives at A B has already moved for another 100ms. Even worse when A killed B he killed a 100ms old "image" of B and it takes at least another 100ms before As kill is relayed to B. This allows B to continue moving for 200ms although he is dead from the games POV. This creates the classic "shot around a corner" situations and gets worse, the higher the latency, the faster the players and the more computing the server has to do.
Especially with fast shooters it might seem sensible to make a server only relay data and do the most basic computing in order to reduce the shot around corner syndrome to ((Latency(A)+Latency(B))x2) but this creates another problem with cheaters. Wall-hacks only work when the data you receive contains the position of other players. If the server computed that A cannot see B and thus stripped Bs position from the data it send to A wallhacks would become worthless but the server would be put under additional strain and the latency would rise. NS2 is a very fast game so the last thing we want are high latencies. But how does UWE stop wallhackers? It's up to them but you can distinguish two different methods: follow-up care and pre-emptive measures. Follow up care would be VAC. If cheats are found they are entered into a database and if someone is running these cheats the are banned. pre-emptive measures always put addition stress on the server and will increase latency but maybe they find a clever method that is worth it. An example would be to include the longest visible distance with every map and when that map ist played the server calculates the distance between to players and if it longer than the longest visible distance the server does not relay the players position to each other. You can simplify by only taking 2 dimension into account (NS2 maps are basically flat). This means that the most secrey environment is one where the server calculates everything and simply streams video to the clients.
Interactive Environment:
Interactive Environment for NS2 are mainly Dynamic Infestation and the Power-Grid. The Power Grid aint that problematic. Because there is a very limited amount of possible states and that a certain light source can be in. Lets say an alien bites a power node down to 30% and the lights start to flicker. All that is needed to keep the flickering in sync among all other clients is the server to tell the clients when the flickering started. With this information the flickering can be initiated by the server and maintained by the client. However a client could override the flicker order, bringing us back to client-server communication. Dynamic infestation is however not that simple. A basic design decision is going to be whether DI affects collision. If it does DI must be kept in sync among clients all the time. The most straight forward solution would be for the server update the new level geometry; this would however require additional computing from the server and higher bandwith from everyone. There are ways to make sure that the clients do must of the computing and the bandwidth demand does not rise that much. Currently DI is placed in rather large and round patches. All that is needed is an algorithm that behaves like a function. (For every valid input there is only 1 possible output). To create chaotic DI the server randomly determines the whole or part of the input and than transmits to input for DI creation to the clients, which will then make all the same changes to the level. The server created input would most likely contain a timestamp, values based and the proximity and direction of already existing DI and of course a random value.
Fine, we managed to create collision influencing DI and ensured synchronisity among the clients. But what about DI removal? The flamethrower does not care how and where you created your patches, or does it? Having the DI react spontaneously to flames will be hard, especially if you want a fast reaction in terms to collision detection. Remember collsion has the be kept synchronised amoing clients all the time. So when you burn DI the collision can only be changed once the server has approved. How do we get a direct reaction from DI while having enough time to let the server decide for a new collsion mesh? One way would be to have everyone remember where the center of all placed DI patches is. Because of their constant radius we can do the following: If the flamethrower hits a part of a patch the patch starts burning. The server would simply transmit patch ID, timestamp and a value that represents the intensity of the fire. The clients simply render random flames based on intensity. When the intensity changes (because gorges used healspray) the server sends the new values and the clients reduce the amount of flames. When the intensity for a patch reaches a certain threshold the patch will be removed and the server send new DI info for all patches that have been in direct contact with the destroyed one.
Please remember these are all potential ways to do it and their main purpose is to show the obstacles that UWE has to overcome. Of course there are other solutions and more elegant ones (MAX will find those, do not worry).
The DI parts brings me to my next point:
Precision or resolution. The gorge places DI patches with a diameter of roughly 2 meters. However in order to make to DI patches interact more nicely with flames they could be divided into 8 16 32 or even 4096 little segments. Same goes for hitboxes. Just open a few models in the model viewer. You will notice that the main goal of hitboxes is to put the optical model inside the hitbox. This ensures that a hit on the optical model is always a hit. (However a miss could be still a hit ;)) So UWE could create more complex hitboxes until the hitbox is identical with the model itself. This can at has been done for single player games but you do not want to stress your server with this kind of BS. Halving server performance for a 5% increase in precision is usually not worth it.
Melee Combat:
Precision is a good starter for one of the greatest obstacles in FPS melee combat. When you are 100 meters away from your enemy he is only a few pixels high on your screen and you can only move your crosshair pixel-wise. You cannot move it between pixels. This means that you wont notice that hitbox and model are not 100% the same. You also wont notice that model and hitbox are not in sync because of latency and interpolation issues. However with NS2 ranged combat going from 5 to 20 meters and aliens trying to close in you notice that these matter much more when you are close to your target. Continuing with the 200ms difference in player perspective it is entirely possible to kill a skulk although you missed by a 90 degree angle.
Ragdolls:
NS2 offers great opportunities for gameplay affecting ragdolls. A dead body on DI could be converted to resources for example. Or a dead ONOS could act as a physical barrier until it has been dissolved by either DI or the nano grid. However because these ragdolls would severly affect gameplay they have to be synchronized among clients. The server could calculate ragdolls and then update the clients. This however puts additional strain on it. Another possibilty would be to make it only semi-server controlled. A dead skulk is not big enough to be an obstacle and can simply be walked over. That is why the deak-skluk ragdoll can be calculated by every individual client. The server simply has to decide wether the body has landed on DI or on the nano-grid and which team to award resources. The only problem here is that different players would get different info. You could see the skulk getting dissolved by the nano-grid but your resources counter would not rise, because the server decided that the skulk-body in reality landed on DI and not on the nano-grid. This would also be problematic in terms of replays.
Keep in mind that the UWE is pretty small compared to your average high profile developer and yet they still have to tackle the same problems, especially because they are creating their own engine from scratch.
Difficulties that they have to overcome:
Server-Client architecture:
Sounds pretty simple, doesn't it? The clients send data to the server who does some computing and sends data back. Well, it would be simple if NS2 was a round based game with long reaction times like chess. But what we have is a game where you can feel the difference between a 10 ms and a 20 ms delay. Lets look at it from the clients POV. The Client needs to draw at least 30 frames a seconds to create the impression of smooth gameplay. This also means that he needs 30 updates a seconds about the position of movable entities like other players. Especially fast moving entities need to be updated even more often to ensure smooth movement and eliminate stuttering.
So for one client to be able to play the game he needs 30 updates a second from other clients. This could be done with a peer to peer architecture but then cheating would go rampant, cause there is no neutral 3d party (the server) who can confirm wheter a certain action was legit or not. In a peer to peer shooter I could simply tell all clients *BAM I shot you*. I can do the same in a client-server game, but the server can remove me from the game if the send data doe not make send. In a peer to peer game you could do the same, but punishment for false data and verification of data would only be reliable if you quorum them creating a huge strain on every individual client.
Ok fine, we have a architecture and everyone is sending updates about their own position 30 times a second and the server is distributing those updates to every other client. Unfortunately the client wont be able to reliably send 30 updates every second. The reason for this is the basic nature of the Internet. Routes change. Individual packages get lost or packet number 10 arrives before packet 4 because of a mid-communication route change. Some clients might even not be able to deliver 30 updates a second because of computing or bandwidth limitations. The server could simply remove clients from the game that fail to deliver. But this would mean that only people who buy a static route to their favorite server could play on that server :P
So instead UWE has to introduce a mechanism that allows the server to compute missing information if a client fails to deliver. Lets say Flayras last 3 known positions are (1,1,1) (2,2,2) and (3,3,3). Too bad that update 4 and 5 do not arrive in time. No worry the server could extrapolate that missing updates based on the previous ones. So the server sends the positions (4,4,4) and (5,5,5) to all other clients. So good so well, but only if Flayra actually continued his previous movement. But what happens when Flayras update 4 and 5 finally arive at the server and look something like this (4,4,4) and (7,7,7) because he started a leap/sprint with update 4.The server will move Flayra from his falsely calculated position (5,5,5) to (7,7,7). Flayra will appear to have been teleported.
K, so we got basic client communication down. Now imagine that every players sends a different amount of updates per second and also wants to receive a different amount of updates per seconds. In addition player latencies range from 50ms to 150ms and 5% of all packages are either lost or arrive out of order. I guess a good comparison would be 12 people trying to throw 30 puzzle-pieces each at you and you have to put them back together. This whole cycle repeats every second.
What UWE needs to do is come up with strategies and put them into code (fast code) that allow the server the handle these messy situations. But that is not all. I just have finished telling you about "non abusive clients". Of course the fastest way for the server to handle all the data is to simply relay it. But this would man client A could send a "i killed the hive, i rock" to the server and the game would end. This is why the server is double checking whether the information makes sense. Questions like: Did the client have a line of view to the hive? come to mind also: At the time A killed B was B actually under As crosshair? Here one of the main problems with fast shooters emerge. A is never shooting at the current B, but at the last position of B known to A. Assuming a ping of 50ms for A and B it takes at least 100ms before the server is able to relay Bs current position to A. But when that info finally arrives at A B has already moved for another 100ms. Even worse when A killed B he killed a 100ms old "image" of B and it takes at least another 100ms before As kill is relayed to B. This allows B to continue moving for 200ms although he is dead from the games POV. This creates the classic "shot around a corner" situations and gets worse, the higher the latency, the faster the players and the more computing the server has to do.
Especially with fast shooters it might seem sensible to make a server only relay data and do the most basic computing in order to reduce the shot around corner syndrome to ((Latency(A)+Latency(B))x2) but this creates another problem with cheaters. Wall-hacks only work when the data you receive contains the position of other players. If the server computed that A cannot see B and thus stripped Bs position from the data it send to A wallhacks would become worthless but the server would be put under additional strain and the latency would rise. NS2 is a very fast game so the last thing we want are high latencies. But how does UWE stop wallhackers? It's up to them but you can distinguish two different methods: follow-up care and pre-emptive measures. Follow up care would be VAC. If cheats are found they are entered into a database and if someone is running these cheats the are banned. pre-emptive measures always put addition stress on the server and will increase latency but maybe they find a clever method that is worth it. An example would be to include the longest visible distance with every map and when that map ist played the server calculates the distance between to players and if it longer than the longest visible distance the server does not relay the players position to each other. You can simplify by only taking 2 dimension into account (NS2 maps are basically flat). This means that the most secrey environment is one where the server calculates everything and simply streams video to the clients.
Interactive Environment:
Interactive Environment for NS2 are mainly Dynamic Infestation and the Power-Grid. The Power Grid aint that problematic. Because there is a very limited amount of possible states and that a certain light source can be in. Lets say an alien bites a power node down to 30% and the lights start to flicker. All that is needed to keep the flickering in sync among all other clients is the server to tell the clients when the flickering started. With this information the flickering can be initiated by the server and maintained by the client. However a client could override the flicker order, bringing us back to client-server communication. Dynamic infestation is however not that simple. A basic design decision is going to be whether DI affects collision. If it does DI must be kept in sync among clients all the time. The most straight forward solution would be for the server update the new level geometry; this would however require additional computing from the server and higher bandwith from everyone. There are ways to make sure that the clients do must of the computing and the bandwidth demand does not rise that much. Currently DI is placed in rather large and round patches. All that is needed is an algorithm that behaves like a function. (For every valid input there is only 1 possible output). To create chaotic DI the server randomly determines the whole or part of the input and than transmits to input for DI creation to the clients, which will then make all the same changes to the level. The server created input would most likely contain a timestamp, values based and the proximity and direction of already existing DI and of course a random value.
Fine, we managed to create collision influencing DI and ensured synchronisity among the clients. But what about DI removal? The flamethrower does not care how and where you created your patches, or does it? Having the DI react spontaneously to flames will be hard, especially if you want a fast reaction in terms to collision detection. Remember collsion has the be kept synchronised amoing clients all the time. So when you burn DI the collision can only be changed once the server has approved. How do we get a direct reaction from DI while having enough time to let the server decide for a new collsion mesh? One way would be to have everyone remember where the center of all placed DI patches is. Because of their constant radius we can do the following: If the flamethrower hits a part of a patch the patch starts burning. The server would simply transmit patch ID, timestamp and a value that represents the intensity of the fire. The clients simply render random flames based on intensity. When the intensity changes (because gorges used healspray) the server sends the new values and the clients reduce the amount of flames. When the intensity for a patch reaches a certain threshold the patch will be removed and the server send new DI info for all patches that have been in direct contact with the destroyed one.
Please remember these are all potential ways to do it and their main purpose is to show the obstacles that UWE has to overcome. Of course there are other solutions and more elegant ones (MAX will find those, do not worry).
The DI parts brings me to my next point:
Precision or resolution. The gorge places DI patches with a diameter of roughly 2 meters. However in order to make to DI patches interact more nicely with flames they could be divided into 8 16 32 or even 4096 little segments. Same goes for hitboxes. Just open a few models in the model viewer. You will notice that the main goal of hitboxes is to put the optical model inside the hitbox. This ensures that a hit on the optical model is always a hit. (However a miss could be still a hit ;)) So UWE could create more complex hitboxes until the hitbox is identical with the model itself. This can at has been done for single player games but you do not want to stress your server with this kind of BS. Halving server performance for a 5% increase in precision is usually not worth it.
Melee Combat:
Precision is a good starter for one of the greatest obstacles in FPS melee combat. When you are 100 meters away from your enemy he is only a few pixels high on your screen and you can only move your crosshair pixel-wise. You cannot move it between pixels. This means that you wont notice that hitbox and model are not 100% the same. You also wont notice that model and hitbox are not in sync because of latency and interpolation issues. However with NS2 ranged combat going from 5 to 20 meters and aliens trying to close in you notice that these matter much more when you are close to your target. Continuing with the 200ms difference in player perspective it is entirely possible to kill a skulk although you missed by a 90 degree angle.
Ragdolls:
NS2 offers great opportunities for gameplay affecting ragdolls. A dead body on DI could be converted to resources for example. Or a dead ONOS could act as a physical barrier until it has been dissolved by either DI or the nano grid. However because these ragdolls would severly affect gameplay they have to be synchronized among clients. The server could calculate ragdolls and then update the clients. This however puts additional strain on it. Another possibilty would be to make it only semi-server controlled. A dead skulk is not big enough to be an obstacle and can simply be walked over. That is why the deak-skluk ragdoll can be calculated by every individual client. The server simply has to decide wether the body has landed on DI or on the nano-grid and which team to award resources. The only problem here is that different players would get different info. You could see the skulk getting dissolved by the nano-grid but your resources counter would not rise, because the server decided that the skulk-body in reality landed on DI and not on the nano-grid. This would also be problematic in terms of replays.
Comments
o
much time on your hands....
It was an interesting post.
It needed a tl;dr version, because, well... tl;dr.
The obscure expectations, standards and definitions of the programming industry have been a gift and curse for UWE. People have different expectations that also cause complaints, but those expectations also have helped UWE to sell a plenty of games they wouldn't have sold otherwise. If there was a direct definition for beta, I doubt UWE could've transitioned into it and got the financing they needed. It all plays both ways and you can't expect to cherry pick just the good stuff.
In short: They've chosen the way they work. They must have also aknowledged that they may upset people with their choises. Even if it's not nice, I expect them to cope with it. Also, it's good to remember that everyone complaining about the performance has preordered and financially supported UWE. That's far better than just not preordering at all or getting a refund in all quietness.
In general, I respect them for being ambitious and having courage to put themselves on the line instead of working in a bigger mainstream project, but I also expect them to provide value in return for all the support they've got so far and are still getting.
However, this snippet gave me an idea:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The server simply has to decide wether the body has landed on DI or on the nano-grid and which team to award resources.<!--QuoteEnd--></div><!--QuoteEEnd-->
If the Marines are going to have the ability to pick up (reuse/recycle) weapons, there could be an asymmetrical feature for the aliens that die to regain part of the cost of the life-form, if he died while defending on Dynamic Infestation.
complaint about framerate
demand for an NS1 feature return
complaint about NS2 feature implementation
complaint about imbalance
comparison to TF2 or SC2
righteous condemnation of complainers
edit: looks like i'm the ######
It wasn't complainy or self righteous...it was educational.
I knew all this stuff because I am a programmer but not everyone here is.
and Bacillus's response framed it well...I still expect them to deliver.
Interesting stuff. I've got to say I'm not a big fan of Onos corpses blocking the way. It is a pain when alive it doesn't need to be a pain when dead as well. Or maybe you could cut them in piece with the ax to free the way.
It wasn't complainy or self righteous...it was educational.
I knew all this stuff because I am a programmer but not everyone here is.
and Bacillus's response framed it well...I still expect them to deliver.<!--QuoteEnd--></div><!--QuoteEEnd-->
fine.... reading...
edit: actual response: most people complain about the server tick rate not getting enough priority. i'm well aware of the reasons and that uwe is small and they have people working on gameplay and people working on technical and that the artists still need to work in the meantime and that occasionally max has to stop working on optimization to figure out things like sound bugs.
i'm just saying, people complain about the server tick because that is what holds them back the most from enjoying this game (as you pointed out many times, client/server code is what makes or breaks a first person shooter and either gives a satisfying feeling of being able to hit moving targets or a terribly frustrating feeling of rubberbanding around and seeing yourself hit something on your screen only to have it completely not register).
accept that people will voice the frustration, expect that when the voices die down, you've replaced frustration with satisfaction.
But remember, it is impossible to please everybody. Somebody will always ###### and moan, regardless of what UWE does, and despite your valiant effort here, Faskalia, I have a feeling the only people that will open their eyes long enough to read your message are the ones that already understand it. The best strategy with these people is to understand them, accept them, and promptly ignore them.
Precision is a good starter for one of the greatest obstacles in FPS melee combat. When you are 100 meters away from your enemy he is only a few pixels high on your screen and you can only move your crosshair pixel-wise. You cannot move it between pixels. This means that you wont notice that hitbox and model are not 100% the same. You also wont notice that model and hitbox are not in sync because of latency and interpolation issues. However with NS2 ranged combat going from 5 to 20 meters and aliens trying to close in you notice that these matter much more when you are close to your target. Continuing with the 200ms difference in player perspective it is entirely possible to kill a skulk although you missed by a 90 degree angle.<!--QuoteEnd--></div><!--QuoteEEnd-->
Good post! I've noticed this happening a lot while fighting skulks when the server starts to lag badly. Rather than try to shoot at the skulk playermodel you need to guesstimate where you think the server will place the skulk from extrapolating its position. I frequently find myself killing skulks by shooting in front of, rather than at, the playermodel.
Some players can actually play a game.
If it was a total mess, most would of just given up so in a way the whines and moans are a indication of intrest and desire to play NS 2.
... it could be worse and end up like Fatsharks Lead and Gold game, poor netcode there shrunk the community till its virtually none existant at this stage. I have 2 hours of playtime in that game, 0 in multiplayer as it didnt work.
I'd say UWE are the 'tryers'. They want to do something new and can't settle for "Pretty good". They over-complicate what they have to try and make it spectacular, thus causing things such as delays etc. and not getting the basics right.
Although hey, by 2012 if NS2 is released that might turn to the "doers" or something else, but right now, they're trying.
When an onos dies in stead of a really lame probably not to good looking ragdoll model. What if it exploded in gore and spread dynamic infestastino in the explosion. The gore explosion could put a cool and gross post effect on the screen of marines. Hot damn. It would perhaps take care of some of the ragdoll and colision issues with the onos.
I'd say UWE are the 'tryers'. They want to do something new and can't settle for "Pretty good". They over-complicate what they have to try and make it spectacular, thus causing things such as delays etc. and not getting the basics right.
Although hey, by 2012 if NS2 is released that might turn to the "doers" or something else, but right now, they're trying.<!--QuoteEnd--></div><!--QuoteEEnd-->
Do you ever say anything nice?
I'd say UWE are the 'tryers'. They want to do something new and can't settle for "Pretty good". They over-complicate what they have to try and make it spectacular, thus causing things such as delays etc. and not getting the basics right.
Although hey, by 2012 if NS2 is released that might turn to the "doers" or something else, but right now, they're trying.<!--QuoteEnd--></div><!--QuoteEEnd-->
Was NS1 any different? That was by far the most ambitious mod on HL1, and they actually did pull it off, remember?
When an onos dies in stead of a really lame probably not to good looking ragdoll model. What if it exploded in gore and spread dynamic infestastino in the explosion. The gore explosion could put a cool and gross post effect on the screen of marines. Hot damn. It would perhaps take care of some of the ragdoll and colision issues with the onos.<!--QuoteEnd--></div><!--QuoteEEnd-->
I know its off topic, but I like this hard idea lost among sentiments of doers and triers.
...but it made me laugh
I'd say UWE are the 'tryers'. They want to do something new and can't settle for "Pretty good". They over-complicate what they have to try and make it spectacular, thus causing things such as delays etc. and not getting the basics right.
Although hey, by 2012 if NS2 is released that might turn to the "doers" or something else, but right now, they're trying.<!--QuoteEnd--></div><!--QuoteEEnd-->
Actually, UWE reminds me a bit about the article on Valve developed HL1 circa 1997 (http://www.gamasutra.com/view/feature/3408/the_cabal_valves_design_process_.php). Its a good read about game development. Also contrast the picture of Valve portrayed in the article with the success story that Valve is today. In fact, I'd say that UWE is in a better position that Valve was in 1997 because 1) UWE has already developed a game (NS1) and 2) because of that they have a dedicated community that is helping finance, test, and even debug their flagship game/engine.
I know. They (UWE) went a bit more complicated for the time and pulled it off pretty well, they reigned in some over ambitious ideas. I think that's mainly what I'm going for here, reign in some over-ambition.
@Breadman
I think maybe that come across the wrong way to you, so let me clear things up. There's nothing wrong in trying but you know yourself, there's been a lot of delay and lack of transparency around pricing and release of game on schedule and as foretold. UWE are underachieving on this front there's no two ways about it.
What you guys do well however is trying new ideas, gameplay wise, production wise. By 'tryers' I don't mean you're the guy who can't quite get the girl, but doing something new trying to push yourselves above that "pretty good" boundary which you already think you have.
I'm all for trying new things, some of the effects like the alien flashlight, great new idea, two commanders on an RTS/FPS platform, great idea, again something new.
The only down side I see with all the trying new right now is the trying what works and getting a basic game going isn't there. I couldn't really care less about balance updates going on right now, because it's not like there's going to be any games going which could be called balance because of the playable state of the game.
Everyone has a personal opinion, mine just happens to come from a different angle to yours.
@Insane
Never said any criticism was expert. Although criticism is widely played down on here and I once remember Cory posting a post telling people not to criticise on the forums some time before Christmas.
I think it's something you guys need to deal better with, learn to take criticism, especially on an open front it's always going to be there.
Honestly there is little much we can do except be patient. And by patient I don't just mean 'wait for the patch that fixes the main issues' because we all know that's never gonna be the case, but rather, the patience to sit through some patches with only minor performance gains, eventually resulting in a game with such performance that it is unrecognisable from before, or at least that's the hope. Or alternatively, yes, you could just take a break from following NS2 until release and I imagine the performance gain would be immense.
Having said that, the apparent lack of a vision or a plan as far as the gameplay goes, does bother me. Unlike Chris, I am not optimistic about totally 'free design', without an initial plan, or a vision of how the game will play, or end up. The 4 pillars are a good first step, but I sure as hell hope you're building this house on a more solid foundation than that.
Don't just make up stuff and attach my name to it. If you are going to make a claim about something I said, at least look up the actual post and quote it. I may have made appeals at various stages for people to be a little more constructive in their criticism if they want us to actually pay attention, but I've never told people not to criticize, as evident by the massive amount of threads and posts that are nothing but critical. Though, apparently you got several of us at UW to pay attention to your nonconstructive post, anyway, so good job there.
Sorry, but all I see around me at UW are DOERS, making amazing things happen every day, and making an ambitious game a reality.
--Cory
What I am trying to say is that a performance boost can happen very suddenly. Games are a prime example of this; you have functions that are being called several dozen times a second. Optimize One or two of those and blamo.
Also: *virtual pat on back for Cory* I like your art. Now give the phase-gate a square energy-field/portal. :P kthxbye