Addressing FPS issues with giganticism and fleet spam by using maintenance cost

[aRottenKomquat]

As far as FPS, I think we need to see what the developers can accomplish via optimizing the rendering and physics engines before we try out any major changes to game mechanics. Just yesterday I used the ellipsoid build helper to generate a 50-radius sphere and my FPS dropped horribly while the build helper was there. Considering the build helper is static geometry that doesn't change from frame-to-frame once generated, I suspect StarMade still has some very inefficient things going on in the render code, like recalculating geometry that hasn't changed and constantly updating the GPU's scene data with geometry that hasn't changed. But that's just my wild guess as an outsider. Hopefully optimization can make the FPS drop due to titans or large fleets a non-issue.

 

[Jojomo]

If 'non-invulnerable' stations generated faction points, there would be a reason to build such stations, a reason to defend them, and they would be a good target for faction warfare. Bigger stations aught generate somewhat bigger amounts, though not linearly. Of course we still need a reason for factions to actually go to war. Perhaps linking faction points to ship maintenance will ultimately be the goad, as factions will want to claim as many systems as possible to generate as many faction points as possible.

Sector rescources *should* be what makes war worthwhile (asteroids, planets), but it isn't there yet. As a workaround, one possibility would be making stations incredibly expensive to build, and also generate FP. Factions would fight over them then.
Inverted FP is another workaround.

As for the OP, I don't disagree with it, but I think it would be better to spend time and effort improving the net code so that hudreds of entities can be handled in a sector.

 

[Lukwan]

As for the OP, I don't disagree with it, but I think it would be better to spend time and effort improving the net code so that hudreds of entities can be handled in a sector.

I think everyone who plays SM can at least agree on this one point. The fact remains...

...no matter how slick the optimizations are, or how perfect code is...there will always be a point at which the hardware will present it's limitations. There will always be a need for the game-engine to regulate against unlimited growth of it's elements.

 

[Jasper1991]

Limiting the ability to have titans does not fix the FPS issues that are caused when a Titan enters your sector, assuming you get any lag at all.

 

[MacThule]

Limiting the ability to have titans does not fix the FPS issues that are caused when a Titan enters your sector, assuming you get any lag at all.

No - it does better. It prevents the kind of lag with which we are all concerned from occurring. Schine already has continually optimized to accommodate the rampant small-man syndrome Starmade seems to engender, and in response the scale of building has just increased.

Titan is a meaninglessly subjective term, and the so-called titans players field today are bigger than the titans from a year before. To hope that speculative "future optimizations" will somehow 'solve' players' ability to lag servers seems fruitless, when past optimizations have only spurred scale growth upward until it again scrapes the same inevitable physical performance cap of what a computer can perform. Optimization would be great, but even if Schine somehow halves the processor loads and insists that all players run on 32GB of RAM, the net result (based on observing past optimizations) will just be 50M mass titans lagging servers instead of 500K mass titans doing it.

The point at which the game breaks servers is irrelevant. The important issue that the game does crash servers, crash clients, and and lag out networks because more needs to be done to prevent players from performing actions in game that are known to cause such performance instability. At some point, the laws of physics and human nature must be acknowledged - no one's rig has infinite capability, and people will always push boundaries.

Without strong checks and balances on scale, without well-designed resistance factors to prevent incidences of game-breaking level lag, this game will always be unstable.

 

[Jasper1991]

No - it does better. It prevents the kind of lag with which we are all concerned from occurring. Schine already has continually optimized to accommodate the rampant small-man syndrome Starmade seems to engender, and in response the scale of building has just increased.

Titan is a meaninglessly subjective term, and the so-called titans players field today are bigger than the titans from a year before. To hope that speculative "future optimizations" will somehow 'solve' players' ability to lag servers seems fruitless, when past optimizations have only spurred scale growth upward until it again scrapes the same inevitable physical performance cap of what a computer can perform. Optimization would be great, but even if Schine somehow halves the processor loads and insists that all players run on 32GB of RAM, the net result (based on observing past optimizations) will just be 50M mass titans lagging servers instead of 500K mass titans doing it.

