Or we get a game that takes so long to develop that in order to stay cutting edge and relevant they have to reboot development of the game multiple times over, dropping it into dev hell until someone finally gives up and pushes it out the door to sit next to Duke Nukem Forever.
the whole "cutting edge" debacle is simply graphics upgrades, the game itself there is no "cutting edge" gameplay that needs reworks over time, just design ideas really.
That does not hit the game content/mechanics, the slowdown is more on that own department but that progression is not a bad thing having the graphics team constantly pumping improvements, this happens even on released games so they won't be going anywhere.
The whole "Duke Nukem" moment on SC already passed, it peaked on 2015/16 when the scope grown and they had a large engineering debt as the engine needed heavy refactors to allow for wanted features. Now the graphics is an easier front because they are their own teams that can work independently of the tech/features.
I have sunk my cost by having played the game as it progressed and progresses for many hours now doing all sorts of things.
I have had fun with many unfinished games as SC is one (what has been quite the trend in the industry for quite the years already), and I think everyone buys games for entertainment so if the unfinished game is capable to provide me with that, then for me there is no "sunken cost", I haven't lost any money.
I think I have felt I lost money more times when I bought finished games than unfinished ones O_o
I'm still trying to figure out if the whole taking a crap in space was an actual mechanic.
Was not really, it's just as part of what SC is stuff is interactable and has to make sense, hence a toilet to be interacted with will have animation/etc, if I am correct there is some simple stuff that requires you to say take a shower or you'll look dirty over time, eat, etc... It's superficial stuff.
I just waiting to see what happens. I have spent more on a lottery ticket with (presumably) less odds of any return. The possible outcome for this game matches the money I put in fairly well if they at least make a decent Squadron 42.
@MaxBacon I just can't get into the game yet for some reason (mentally - not technically) It checks all the boxes but I just don't find it "fun". I haven't done much yet though. I tried a bit ago but there was some issue that was messing something up. I will try again. Still haven't gotten far out of the hanger.
Or we get a game that takes so long to develop that in order to stay cutting edge and relevant they have to reboot development of the game multiple times over, dropping it into dev hell until someone finally gives up and pushes it out the door to sit next to Duke Nukem Forever.
the whole "cutting edge" debacle is simply graphics upgrades, the game itself there is no "cutting edge" gameplay that needs reworks over time, just design ideas really.
That does not hit the game content/mechanics, the slowdown is more on that own department but that progression is not a bad thing having the graphics team constantly pumping improvements, this happens even on released games so they won't be going anywhere.
The whole "Duke Nukem" moment on SC already passed, it peaked on 2015/16 when the scope grown and they had a large engineering debt as the engine needed heavy refactors to allow for wanted features. Now the graphics is an easier front because they are their own teams that can work independently of the tech/features.
You realize Duke Nukem went through that phase multiple times, yeah? Graphics are not entirely divorced from gameplay, less so now than it used to with more kinematic and physics driven elements. An engine will always be beholden to it's time, and trying to heavily modify it post-launch poses many additional hurdles in how it can affect a game.
SC is not past anything until they manage a complete and readily consumed product. Until then it has every same chance to be a success as it has to be a massive flop.
You realize Duke Nukem went through that phase multiple times, yeah? Graphics are not entirely divorced from gameplay, less so now than it used to with more kinematic and physics driven elements. An engine will always be beholden to it's time, and trying to heavily modify it post-launch poses many additional hurdles in how it can affect a game.
SC is not past anything until they manage a complete and readily consumed product. Until then it has every same chance to be a success as it has to be a massive flop.
They are vastly divorced from gameplay, there are things say when a game has a lot of content that is assets created and graphics changes need the update of all created assets to bring light to changes, that's when it sinks time, but that is still the artists work not the gameplay programmers/engineers.
When they added new lightning, the new fog system, new particles system, updated models, etc... that is all artist work after tech updates it's not who is creating the actual game features that need to go there do it, it would be a waste of their expertise. Hence why big studios are known for having literal armies of artists so they cope with it.
There are engineering tasks, such as the upgrade to DX12/Vulkan that are going to cost engineering time and seems to be the biggest in the graphics area.
The engineering debt phase, aka Duke Nukem is not SC's boogeyman today, there are still engineering hurdles but the game is already far from the engineering problems that completely stalled the game years ago, such as, until OCS they couldn't add a planets/expand the game-world because of daunting memory issues. SC has been visibly knocking down its challenges that are the fundamental pieces that make the game, the shiny visuals are an addon comparing to that work.
SC is quite more unique when it comes to funding and development resources, that is what has been core to did and continue to surpass its dev challenges that could have otherwise potentially sunk the project.
That's feeling rather misinformed. You are talking only about graphics as assets dropped into the game. That is far from reality, as things like lighting, particles, fog, and object complexity all weighs against the engine's performance and balance against its other elements.
This is furthered when certain graphical elements, like character and vehicle animation, is tied to physics-bound actions. Them showing off water caustics? That liquid in that cup is processing power. And it doesn't come from nowhere nor does it not have to be budgeted against everything else.
Nothing in development is separated from the rest of the things going into a game and it's engine.
Which bears reiteration, "engineering debt" is going to exist as long as they keep adding things to the game/engine. As they are going to be constantly updating, tweaking, and tuning it, if not having to deal with even broader revamps as new features need to get merged with old ones.
And that's avoiding the point of the Duke Nukem comparison, that of the game developing on one standard, only to have to stop and redo things because there's a new benchmark out before they could release. Perpetually chasing a cutting-edge they can't obtain.
That's feeling rather misinformed. You are talking only about graphics as assets dropped into the game. That is far from reality, as things like lighting, particles, fog, and object complexity all weighs against the engine's performance and balance against its other elements.
This is furthered when certain graphical elements, like character and vehicle animation, is tied to physics-bound actions. Them showing off water caustics? That liquid in that cup is processing power. And it doesn't come from nowhere nor does it not have to be budgeted against everything else.
Nothing in development is separated from the rest of the things going into a game and it's engine.
Which bears reiteration, "engineering debt" is going to exist as long as they keep adding things to the game/engine. As they are going to be constantly updating, tweaking, and tuning it, if not having to deal with even broader revamps as new features need to get merged with old ones.
And that's avoiding the point of the Duke Nukem comparison, that of the game developing on one standard, only to have to stop and redo things because there's a new benchmark out before they could release. Perpetually chasing a cutting-edge they can't obtain.
The implementation of these new things as the new lightning, particle effects and so forth comes from programmers, from the updates they have that team on the UK graphics programmers.
When they added the new fog what happens then is not of the support of programmers is the artists, they went update/review all locations that needed or used the legacy system to the new one, on this aspect that is not a quick one but it's also not sinking the important departments time when SC's development is put in question.
And yes many of these updates are aside of the visual improvement is the fact they are able to do more with less of a performance impact, at this stage the last major (and upcoming ones as Vulkan) graphics steps have been an optimization and efficiency effort while increasing the visual quality.
SC has money and resources so they afford to have these teams dedicated to graphics unlike the majority of the indie/early-access/crowdfunded projects around, the development doesn't have to face stalls on the usual gameplay fronts because there is a new graphics tech coming online.
So visuals will remain shiny, if you'd want to see something that would cause development features to stop because of there are aspects being imposing problems we might look at the AI or the network that are areas not yet capable to cope with the scope of the game.
The "cutting edge" outside graphics I don't see that much relevant stuff, games have been using the same standards for a long time as far how the technology and how certain features are created, and we can see that by looking at the available game engines where many times the same old methods and tools just get new versions, and that is meant exactly so the devs don't have to redo everything just to do implementations.
You do understand your entire counterpoint boils down to them making the game cost even more money to develop by broadening the team to try and solve individual problems all at once, and that it is still not absolving the core element that the point at which they make the game, it will always be beholden to the technology they develop at that given time.
This is why I asked before whether you understood how many times the Duke Nukem title was rebooted due to them choosing to update the engine and tech. It wasn't once, it was multiple as they cyclically went through trying to match to new ideas and the evolution of hardware and the marketplace.
Having the money and resources to have a team dedicated to graphics and engine optimization does not magically make that issue go away, it just means you are spending thousands to millions extra more on a problem that's going to persist as long as that game persists.
Bold last paragraph from you as well given how much they have tried to up sell the use of new or novel technology/implementations. Admission the game is not using new methods or technology standards kind of drags you right back into the prior talked about issues though. Every doodad you place, every assets a client sees in the environment, is something that the network has to support placement and implied collision or any other associated elements that object/container has attached to it. Every node that spawns fog, every light/ray source, and especially every dynamic object. If network is not yet capable of handling the scope of the game, you are going to see the visual side of the game being tweaked about a ton as they try to continue developing that in order to get all things balanced and cooperating stably enough for it to run fine.
And you want to say something like "bogus dude, graphics are just visual and have nothing to do with the network or online play" and then I would just inform you that if they develop graphics as purely client side assets, then SC will be hacked to hell the first week it's out and the game will be thoroughly screwed. Positioning of elements, collision, physics modeling, etc all needs some measure of compliance through server synchronization otherwise people can effectively tell the game anything they want. That puts a toll across the entire game and engine as it has to communicate all that information alongside standard player actions and rest of the stuff taking place.
So not only are the visuals of the game far from done, they are likely awaiting some major revisions as other features of the game/engine have to still be implemented and merged together, and the resulting impact on performance or introduction of new bugs/problems takes place. This actually becomes more of a problem with more disparate teams working on separate lines of code that have to get later merged together, because not everyone codes in the same way.
So not only are the visuals of the game far from done, they are likely awaiting some major revisions as other features of the game/engine have to still be implemented and merged together, and the resulting impact on performance or introduction of new bugs/problems takes place. This actually becomes more of a problem with more disparate teams working on separate lines of code that have to get later merged together, because not everyone codes in the same way.
And this is why a lot of people say that they should have had the engine and networking done in order the build the game on top of that.
The way they did it, all the assets will be in perpetual rework* as they build the core. Wasting time and money.
*By law, as long as they can prove that the game is in development, they can deny refunds. So keep that in mind anytime they need to "rework" something.
The big question is, after they get the core/network finished, will the game still be able to do all the things they sold to us? They made a lot of promises that depend on core/networking that hasn't been finished built yet.
I have a problem with them continuing to sell specialized ships that have an unique game mechanic for them to work. Game mechanics that have no documentation, no tech demo, and worse of all, won't know if they can even be done until they know the capabilities of their unfinished engine. Yet, they sell these unique game mechanics as ships, anyways.
This was when I realized this game was a Sunk Cost Fallacy. It's gotten worse since then, so I'm glad I didn't put any more money into it.
Cool story derek. this is your fourth time through the mmorpg community....
Better check under your bed and make sure he isn’t hiding under there as well or your closet
So not only are the visuals of the game far from done, they are likely awaiting some major revisions as other features of the game/engine have to still be implemented and merged together, and the resulting impact on performance or introduction of new bugs/problems takes place. This actually becomes more of a problem with more disparate teams working on separate lines of code that have to get later merged together, because not everyone codes in the same way.
And this is why a lot of people say that they should have had the engine and networking done in order the build the game on top of that.
The way they did it, all the assets will be in perpetual rework* as they build the core. Wasting time and money.
*By law, as long as they can prove that the game is in development, they can deny refunds. So keep that in mind anytime they need to "rework" something.
The big question is, after they get the core/network finished, will the game still be able to do all the things they sold to us? They made a lot of promises that depend on core/networking that hasn't been finished built yet.
I have a problem with them continuing to sell specialized ships that have an unique game mechanic for them to work. Game mechanics that have no documentation, no tech demo, and worse of all, won't know if they can even be done until they know the capabilities of their unfinished engine. Yet, they sell these unique game mechanics as ships, anyways.
This was when I realized this game was a Sunk Cost Fallacy. It's gotten worse since then, so I'm glad I didn't put any more money into it.
Cool story derek. this is your fourth time through the mmorpg community....
Better check under your bed and make sure he isn’t hiding under there as well or your closet
Just trying to live long enough to play a new, released MMORPG, playing New Worlds atm
Fools find no pleasure in understanding but delight in airing their own opinions. Pvbs 18:2, NIV
Don't just play games, inhabit virtual worlds™
"This is the most intelligent, well qualified and articulate response to a post I have ever seen on these forums. It's a shame most people here won't have the attention span to read past the second line." - Anon
You do understand your entire counterpoint boils down to them making the game cost even more money to develop by broadening the team to try and solve individual problems all at once, and that it is still not absolving the core element that the point at which they make the game, it will always be beholden to the technology they develop at that given time.
This is why I asked before whether you understood how many times the Duke Nukem title was rebooted due to them choosing to update the engine and tech. It wasn't once, it was multiple as they cyclically went through trying to match to new ideas and the evolution of hardware and the marketplace.
Having the money and resources to have a team dedicated to graphics and engine optimization does not magically make that issue go away, it just means you are spending thousands to millions extra more on a problem that's going to persist as long as that game persists.
Bold last paragraph from you as well given how much they have tried to up sell the use of new or novel technology/implementations. Admission the game is not using new methods or technology standards kind of drags you right back into the prior talked about issues though. Every doodad you place, every assets a client sees in the environment, is something that the network has to support placement and implied collision or any other associated elements that object/container has attached to it. Every node that spawns fog, every light/ray source, and especially every dynamic object. If network is not yet capable of handling the scope of the game, you are going to see the visual side of the game being tweaked about a ton as they try to continue developing that in order to get all things balanced and cooperating stably enough for it to run fine.
So not only are the visuals of the game far from done, they are likely awaiting some major revisions as other features of the game/engine have to still be implemented and merged together, and the resulting impact on performance or introduction of new bugs/problems takes place. This actually becomes more of a problem with more disparate teams working on separate lines of code that have to get later merged together, because not everyone codes in the same way.
I do have a general understanding from working on QA, software not games specifically, but the lines of what tends to cause refactoring aside of systems/tech that is too unstable and drive a lot of bugs, things that are not optimized enough and need to be worked to stay within the performance budget, and yes, improving the visual quality of the game.
My last paragraph is simply how things tend to be, beyond the graphics what drives the visual quality/detail of a game there is not much going on, games are still generally built on tools and standards that are decades old, just improved over time not redone to entire new technology. Reworks, revisions, etc... are part of the development of any game of complex scope, long undertakings with usually hundreds iterating on it, that doesn't mean anything aside that they go through the same process in a quite harder reality as the ambition of the devs has forced big pushes on technology to achieve viability.
They have dedicated teams to graphics it's no new thing, and they have the money to sustain it, the new graphics tech, improvements and such have been coming along together with the game feature-set, and they do not break the actual game mechanics aside of the bugs that require artists to review a lot of things to maintain the expected result. SC is also an MMO so this work will continue AFTER the game releases, and we see this same progress on released titles with devs that are more passionate about their work, such as Warframe.
When you talk about this things you must talk about undertakings that hit the engine and features that are more core that much stuff depends on, changing those is when everything goes to hell because everything has to be updated, this happened on SC in multiple visible occasions but the graphics updates with new systems/tech have not been any core cause.
Visuals are not done indeed, but there is no reboot of development to do so needed, Duke Nukem team could not cope with upgrades without majorly dropping codebase what just shown the codebase was what we can call "spaguetti" and they couldn't work with it anymore gets to a point just reboot the thing is going to be faster. On SC when the game went through the huge scope increase AND the followed engineering debt this already happened they hired a lot of on engineering positions and reworked a lot of the engine, most of that was not because of the graphics yet because of the scale of what needed to be added went beyond what the engine could ever do, from an isolated map loading in on-rails to a full city planet procgen, with the scope vastly settled they just work on what needs to be done, the "cutting edge" thing does not apply to much that work, unless like on the beginning of my post the work done doesn't cope with the performance budget or is too unstable and becomes a problem that needs rework.
And you want to say something like "bogus dude, graphics are just visual and have nothing to do with the network or online play" and then I would just inform you that if they develop graphics as purely client side assets, then SC will be hacked to hell the first week it's out and the game will be thoroughly screwed. Positioning of elements, collision, physics modeling, etc all needs some measure of compliance through server synchronization otherwise people can effectively tell the game anything they want. That puts a toll across the entire game and engine as it has to communicate all that information alongside standard player actions and rest of the stuff taking place.
The graphics and network argument makes no sense to me.
First this is a multiplayer game so what we are talking about are ENTITIES, when a ship loads in on the game it's processed on the server as an entity it's your client who loads the assets the network tells you to.
When a ship comes into view, what is happening in the server telling you the client to load X assets, I don't understand where you think that MMOs are streaming assets to your client, the standard of MMOs is network tells the client what assets to load it's not possible have the server send the actual asset the client needs would be a lag-madness.
What makes something heavy on network is how complex entities are, when a big ship comes into view on the game what is costing resources to the server is not how SHINY and detailed the ship visually is, is how many netcoded elements that ship has, and ships HELL have a lot of those from their individual components to the physics grid and even their internal atmosphere as part of the game's sim aspect.
So you are misunderstanding some here as to how MMOs deal with assets on the client, if you go into hacks and manipulate the assets on your client you won't be exploiting anything, the server is authoritative on what it needs to be, the server does not give you the assets of a gun it just controls the data if you manipulate on your client to try to have that gun shoot faster or do more damage it doesn't work because that is the relevant data that is server-sided, entity not the asset. You could try to mess up collisions on your client assets to clip through things in-game this has been a frequent enough hack on games but here the server is aware of the collisions of the spawned entities despite the assets loading from the client.
There are a lot of back end calculations that goes into modern graphics. The basic technology may not be new, but the scope has readily increased and as more engines switch to using 64 bit processes they will also carry with them the need for new methods to deal with process loads. This was brought up regarding SC itself and 64 bit precision versus 32 bit double precision.
This also ties into your misunderstanding of server and client side communication regarding assets. You conflated rendering of assets to be the same as it's physics and meta data, that does indeed have to be tracked by the server. Information that as graphics gets more complex and reliant on the same physics that is used to model the collision and movement of assets within the game, you begin having to deal with a broader scope of information the server has to keep in sync.
Which is also where your statement fails yet again. When major components of the network are not in place, and they have yet to know the full scope of features that the game has to handle loading and unloading within the game in regards to NPCs, players, entity density, and entity activity, then you can be guaranteed that there will be much redesigning needed to balance to keep the game stable.
Which stacks in a manner you did not account for or acknowledge regarding the graphics element as well. The more entities a server has to tell a client to render, the more entities a server has to send updates to for the client, the more meta data on entities and the game's physics and AI emulations, the more the client itself will be bogged down on top of anything it renders.
It is ironic you try to assert misunderstanding on my end about that, when you restated a point I made, and then promptly forgot how that affects you claims detrimentally.
Also, your semantic quibble about the use of entities when I referred to them as objects is noted, and can be promptly ignored because ENTITY CONTAINERS are a type of, well, container. Quibbling over that as if you know something does not contribute to your argument, it only spawns pointless pedantics such as this where I have to correct some pointless inanity.
And indeed, talking about things that affects stuff much of the game depends on has been the only thing I have been talking about. Why do you think I've brought up the point of the game's physics simulations multiple times across these last several posts in spite of your aversion to acknowledging that? Because when the physics in the game, and consequently the myriad of collision detection and physics simulated elements of motion and combat, are done client side, security for an online game becomes damn near impossible. That has to be vetted on the server for security, or the game is hackable to high hell. And that does affect the visuals of the game alongside many other things, especially so when ships fly through complex physics simulated elements.
You example of a company working on graphics after launch is also a rather weak one. Major graphics enhancements for MMOS have required from the studios that have done them a massive amount of time and effort dedicated to remodeling assets as well as generally porting to new versions of an engine and updating even visually unimproved assets accordingly. Warframe has taken a long time on their upgrades, and they use a client-based matchmaking system that uses central servers for specific components of the game only.
We also have the outstanding issue that you ave tried to cut the argument to one of graphics alone, which is a very reductive argument when the original statement of "cutting edge" referred to a much broader case than that. Everything from AI, method of animation, methods of rendering, methods of physics simulation, 32 vs 64 bit computation and precision, entity component vs container systems, etc. It's nice you spent some time doing QA, that is a rather weak appeal to authority however, and is not a job that will inform you of much of the depth of developing many of these systems or how they actually interact with each other. As you have demonstrated.
This also ties into your misunderstanding of server and client side communication regarding assets. You conflated rendering of assets to be the same as it's physics and meta data, that does indeed have to be tracked by the server. Information that as graphics gets more complex and reliant on the same physics that is used to model the collision and movement of assets within the game, you begin having to deal with a broader scope of information the server has to keep in sync.
Which is also where your statement fails yet again. When major components of the network are not in place, and they have yet to know the full scope of features that the game has to handle loading and unloading within the game in regards to NPCs, players, entity density, and entity activity, then you can be guaranteed that there will be much redesigning needed to balance to keep the game stable.
Which stacks in a manner you did not account for or acknowledge regarding the graphics element as well. The more entities a server has to tell a client to render, the more entities a server has to send updates to for the client, the more meta data on entities and the game's physics and AI emulations, the more the client itself will be bogged down on top of anything it renders.
It is ironic you try to assert misunderstanding on my end about that, when you restated a point I made, and then promptly forgot how that affects you claims detrimentally.
Also, your semantic quibble about the use of entities when I referred to them as objects is noted, and can be promptly ignored because ENTITY CONTAINERS are a type of, well, container. Quibbling over that as if you know something does not contribute to your argument, it only spawns pointless pedantics such as this where I have to correct some pointless inanity.
And indeed, talking about things that affects stuff much of the game depends on has been the only thing I have been talking about. Why do you think I've brought up the point of the game's physics simulations multiple times across these last several posts in spite of your aversion to acknowledging that? Because when the physics in the game, and consequently the myriad of collision detection and physics simulated elements of motion and combat, are done client side, security for an online game becomes damn near impossible. That has to be vetted on the server for security, or the game is hackable to high hell. And that does affect the visuals of the game alongside many other things, especially so when ships fly through complex physics simulated elements.
You example of a company working on graphics after launch is also a rather weak one. Major graphics enhancements for MMOS have required from the studios that have done them a massive amount of time and effort dedicated to remodeling assets as well as generally porting to new versions of an engine and updating even visually unimproved assets accordingly. Warframe has taken a long time on their upgrades, and they use a client-based matchmaking system that uses central servers for specific components of the game only.
We also have the outstanding issue that you ave tried to cut the argument to one of graphics alone, which is a very reductive argument when the original statement of "cutting edge" referred to a much broader case than that. Everything from AI, method of animation, methods of rendering, methods of physics simulation, 32 vs 64 bit computation and precision, entity component vs container systems, etc. It's nice you spent some time doing QA, that is a rather weak appeal to authority however, and is not a job that will inform you of much of the depth of developing many of these systems or how they actually interact with each other. As you have demonstrated.
You are stretching stuff here to tie graphics to servers, there are games with amazing graphics yet with the most basic entities that are cheap on the server resources due to small amounts of networked data with simple entities.
You are trying to connect both implying that better graphics mean more server work like that means that the servers will forcefully have to do more, that is not based on graphics yet on the complexity of the entities added.
I have been MMO's where the character is very high quality in terms of textures, animations, etc... yet server-side its hitbox is a RECTANGLE the cheapest on network, the high quality visuals had none to do with the server calculations, even animations all of the character are client-sided the server just networks the action to surrounding players in case of movement, emotes, etc...
So I will not take this argument on servers against graphic complexity, Star Citizen devs could make the ships collisions with the hitboxes plain simple rectangles hitting gameplay without hitting the graphical complexity of such ships.
"Which stacks in a manner you did not account for or acknowledge regarding the graphics element as well. The more entities a server has to tell a client to render, the more entities a server has to send updates to for the client, the more meta data on entities and the game's physics and AI emulations, the more the client itself will be bogged down on top of anything it renders."
Yes, any server that has more entities on it has the more resources the server needs up to the point when high density can hit performance, but what the hell does that have to do with graphics?
You keep trying to bridge the fact that the graphical complexity of the entities that are spawned means how complex those entities are on the server...
But just no, there are games around with any high-quality graphics that have pretty much anything a SC ship has, from an atmosphere to internal physics to simulation of individual components, to things as realistic moving thrusters and so forth, that stuff does not make the game graphically complex it makes the game mechanically complex, and those yes, determine how complex the entities are and how "expensive" they can be on a server.
A game can have high-quality graphics with a low complexity on its entities, it's a DESIGN CHOICE from the developers it's not required, SC is a sim that invests on the complexity of things so it does a lot of simulation, but on the generality of the MMOs such is not the case, independent of the graphics the entities are as simple as they can get.
From your comment on the hacking post I don't know why but you seem to merge the simulation of things like collisions and such with it but not at all, when a ship entity is around you load the ship assets from your filesystem the server is authoritative so the hitboxes and the collisions of such spawned entity are handled/validated by the server. And as far as collisions go like I said they can be simplified if devs want it's a design choice, and not at the cost of the quality of graphics yet at the cost of gameplay.
I just picked on this because while the individual arguments are not wrong, but trying to imply a graphical quality of a game is that relevant to determine the impact it has on a server is just not true because a developer can have one without the other, it's whatever their design is, having a great-looking game with simple simulation leading to simpler entities on the server or a graphically lower-quality game with a lot of simulation and complex entities.
You are stretching stuff here to tie graphics to servers, there are games with amazing graphics yet with the most basic entities that are cheap on the server resources due to small amounts of networked data with simple entities.
You are trying to connect both implying that better graphics mean more server work like that means that the servers will forcefully have to do more, that is not based on graphics yet on the complexity of the entities added.
I have been MMO's where the character is very high quality in terms of textures, animations, etc... yet server-side its hitbox is a RECTANGLE the cheapest on network, the high quality visuals had none to do with the server calculations, even animations all of the character are client-sided the server just networks the action to surrounding players in case of movement, emotes, etc...
So I will not take this argument on servers against graphic complexity, Star Citizen devs could make the ships collisions with the hitboxes plain simple rectangles hitting gameplay without hitting the graphical complexity of such ships.
"Which stacks in a manner you did not account for or acknowledge regarding the graphics element as well. The more entities a server has to tell a client to render, the more entities a server has to send updates to for the client, the more meta data on entities and the game's physics and AI emulations, the more the client itself will be bogged down on top of anything it renders."
Yes, any server that has more entities on it has the more resources the server needs up to the point when high density can hit performance, but what the hell does that have to do with graphics?
You keep trying to bridge the fact that the graphical complexity of the entities that are spawned means how complex those entities are on the server...
But just no, there are games around with any high-quality graphics that have pretty much anything a SC ship has, from an atmosphere to internal physics to simulation of individual components, to things as realistic moving thrusters and so forth, that stuff does not make the game graphically complex it makes the game mechanically complex, and those yes, determine how complex the entities are and how "expensive" they can be on a server.
A game can have high-quality graphics with a low complexity on its entities, it's a DESIGN CHOICE from the developers it's not required, SC is a sim that invests on the complexity of things so it does a lot of simulation, but on the generality of the MMOs such is not the case, independent of the graphics the entities are as simple as they can get.
From your comment on the hacking post I don't know why but you seem to merge the simulation of things like collisions and such with it but not at all, when a ship entity is around you load the ship assets from your filesystem the server is authoritative so the hitboxes and the collisions of such spawned entity are handled/validated by the server. And as far as collisions go like I said they can be simplified if devs want it's a design choice, and not at the cost of the quality of graphics yet at the cost of gameplay.
I just picked on this because while the individual arguments are not wrong, but trying to imply a graphical quality of a game is that relevant to determine the impact it has on a server is just not true because a developer can have one without the other, it's whatever their design is, having a great-looking game with simple simulation leading to simpler entities on the server or a graphically lower-quality game with a lot of simulation and complex entities.
Didn’t CIG promise if your ship was shot in the wing then that wing will show damage and that damage state is supposed to be like that for all the ships? Plus you can do different things to disable that ship (or was that the fever dreams of the fans trying to make it sound more awesome then is possible?)
A game can have high-quality graphics with a low complexity on its entities, it's a DESIGN CHOICE from the developers it's not required, SC is a sim that invests on the complexity of things so it does a lot of simulation, but on the generality of the MMOs such is not the case, independent of the graphics the entities are as simple as they can get.
Didn’t CIG promise if your ship was shot in the wing then that wing will show damage and that damage state is supposed to be like that for all the ships? Plus you can do different things to disable that ship (or was that the fever dreams of the fans trying to make it sound more awesome then is possible?)
So maybe not so simple as a rectangle hit box?
Indeed, they also talked about discrete systems damage, realistic flight physics and modeling, 64 bit precision, and a myriad of other things that weighs on a server.
He is trying to be reductive in his argument in order to be defensive of a position, and losing out on logic in doing so. Especially so for the fact that he is also making false assertions which I should address.
Bacon boy, you're the only one that has tried to associate everything to graphics. While I have noted there is indeed a connection between graphics and mechanics, you are making a hyperbolic argument out of it that does not even exist in an attempt to ignore what's actually stated.
What was noted, is that complex physics simulations, animations that require kinematics and collision with dynamic objects, 64 bit precision modeling, entity containers vs entity components, etc all affects both the mechanics as well as the visuals of the game and all weigh both on the client and the server.
What I have discussed is the fact that, with incomplete major components like the networking layer and architecture, there are a lot of systems that will have to go through major revisions. Bacon boy has tried to reduce focus to graphics and saying that the graphics component is almost complete and won't need any major revisions, which is both a dishonest argument as well as a false one. It's dishonest because graphics is simply not the only system, and bacon already admitted the game is still lacking some rather major components, which when they are brought up will have to be merged and balanced against the rest of the game's systems. Like most every other game in history, compromises will need to be made, and other systems like graphics will have to go through a lot of revisions along with any other system that has mechanics like the one's mentioned prior.
Bacon also avoids a fundamental truth with his "but there's games with all this stuff in it" argument. Look at any such game, and note the complexity of the environment and the density of AI or player entities, and realize how sparsely packed the content and subsequent visuals are in order to offset the demand the rest of the system has on one's machine. Even No Man's Sky, as one of the more visually striking titles, uses simpler models than most and utilizes dynamic elements like tesselation where it can spare in order to make the visuals look better. Otherwise it leans into the Pixar-esque bold shapes and colors to make it look good, rather than any massive depth to environmental complexity. It also has a simpler physics and mechanics behind most systems.
And sure, a game "can" have high graphical detail with low entity complexity. But then we'd call it a prop. Something that's largely non-interactive and sucks up rendering power to do nothing but look good in someone's little digital house or something. But then you start making it interactive, have different states, have dynamic physics simulation, has mass and weight values, have components that can be individually and/or globally damaged, add various snap points for sitting or grabbing it, etc. Suddenly, that thing has a budget you have to pay attention to, yet it's still just a chair.
Which is where his little hacking counter also ends up failing, because his continued obsession with graphics and projecting the idea that graphics is everything onto the opposing argument. Makes it so he can't even understand the argument because he's trying to reinterpret it to fit a notion that already fundamentally makes no sense, and purposely so since he want things he considers oppositional to his position to appear to make no sense. So instead of address how core components of the system are still client side right now and requires server validation that presently does not exist, and would need a lot of revisions to migrate to a server-client system, he will mention the notion of server validation to justify his skewed graphics focused argument, and ignore that the server architecture and mechanics are far from even completed or implemented in the intended scope to do such things. As was brought up in the other thread going on, they may be scaling up the player count slowly, but there's a bit of a gap there between having people stand around as entities doing nothing, and the quick drop of such numbers to 'dozens' in a busy situation. That side of the tech needs to catch up, and the more stuff there is about entities and more ways entities can interact, the more that draws from other elements, including the visuals.
Which bears another point that the visuals are not just a server communication problem. Yes, the content the server has to communicate does actually affect visual elements of the game as it relates to complexity, but that same complexity weighs on the client side engine, especially so when it's the workhorse for taking that data and interpreting it all into the action on the screen while simultaneously tracking what the player is doing and pitching it back.
So basically, he tried to use reductive reasoning to ignore everything but the graphics of the game, and has made some dishonest arguments that don't align with reality to try and maintain that subject.
Fact is, his premise ends up being false. From the fact that he frames a supposition he was the one to propose and project it in order to then try and assert it's an absurd stance, which is very simply dishonest. Up to his conclusions that something can be graphically detailed but mechanically simple, which ignores how devoid of functionality and scope the resulting game would be. Last I'd heard SC was supposed to be a game full of things to interact with and do, not a virtual museum. So he tried to mask a simple and 'technically true' claim as a valid counterpoint, even though entities in SC are anything but simple with the intended scope of the game.
I am talking on game development in general, not specifically SC that doesn't need to be said that they take a highly complex approach on the simulation of anything that goes on, the majority on the gameplay aspect not the graphics.
This rant of yours manipulates what I said several times to put it against another context, the graphics talk is on game-dev in general, shown by your last paragraph and the many jabs.
What I had a go at, is the argument pushed that a graphically high-quality game result on the servers taking the weight of that, what is not true and repeating myself, it's a design choicethat developers take on either path they go a multiplayer game can be high-quality graphics with a small impact on the network, vice-versa, and both, and the vast majority of that is the collisions on the graphical front when it wanted more realistic, then we have added mechanics that exist independent of the graphics complexity.
You just going on attacking me and posting a wall of text, but silly stretched arguments like the one on hacking you just posted shows you don't know how SC servers work right now and are making statements out of thin air, server validation does not exist, client-sided core systems... the servers are already authoritative and control data... you refuse to understand that the fact the assets load from the filesystem that the client has all control over the data while in-game when they don't have that access because it's the server who spawns in entities with the intended data. Client-sided graphics does not mean the detailed data on configurations of a ship for example and so forth is ever loaded from the client.
I am not even going to bother anymore as it's clear you will just become more toxic in any following discussion to lay jabs towards me, I'll stick with links and sources with clear information I don't need walls of text that turn toxic with the classic forum tactic "quote a random user to have a go at X other user".
What you "had a go at" was what my last paragraph pointed out, the false premise you built.
You proposed that graphics was the main concern. You proposed that it was a past hurdle. You marginalized the argument in an attempt to ignore the actual point that was made. Duke Nukem Forever's problem wasn't about the graphics. Though that certainly played a role, the reason for many revamps came from a myriad of changes in engine and technology as Apogee/3D Realms developed the game and the concept and scope changed with new options that became available.
Attacking you? No, I listed off what you wrote, and then I explained it faults. If you find correcting things to be an attack, then that's a personal problem for you.
You, on the other hand, have tried to claim things YOU have written as my position on this, and that is very simply dishonest. Morally devoid.
And you are not talking on game development in general because you are actively trying to ignore the very real factors that have been laid out.
Should we go back and start quoting everything?
Do I have to quote where you tried to sweep the advancing technology ("cutting edge") argument under the rug by claiming the only major thing that's advanced for them is the graphics.
Which has been noted as a false argument, and how it's a false argument by noting the variety of ways that SC has claimed it's trying to push the flight model and simulation elements of the game, and some of the tech that's been involved in that.
Do I have to quote where you tried to take my statement (that graphics does not exist in a vacuum, and laid out specific examples of the type of gameplay elements that servers have to track which also happen to directly affects the visuals of the game) and you ignored the examples and noted tech to instead make a straw man about graphics?
Which has been noted as a false argument, because we can go back and see that there were specific factors called out and even mentioned how they impact servers due to the increase in entity meta data.
Do I have to quote where you tried to distract from that by quibbling about the term "entity" because I wrote "container"?
Which has been noted as a false argument, as "entity" refers to an "entity container".
Do I have to quote where you claimed an object could be graphically complex, but it's entity could be simple?
Which has been noted as a false argument, because in order for an entity to have interactive elements it needs to have the content within it to enable any given functionality. The best you can do is claim being semantically correct on this one point in that a simple object that does nothing can be a light load on the server while being visually complex. Yet, it;s a statement that bears zero relevance on the topic, because ALL games requires entities to increase in complexity of their content in order to be functioning assets within a game. If all it has is collision, then it's little more than a static environmental feature.
This constant making up of statements does not make you a rational or reasonable person. Point in case, you try to attack the hacking dilemma again, while completely undermining your own argument. You brought up nothing new with your argument there, and instead restated things that I said. Things I said in the very post you were just responding to even, and I broke down the distinction of how it taxes the client differently than the server. Instead, you make the claim that the servers are already authoritative, and make the claim "it's the server who spawns in entities", but you do not address the fact that such a statement is itself illogical.
Reason being, Each interacting client carries with it the entity data that's being communicated from their client to the server in order to understand at all what it is the player is trying to do. That input data has to be interpreted, and that has to either be done on the client, the server, or both. If the client handles translation of that information and how it affects things at a basic level, which it does in most games in order to make the game feel responsive. If it's the server spawning and managing that entity and input data, then you immediately have to deal with how responsive the game servers are and the subsequent input lag.
You see the problem you stumbled into there? You just made the claim that it's the server saddled with management of player actions, ship and character configurations, physics simulations, etc. Do you not understand the sheer burden you just saddled the server with? Do you not understand that if the client does not model any of this, then that would mean SC has to create an extra translation of the things the server is doing to associate it with what the client is supposed to be rendering?
"You refuse to understand" your explanations unfortunately are causing more logical problems as you continue.
You talk about links and sources, yet you have offered none here for your arguments.
You talk about "going on attacking" and "jabs", but I doubt you can quote any statement that is an attack.
Instead, you are now playing a silly victim card?
By all means bow out of the conversation, but is it so hard to be honest while doing so? Did you really have to lie?
You see the problem you stumbled into there? You just made the claim that it's the server saddled with management of player actions, ship and character configurations, physics simulations, etc. Do you not understand the sheer burden you just saddled the server with? Do you not understand that if the client does not model any of this, then that would mean SC has to create an extra translation of the things the server is doing to associate it with what the client is supposed to be rendering?
"You refuse to understand" your explanations unfortunately are causing more logical problems as you continue.
You talk about links and sources, yet you have offered none here for your arguments.
You talk about "going on attacking" and "jabs", but I doubt you can quote any statement that is an attack.
Instead, you are now playing a silly victim card?
What I understand is that you don't understand how the SC servers work seen by your previous post saying stuff as servers don't validate like servers aren't authoritative, neither understanding what is said about how is the server in the MP environment is going to determine when & what a client will render from its client, such as when another ship comes into range, it is the server who controls the data, the client the assets.
Something else you are saying in exploitation is collisions to not be client-sided, see because a server will always tick less than the client a mixed solution allows for more smooth gameplay. Fully server-sided collisions can cause an overall laggy feeling and jumpy as the server can never send updates fast enough, so if you could let the client for speed purposes and the server for sanity checks to validate and prevent cheating. You can notice on MMOs some with fully server-sided collisions you can actually run and clip into things to then be pushed back as the server doesn't update fast enough, others where that never happens so I think they involve the client for the sake of speed and then the server for the sake of security. I am not sure how SC is doing collisions rn. But anyway don't mind me, I usually like tech talk but this is just on a tone that just gets toxic.
What you understand is a skewed belief at best. Point in case, you want to claim I dont know how the servers operate, but between these last two pages we can pull contradicting quotes from you on the state of the server and how it works, as you continue to change your argument to fit the moment.
The fact you have to make up lies outright, claiming I said "servers don't validate" or "aren't authoritative" just shows you've slipped in this behavior far enough to abandon reason outright. Are you capable of an honest argument at all at this point, or is trying to make things up all you've got?
Your second paragraph reads like you didn't even actually read what I wrote, as you bring up things yet again that I prior stated. You have done this multiple ti.es now, going 'no' and then functionally repeating me while failing to u understand the implications of the things you're mentioning.
Like your collision statement, and how you conveniently forgot od already talked about that in the context of server latency versus client side emulation and the use of server validation on that end.
You don't get to make the claim that the server does everything, then when it's pointed out to you that your argument is illogical completely flip to the opposing side and pretend it wasn't you who was making that illogical claim.
You have no right to make any comment about toxicity when you've stopped so low as to brazenly lie and make such duplicitous arguments.
Play the victim if you want, but understand your bluff has been called. Don't claim you "like tech talk" while actively lying about it at every turn.
You see the problem you stumbled into there? You just made the claim that it's the server saddled with management of player actions, ship and character configurations, physics simulations, etc. Do you not understand the sheer burden you just saddled the server with? Do you not understand that if the client does not model any of this, then that would mean SC has to create an extra translation of the things the server is doing to associate it with what the client is supposed to be rendering?
"You refuse to understand" your explanations unfortunately are causing more logical problems as you continue.
You talk about links and sources, yet you have offered none here for your arguments.
You talk about "going on attacking" and "jabs", but I doubt you can quote any statement that is an attack.
Instead, you are now playing a silly victim card?
What I understand is that you don't understand how the SC servers work seen by your previous post saying stuff as servers don't validate like servers aren't authoritative, neither understanding what is said about how is the server in the MP environment is going to determine when & what a client will render from its client, such as when another ship comes into range, it is the server who controls the data, the client the assets.
Something else you are saying in exploitation is collisions to not be client-sided, see because a server will always tick less than the client a mixed solution allows for more smooth gameplay. Fully server-sided collisions can cause an overall laggy feeling and jumpy as the server can never send updates fast enough, so if you could let the client for speed purposes and the server for sanity checks to validate and prevent cheating. You can notice on MMOs some with fully server-sided collisions you can actually run and clip into things to then be pushed back as the server doesn't update fast enough, others where that never happens so I think they involve the client for the sake of speed and then the server for the sake of security. I am not sure how SC is doing collisions rn. But anyway don't mind me, I usually like tech talk but this is just on a tone that just gets toxic.
and you do then? or is supose SC server do what no other server do?
Comments
That does not hit the game content/mechanics, the slowdown is more on that own department but that progression is not a bad thing having the graphics team constantly pumping improvements, this happens even on released games so they won't be going anywhere.
The whole "Duke Nukem" moment on SC already passed, it peaked on 2015/16 when the scope grown and they had a large engineering debt as the engine needed heavy refactors to allow for wanted features. Now the graphics is an easier front because they are their own teams that can work independently of the tech/features.
@MaxBacon I just can't get into the game yet for some reason (mentally - not technically) It checks all the boxes but I just don't find it "fun". I haven't done much yet though. I tried a bit ago but there was some issue that was messing something up. I will try again. Still haven't gotten far out of the hanger.
Wa min God! Se æx on min heafod is!
SC is not past anything until they manage a complete and readily consumed product. Until then it has every same chance to be a success as it has to be a massive flop.
When they added new lightning, the new fog system, new particles system, updated models, etc... that is all artist work after tech updates it's not who is creating the actual game features that need to go there do it, it would be a waste of their expertise. Hence why big studios are known for having literal armies of artists so they cope with it.
There are engineering tasks, such as the upgrade to DX12/Vulkan that are going to cost engineering time and seems to be the biggest in the graphics area.
The engineering debt phase, aka Duke Nukem is not SC's boogeyman today, there are still engineering hurdles but the game is already far from the engineering problems that completely stalled the game years ago, such as, until OCS they couldn't add a planets/expand the game-world because of daunting memory issues. SC has been visibly knocking down its challenges that are the fundamental pieces that make the game, the shiny visuals are an addon comparing to that work.
SC is quite more unique when it comes to funding and development resources, that is what has been core to did and continue to surpass its dev challenges that could have otherwise potentially sunk the project.
This is furthered when certain graphical elements, like character and vehicle animation, is tied to physics-bound actions. Them showing off water caustics? That liquid in that cup is processing power. And it doesn't come from nowhere nor does it not have to be budgeted against everything else.
Nothing in development is separated from the rest of the things going into a game and it's engine.
Which bears reiteration, "engineering debt" is going to exist as long as they keep adding things to the game/engine. As they are going to be constantly updating, tweaking, and tuning it, if not having to deal with even broader revamps as new features need to get merged with old ones.
And that's avoiding the point of the Duke Nukem comparison, that of the game developing on one standard, only to have to stop and redo things because there's a new benchmark out before they could release. Perpetually chasing a cutting-edge they can't obtain.
When they added the new fog what happens then is not of the support of programmers is the artists, they went update/review all locations that needed or used the legacy system to the new one, on this aspect that is not a quick one but it's also not sinking the important departments time when SC's development is put in question.
And yes many of these updates are aside of the visual improvement is the fact they are able to do more with less of a performance impact, at this stage the last major (and upcoming ones as Vulkan) graphics steps have been an optimization and efficiency effort while increasing the visual quality.
SC has money and resources so they afford to have these teams dedicated to graphics unlike the majority of the indie/early-access/crowdfunded projects around, the development doesn't have to face stalls on the usual gameplay fronts because there is a new graphics tech coming online.
So visuals will remain shiny, if you'd want to see something that would cause development features to stop because of there are aspects being imposing problems we might look at the AI or the network that are areas not yet capable to cope with the scope of the game.
The "cutting edge" outside graphics I don't see that much relevant stuff, games have been using the same standards for a long time as far how the technology and how certain features are created, and we can see that by looking at the available game engines where many times the same old methods and tools just get new versions, and that is meant exactly so the devs don't have to redo everything just to do implementations.
This is why I asked before whether you understood how many times the Duke Nukem title was rebooted due to them choosing to update the engine and tech. It wasn't once, it was multiple as they cyclically went through trying to match to new ideas and the evolution of hardware and the marketplace.
Having the money and resources to have a team dedicated to graphics and engine optimization does not magically make that issue go away, it just means you are spending thousands to millions extra more on a problem that's going to persist as long as that game persists.
Bold last paragraph from you as well given how much they have tried to up sell the use of new or novel technology/implementations. Admission the game is not using new methods or technology standards kind of drags you right back into the prior talked about issues though. Every doodad you place, every assets a client sees in the environment, is something that the network has to support placement and implied collision or any other associated elements that object/container has attached to it. Every node that spawns fog, every light/ray source, and especially every dynamic object. If network is not yet capable of handling the scope of the game, you are going to see the visual side of the game being tweaked about a ton as they try to continue developing that in order to get all things balanced and cooperating stably enough for it to run fine.
And you want to say something like "bogus dude, graphics are just visual and have nothing to do with the network or online play" and then I would just inform you that if they develop graphics as purely client side assets, then SC will be hacked to hell the first week it's out and the game will be thoroughly screwed. Positioning of elements, collision, physics modeling, etc all needs some measure of compliance through server synchronization otherwise people can effectively tell the game anything they want. That puts a toll across the entire game and engine as it has to communicate all that information alongside standard player actions and rest of the stuff taking place.
So not only are the visuals of the game far from done, they are likely awaiting some major revisions as other features of the game/engine have to still be implemented and merged together, and the resulting impact on performance or introduction of new bugs/problems takes place. This actually becomes more of a problem with more disparate teams working on separate lines of code that have to get later merged together, because not everyone codes in the same way.
"True friends stab you in the front." | Oscar Wilde
"I need to finish" - Christian Wolff: The Accountant
Just trying to live long enough to play a new, released MMORPG, playing New Worlds atm
Fools find no pleasure in understanding but delight in airing their own opinions. Pvbs 18:2, NIV
Don't just play games, inhabit virtual worlds™
"This is the most intelligent, well qualified and articulate response to a post I have ever seen on these forums. It's a shame most people here won't have the attention span to read past the second line." - Anon
My last paragraph is simply how things tend to be, beyond the graphics what drives the visual quality/detail of a game there is not much going on, games are still generally built on tools and standards that are decades old, just improved over time not redone to entire new technology. Reworks, revisions, etc... are part of the development of any game of complex scope, long undertakings with usually hundreds iterating on it, that doesn't mean anything aside that they go through the same process in a quite harder reality as the ambition of the devs has forced big pushes on technology to achieve viability.
They have dedicated teams to graphics it's no new thing, and they have the money to sustain it, the new graphics tech, improvements and such have been coming along together with the game feature-set, and they do not break the actual game mechanics aside of the bugs that require artists to review a lot of things to maintain the expected result. SC is also an MMO so this work will continue AFTER the game releases, and we see this same progress on released titles with devs that are more passionate about their work, such as Warframe.
When you talk about this things you must talk about undertakings that hit the engine and features that are more core that much stuff depends on, changing those is when everything goes to hell because everything has to be updated, this happened on SC in multiple visible occasions but the graphics updates with new systems/tech have not been any core cause.
Visuals are not done indeed, but there is no reboot of development to do so needed, Duke Nukem team could not cope with upgrades without majorly dropping codebase what just shown the codebase was what we can call "spaguetti" and they couldn't work with it anymore gets to a point just reboot the thing is going to be faster. On SC when the game went through the huge scope increase AND the followed engineering debt this already happened they hired a lot of on engineering positions and reworked a lot of the engine, most of that was not because of the graphics yet because of the scale of what needed to be added went beyond what the engine could ever do, from an isolated map loading in on-rails to a full city planet procgen, with the scope vastly settled they just work on what needs to be done, the "cutting edge" thing does not apply to much that work, unless like on the beginning of my post the work done doesn't cope with the performance budget or is too unstable and becomes a problem that needs rework.
The graphics and network argument makes no sense to me.
First this is a multiplayer game so what we are talking about are ENTITIES, when a ship loads in on the game it's processed on the server as an entity it's your client who loads the assets the network tells you to.
When a ship comes into view, what is happening in the server telling you the client to load X assets, I don't understand where you think that MMOs are streaming assets to your client, the standard of MMOs is network tells the client what assets to load it's not possible have the server send the actual asset the client needs would be a lag-madness.
What makes something heavy on network is how complex entities are, when a big ship comes into view on the game what is costing resources to the server is not how SHINY and detailed the ship visually is, is how many netcoded elements that ship has, and ships HELL have a lot of those from their individual components to the physics grid and even their internal atmosphere as part of the game's sim aspect.
So you are misunderstanding some here as to how MMOs deal with assets on the client, if you go into hacks and manipulate the assets on your client you won't be exploiting anything, the server is authoritative on what it needs to be, the server does not give you the assets of a gun it just controls the data if you manipulate on your client to try to have that gun shoot faster or do more damage it doesn't work because that is the relevant data that is server-sided, entity not the asset. You could try to mess up collisions on your client assets to clip through things in-game this has been a frequent enough hack on games but here the server is aware of the collisions of the spawned entities despite the assets loading from the client.
There are a lot of back end calculations that goes into modern graphics. The basic technology may not be new, but the scope has readily increased and as more engines switch to using 64 bit processes they will also carry with them the need for new methods to deal with process loads. This was brought up regarding SC itself and 64 bit precision versus 32 bit double precision.
This also ties into your misunderstanding of server and client side communication regarding assets. You conflated rendering of assets to be the same as it's physics and meta data, that does indeed have to be tracked by the server. Information that as graphics gets more complex and reliant on the same physics that is used to model the collision and movement of assets within the game, you begin having to deal with a broader scope of information the server has to keep in sync.
Which is also where your statement fails yet again. When major components of the network are not in place, and they have yet to know the full scope of features that the game has to handle loading and unloading within the game in regards to NPCs, players, entity density, and entity activity, then you can be guaranteed that there will be much redesigning needed to balance to keep the game stable.
Which stacks in a manner you did not account for or acknowledge regarding the graphics element as well. The more entities a server has to tell a client to render, the more entities a server has to send updates to for the client, the more meta data on entities and the game's physics and AI emulations, the more the client itself will be bogged down on top of anything it renders.
It is ironic you try to assert misunderstanding on my end about that, when you restated a point I made, and then promptly forgot how that affects you claims detrimentally.
Also, your semantic quibble about the use of entities when I referred to them as objects is noted, and can be promptly ignored because ENTITY CONTAINERS are a type of, well, container. Quibbling over that as if you know something does not contribute to your argument, it only spawns pointless pedantics such as this where I have to correct some pointless inanity.
And indeed, talking about things that affects stuff much of the game depends on has been the only thing I have been talking about. Why do you think I've brought up the point of the game's physics simulations multiple times across these last several posts in spite of your aversion to acknowledging that? Because when the physics in the game, and consequently the myriad of collision detection and physics simulated elements of motion and combat, are done client side, security for an online game becomes damn near impossible. That has to be vetted on the server for security, or the game is hackable to high hell. And that does affect the visuals of the game alongside many other things, especially so when ships fly through complex physics simulated elements.
You example of a company working on graphics after launch is also a rather weak one. Major graphics enhancements for MMOS have required from the studios that have done them a massive amount of time and effort dedicated to remodeling assets as well as generally porting to new versions of an engine and updating even visually unimproved assets accordingly. Warframe has taken a long time on their upgrades, and they use a client-based matchmaking system that uses central servers for specific components of the game only.
We also have the outstanding issue that you ave tried to cut the argument to one of graphics alone, which is a very reductive argument when the original statement of "cutting edge" referred to a much broader case than that. Everything from AI, method of animation, methods of rendering, methods of physics simulation, 32 vs 64 bit computation and precision, entity component vs container systems, etc. It's nice you spent some time doing QA, that is a rather weak appeal to authority however, and is not a job that will inform you of much of the depth of developing many of these systems or how they actually interact with each other. As you have demonstrated.
You are stretching stuff here to tie graphics to servers, there are games with amazing graphics yet with the most basic entities that are cheap on the server resources due to small amounts of networked data with simple entities.
You are trying to connect both implying that better graphics mean more server work like that means that the servers will forcefully have to do more, that is not based on graphics yet on the complexity of the entities added.
I have been MMO's where the character is very high quality in terms of textures, animations, etc... yet server-side its hitbox is a RECTANGLE the cheapest on network, the high quality visuals had none to do with the server calculations, even animations all of the character are client-sided the server just networks the action to surrounding players in case of movement, emotes, etc...
So I will not take this argument on servers against graphic complexity, Star Citizen devs could make the ships collisions with the hitboxes plain simple rectangles hitting gameplay without hitting the graphical complexity of such ships.
"Which stacks in a manner you did not account for or acknowledge regarding the graphics element as well. The more entities a server has to tell a client to render, the more entities a server has to send updates to for the client, the more meta data on entities and the game's physics and AI emulations, the more the client itself will be bogged down on top of anything it renders."
Yes, any server that has more entities on it has the more resources the server needs up to the point when high density can hit performance, but what the hell does that have to do with graphics?
You keep trying to bridge the fact that the graphical complexity of the entities that are spawned means how complex those entities are on the server...
But just no, there are games around with any high-quality graphics that have pretty much anything a SC ship has, from an atmosphere to internal physics to simulation of individual components, to things as realistic moving thrusters and so forth, that stuff does not make the game graphically complex it makes the game mechanically complex, and those yes, determine how complex the entities are and how "expensive" they can be on a server.
A game can have high-quality graphics with a low complexity on its entities, it's a DESIGN CHOICE from the developers it's not required, SC is a sim that invests on the complexity of things so it does a lot of simulation, but on the generality of the MMOs such is not the case, independent of the graphics the entities are as simple as they can get.
From your comment on the hacking post I don't know why but you seem to merge the simulation of things like collisions and such with it but not at all, when a ship entity is around you load the ship assets from your filesystem the server is authoritative so the hitboxes and the collisions of such spawned entity are handled/validated by the server. And as far as collisions go like I said they can be simplified if devs want it's a design choice, and not at the cost of the quality of graphics yet at the cost of gameplay.
I just picked on this because while the individual arguments are not wrong, but trying to imply a graphical quality of a game is that relevant to determine the impact it has on a server is just not true because a developer can have one without the other, it's whatever their design is, having a great-looking game with simple simulation leading to simpler entities on the server or a graphically lower-quality game with a lot of simulation and complex entities.
So maybe not so simple as a rectangle hit box?
EQ1, EQ2, SWG, SWTOR, GW, GW2 CoH, CoV, FFXI, WoW, CO, War,TSW and a slew of free trials and beta tests
He is trying to be reductive in his argument in order to be defensive of a position, and losing out on logic in doing so. Especially so for the fact that he is also making false assertions which I should address.
Bacon boy, you're the only one that has tried to associate everything to graphics. While I have noted there is indeed a connection between graphics and mechanics, you are making a hyperbolic argument out of it that does not even exist in an attempt to ignore what's actually stated.
What was noted, is that complex physics simulations, animations that require kinematics and collision with dynamic objects, 64 bit precision modeling, entity containers vs entity components, etc all affects both the mechanics as well as the visuals of the game and all weigh both on the client and the server.
What I have discussed is the fact that, with incomplete major components like the networking layer and architecture, there are a lot of systems that will have to go through major revisions. Bacon boy has tried to reduce focus to graphics and saying that the graphics component is almost complete and won't need any major revisions, which is both a dishonest argument as well as a false one. It's dishonest because graphics is simply not the only system, and bacon already admitted the game is still lacking some rather major components, which when they are brought up will have to be merged and balanced against the rest of the game's systems. Like most every other game in history, compromises will need to be made, and other systems like graphics will have to go through a lot of revisions along with any other system that has mechanics like the one's mentioned prior.
Bacon also avoids a fundamental truth with his "but there's games with all this stuff in it" argument. Look at any such game, and note the complexity of the environment and the density of AI or player entities, and realize how sparsely packed the content and subsequent visuals are in order to offset the demand the rest of the system has on one's machine. Even No Man's Sky, as one of the more visually striking titles, uses simpler models than most and utilizes dynamic elements like tesselation where it can spare in order to make the visuals look better. Otherwise it leans into the Pixar-esque bold shapes and colors to make it look good, rather than any massive depth to environmental complexity. It also has a simpler physics and mechanics behind most systems.
And sure, a game "can" have high graphical detail with low entity complexity. But then we'd call it a prop. Something that's largely non-interactive and sucks up rendering power to do nothing but look good in someone's little digital house or something. But then you start making it interactive, have different states, have dynamic physics simulation, has mass and weight values, have components that can be individually and/or globally damaged, add various snap points for sitting or grabbing it, etc. Suddenly, that thing has a budget you have to pay attention to, yet it's still just a chair.
Which is where his little hacking counter also ends up failing, because his continued obsession with graphics and projecting the idea that graphics is everything onto the opposing argument. Makes it so he can't even understand the argument because he's trying to reinterpret it to fit a notion that already fundamentally makes no sense, and purposely so since he want things he considers oppositional to his position to appear to make no sense. So instead of address how core components of the system are still client side right now and requires server validation that presently does not exist, and would need a lot of revisions to migrate to a server-client system, he will mention the notion of server validation to justify his skewed graphics focused argument, and ignore that the server architecture and mechanics are far from even completed or implemented in the intended scope to do such things. As was brought up in the other thread going on, they may be scaling up the player count slowly, but there's a bit of a gap there between having people stand around as entities doing nothing, and the quick drop of such numbers to 'dozens' in a busy situation. That side of the tech needs to catch up, and the more stuff there is about entities and more ways entities can interact, the more that draws from other elements, including the visuals.
Which bears another point that the visuals are not just a server communication problem. Yes, the content the server has to communicate does actually affect visual elements of the game as it relates to complexity, but that same complexity weighs on the client side engine, especially so when it's the workhorse for taking that data and interpreting it all into the action on the screen while simultaneously tracking what the player is doing and pitching it back.
So basically, he tried to use reductive reasoning to ignore everything but the graphics of the game, and has made some dishonest arguments that don't align with reality to try and maintain that subject.
Fact is, his premise ends up being false. From the fact that he frames a supposition he was the one to propose and project it in order to then try and assert it's an absurd stance, which is very simply dishonest. Up to his conclusions that something can be graphically detailed but mechanically simple, which ignores how devoid of functionality and scope the resulting game would be. Last I'd heard SC was supposed to be a game full of things to interact with and do, not a virtual museum. So he tried to mask a simple and 'technically true' claim as a valid counterpoint, even though entities in SC are anything but simple with the intended scope of the game.
I am talking on game development in general, not specifically SC that doesn't need to be said that they take a highly complex approach on the simulation of anything that goes on, the majority on the gameplay aspect not the graphics.
This rant of yours manipulates what I said several times to put it against another context, the graphics talk is on game-dev in general, shown by your last paragraph and the many jabs.
What I had a go at, is the argument pushed that a graphically high-quality game result on the servers taking the weight of that, what is not true and repeating myself, it's a design choicethat developers take on either path they go a multiplayer game can be high-quality graphics with a small impact on the network, vice-versa, and both, and the vast majority of that is the collisions on the graphical front when it wanted more realistic, then we have added mechanics that exist independent of the graphics complexity.
You just going on attacking me and posting a wall of text, but silly stretched arguments like the one on hacking you just posted shows you don't know how SC servers work right now and are making statements out of thin air, server validation does not exist, client-sided core systems... the servers are already authoritative and control data... you refuse to understand that the fact the assets load from the filesystem that the client has all control over the data while in-game when they don't have that access because it's the server who spawns in entities with the intended data. Client-sided graphics does not mean the detailed data on configurations of a ship for example and so forth is ever loaded from the client.
I am not even going to bother anymore as it's clear you will just become more toxic in any following discussion to lay jabs towards me, I'll stick with links and sources with clear information I don't need walls of text that turn toxic with the classic forum tactic "quote a random user to have a go at X other user".
If you are holding out for the perfect game, the only game you play will be the waiting one.
You proposed that graphics was the main concern. You proposed that it was a past hurdle. You marginalized the argument in an attempt to ignore the actual point that was made. Duke Nukem Forever's problem wasn't about the graphics. Though that certainly played a role, the reason for many revamps came from a myriad of changes in engine and technology as Apogee/3D Realms developed the game and the concept and scope changed with new options that became available.
Attacking you? No, I listed off what you wrote, and then I explained it faults. If you find correcting things to be an attack, then that's a personal problem for you.
You, on the other hand, have tried to claim things YOU have written as my position on this, and that is very simply dishonest. Morally devoid.
And you are not talking on game development in general because you are actively trying to ignore the very real factors that have been laid out.
Should we go back and start quoting everything?
Do I have to quote where you tried to sweep the advancing technology ("cutting edge") argument under the rug by claiming the only major thing that's advanced for them is the graphics.
Which has been noted as a false argument, and how it's a false argument by noting the variety of ways that SC has claimed it's trying to push the flight model and simulation elements of the game, and some of the tech that's been involved in that.
Do I have to quote where you tried to take my statement (that graphics does not exist in a vacuum, and laid out specific examples of the type of gameplay elements that servers have to track which also happen to directly affects the visuals of the game) and you ignored the examples and noted tech to instead make a straw man about graphics?
Which has been noted as a false argument, because we can go back and see that there were specific factors called out and even mentioned how they impact servers due to the increase in entity meta data.
Do I have to quote where you tried to distract from that by quibbling about the term "entity" because I wrote "container"?
Which has been noted as a false argument, as "entity" refers to an "entity container".
Do I have to quote where you claimed an object could be graphically complex, but it's entity could be simple?
Which has been noted as a false argument, because in order for an entity to have interactive elements it needs to have the content within it to enable any given functionality. The best you can do is claim being semantically correct on this one point in that a simple object that does nothing can be a light load on the server while being visually complex. Yet, it;s a statement that bears zero relevance on the topic, because ALL games requires entities to increase in complexity of their content in order to be functioning assets within a game. If all it has is collision, then it's little more than a static environmental feature.
This constant making up of statements does not make you a rational or reasonable person. Point in case, you try to attack the hacking dilemma again, while completely undermining your own argument. You brought up nothing new with your argument there, and instead restated things that I said. Things I said in the very post you were just responding to even, and I broke down the distinction of how it taxes the client differently than the server. Instead, you make the claim that the servers are already authoritative, and make the claim "it's the server who spawns in entities", but you do not address the fact that such a statement is itself illogical.
Reason being, Each interacting client carries with it the entity data that's being communicated from their client to the server in order to understand at all what it is the player is trying to do. That input data has to be interpreted, and that has to either be done on the client, the server, or both. If the client handles translation of that information and how it affects things at a basic level, which it does in most games in order to make the game feel responsive. If it's the server spawning and managing that entity and input data, then you immediately have to deal with how responsive the game servers are and the subsequent input lag.
You see the problem you stumbled into there? You just made the claim that it's the server saddled with management of player actions, ship and character configurations, physics simulations, etc. Do you not understand the sheer burden you just saddled the server with? Do you not understand that if the client does not model any of this, then that would mean SC has to create an extra translation of the things the server is doing to associate it with what the client is supposed to be rendering?
"You refuse to understand" your explanations unfortunately are causing more logical problems as you continue.
You talk about links and sources, yet you have offered none here for your arguments.
You talk about "going on attacking" and "jabs", but I doubt you can quote any statement that is an attack.
Instead, you are now playing a silly victim card?
By all means bow out of the conversation, but is it so hard to be honest while doing so?
Did you really have to lie?
What I understand is that you don't understand how the SC servers work seen by your previous post saying stuff as servers don't validate like servers aren't authoritative, neither understanding what is said about how is the server in the MP environment is going to determine when & what a client will render from its client, such as when another ship comes into range, it is the server who controls the data, the client the assets.
Something else you are saying in exploitation is collisions to not be client-sided, see because a server will always tick less than the client a mixed solution allows for more smooth gameplay. Fully server-sided collisions can cause an overall laggy feeling and jumpy as the server can never send updates fast enough, so if you could let the client for speed purposes and the server for sanity checks to validate and prevent cheating. You can notice on MMOs some with fully server-sided collisions you can actually run and clip into things to then be pushed back as the server doesn't update fast enough, others where that never happens so I think they involve the client for the sake of speed and then the server for the sake of security. I am not sure how SC is doing collisions rn. But anyway don't mind me, I usually like tech talk but this is just on a tone that just gets toxic.
The fact you have to make up lies outright, claiming I said "servers don't validate" or "aren't authoritative" just shows you've slipped in this behavior far enough to abandon reason outright. Are you capable of an honest argument at all at this point, or is trying to make things up all you've got?
Your second paragraph reads like you didn't even actually read what I wrote, as you bring up things yet again that I prior stated. You have done this multiple ti.es now, going 'no' and then functionally repeating me while failing to u understand the implications of the things you're mentioning.
Like your collision statement, and how you conveniently forgot od already talked about that in the context of server latency versus client side emulation and the use of server validation on that end.
You don't get to make the claim that the server does everything, then when it's pointed out to you that your argument is illogical completely flip to the opposing side and pretend it wasn't you who was making that illogical claim.
You have no right to make any comment about toxicity when you've stopped so low as to brazenly lie and make such duplicitous arguments.
Play the victim if you want, but understand your bluff has been called. Don't claim you "like tech talk" while actively lying about it at every turn.
Gotta go get busy with PAX Dev now though, will be interested to see which way they flop later.