The point at which the game breaks servers is irrelevant. The important issue that the game does crash servers, crash clients, and and lag out networks because more needs to be done to prevent players from performing actions in game that are known to cause such performance instability. At some point, the laws of physics and human nature must be acknowledged - no one's rig has infinite capability, and people will always push boundaries.

Without strong checks and balances on scale, without well-designed resistance factors to prevent incidences of game-breaking level lag, this game will always be unstable.

All this means is that the Titan lag will happen less often, this does not stop it from happening when it does happen

 

[aRottenKomquat]

Modern first-person shooters can very quickly stream a huge amount of level geometry into video RAM and still run at a nice 60 fps while looking much better than StarMade. Can StarMade be optimized to the point that titans cause no lag? I don't know, but based on what other games are doing (including Minecraft) I would expect that it can be done somehow. If this game can reach that level of optimization, titan lag won't be a thing unless people start building titans that are several sectors in volume.

I still strongly suspect (gut instinct, obviously I haven't seen the game's code and could be totally wrong) there is some major inefficiency in the way the rendering system processes geometry and passes it to the GPU. I also strongly suspect the developers have prioritized new game features over render improvements at this stage, since performance is generally "good-enough" for testing purposes.

 

[Lukwan]

Sigh ...

...this thread is an attempt to discuss solutions for Restraint-of-Exponential-Growth in the elements that make up SM. Literally every other thread has people thumping on Schine to do it's optimizations NOW! This helps nobody.

Please stop.

Schine knows it has to do serious optimizations, and they know better than any of us that this should be done later in the development process not sooner because they don't want waste effort redoing things due to poor planning. The cart goes after the horse, not before it. This should be plainly obvious to anyone who is a project-manager. If the terms dependency and critical path mean nothing to you...please look them up.

 

[Jojomo]

Modern first-person shooters can very quickly stream a huge amount of level geometry into video RAM and still run at a nice 60 fps while looking much better than StarMade. Can StarMade be optimized to the point that titans cause no lag? I don't know, but based on what other games are doing (including Minecraft) I would expect that it can be done somehow. If this game can reach that level of optimization, titan lag won't be a thing unless people start building titans that are several sectors in volume.

I still strongly suspect (gut instinct, obviously I haven't seen the game's code and could be totally wrong) there is some major inefficiency in the way the rendering system processes geometry and passes it to the GPU. I also strongly suspect the developers have prioritized new game features over render improvements at this stage, since performance is generally "good-enough" for testing purposes.

From the complaints I see here it's the server that slows down not the clients?

The server isn't doing any rendering, so the net code is the likely culprit.

 

[Panpiper]

From the complaints I see here it's the server that slows down not the clients?

The server isn't doing any rendering, so the net code is the likely culprit.

I have a defensive fleet around my homebase of a couple dozen destroyers. If the fleet is in the same sector floating near to my base, I can get as little as 15 FPS. If I move the fleet so that it is only bordering my homebase sector but still defending it, my FPS goes up to a much more acceptable 55 FPS. All the ships are still close enough to be visible. They are certainly active. Their draw from the server is in both cases the same, but their impact on my own FPS is dramatically different.

It is not just net code.

 

[Jojomo]

I have a defensive fleet around my homebase of a couple dozen destroyers. If the fleet is in the same sector floating near to my base, I can get as little as 15 FPS. If I move the fleet so that it is only bordering my homebase sector but still defending it, my FPS goes up to a much more acceptable 55 FPS. All the ships are still close enough to be visible. They are certainly active. Their draw from the server is in both cases the same, but their impact on my own FPS is dramatically different.

It is not just net code.

I'm simply saying that if it's the servers that are slowing down, rendering isn't the cause. Servers shouldn't be doing any rendering.

 

[Ithirahad]

I have a defensive fleet around my homebase of a couple dozen destroyers. If the fleet is in the same sector floating near to my base, I can get as little as 15 FPS. If I move the fleet so that it is only bordering my homebase sector but still defending it, my FPS goes up to a much more acceptable 55 FPS. All the ships are still close enough to be visible. They are certainly active. Their draw from the server is in both cases the same, but their impact on my own FPS is dramatically different.

It is not just net code.

That FPS lag is CPU load, not your GPU getting bogged down. Client and server both have to evaluate physics, otherwise everything would be super choppy (see Space Engineers) in Multiplayer because the client can do nothing but wait for an answer from the server, which can be delayed for various reasons.

 

[nightrune]

From the complaints I see here it's the server that slows down not the clients?

The server isn't doing any rendering, so the net code is the likely culprit.

Physics is the largest culprit for server lag, and generally you get a lot more clientside lag if you render range is too far.

The physics side is actually a terribly hard problem to solve, Which is why big online games tend to just avoid it. Rts's and Eve solve it by keeping everyone in lock step together.

Starmade appears to be using a hybrid approach of doing it in both places to improve immersion and make sure collisions act how you would expect on the client and then verification on the server since authoritative.

 

[Jojomo]

Physics is the largest culprit for server lag, and generally you get a lot more clientside lag if you render range is too far.

Presumably it's not the actual calculation that's a problem, as single player has no issue? That leaves resulting network traffic as the culprit.

The physics side is actually a terribly hard problem to solve, Which is why big online games tend to just avoid it. Rts's and Eve solve it by keeping everyone in lock step together.

Which physics are the problem? Collisions? Or just accelerations and position updates?

 

[nightrune]

Presumably it's not the actual calculation that's a problem, as single player has no issue? That leaves resulting network traffic as the culprit.

Well latency itself will always be better on single player as its basically a function of how busy the OS is and can shuttle packets from your client to server, and vice versa.

Which physics are the problem? Collisions? Or just accelerations and position updates?

Acceleration and position updates are terribly easy and largely not the issue. Checking for collisions is heavy. Once you've done the bounding box check and there is a a possible collision it becomes a block by block check. There are ways to speed it up that they might be doing but I'm not sure by looking on the outside and looking in. The worst case scenario is a chunk inside a chunk. That means there roughly is 32x32x32x32x32x32 blocks to check for collisions (That math might be a bit high but its close).

 

[Ithirahad]

32x32x32x32x32x32 blocks to check for collisions (That math might be a bit high but its close).

1073741824

...For just one chunk pair

Over... and over...

Oh gods

halp

 

[nightrune]

1073741824

...For just one chunk pair

Over... and over...

Oh gods

halp

Worst case might be closer to 32x32x32x4 since an offset block could occupy the space of 4 others? Thats quite a bit smaller but still a large number. And you wouldn't need to check for both ends.

 

[Malacodor]

It should be way less, since the game only has to check visible blocks.

 

[nightrune]

It should be way less, since the game only has to check visible blocks.

No there is no good way to do that without having redundant lists of blocks. It likely just iterates through the union of two chunks.

 

[Jojomo]

Worst case might be closer to 32x32x32x4 since an offset block could occupy the space of 4 others? Thats quite a bit smaller but still a large number. And you wouldn't need to check for both ends.

Plus on average you'll have only half overlap, and you'll find (assuming there's collision) a collision halfway through and stop. That's 32^3. (I realise you've specifically stated "worst case" not average, but I don't think everyone is registering that)

And as smd3 files structure a ship in 32^3 chunks, I assume for collisions it does pull the relevant chunk and only check occupied blocks.

Anyway, players not connected to a server somewhere don't suffer slowdown due to collision calcs do they? (I am actually asking, because all I've done on SM so far is build)

Assuming the answer to that is no, they don't, then network traffic/synching must be the cause of game "lag".....any decent server should be able to handle collisions at least as well as an unconnected client.