Aux Power & Gigantism

[Malacodor]

I suggested a simple solution to this months ago. Rather than being un-docked when a rail-docker takes terminal damage just make the docked entity remain in place and lose all functionality. The rail-docker becomes intangible but maintains the connection to main ship as dead weight.
Then internal docked entities can still be used with a risk/reward element of 'great when are working but a burden when shot-up'.

I made a similar suggestion, just keep an undocked entity in the host ships's frame of reference with zero relative movement until the game has figured out in which directions that entity could move. Then limit movement to these directions. An internally docked entity without room to move wouldn't move and not cause any further collision checks until surrounding blocks are destroyed. Undocked turrets that could move upwards, but not sideways would slide upwards as if on rails until they could be released safely - instead of trying to move in another direction, getting jammed and cause lots of unnecessary collision checks. Another solution would be to teleport entities, that cause lots of collision checks away from the ship or outright destroy them. I'm pretty sure that this problem has to be addressed sooner or later in one way or the other. I'm afarid the physics engine in its current state won't do it in the long run.

Titans are going to be king forever, just depends on how the titan is designed.

I have some ideas for a titan, that would probably shred fleets into pieces - along with the server.

Ultimately I think what is needed is some sort of maintenance cost, abstracted likely through faction points.

I'd prefer a carrot-and-stick approach, so there also needs to be a carrot. There should be an incentive to spread out fleets across faction space instead of massing them together. Inverted FP, multiple invincible HBs and unloaded combat could help with that. Regarding the stick, I don't think people should be punished for building stuff, just for ship and fleet gigantism. I have an idea, but I need to flesh it out more before I can present it.

 

[Byamarro]

Sorry, but that's entirely your fault.

Yea, treating Starmade as first person RTS with spamming ships will greatly improve performance.

 

[DrTarDIS]

Gigantism isn't a bad thing though. Why are people butthurt that someone who has spent more time(resources required, design, etc) has something "better" ? "performance issues" are something I do follow to a degree(I have them myself), but it is a VERY bad argument for a game in development to be balanced on "existing old" hardware rather than "within 1-2 generations of current hardware." Moore's Law -> Development cycle -> average "existing" hardware should be "future-old hardware" by that point in time.

Now that I've made that stance known...

• I think most collision-check and de-dock maddness could be avoided by simply making active dockers and rails/axis as invulnerable as a ship core. Encourage intelligent building rather than punishing unorthodox methods.
  
• The game supports "non cube" meshes, may as well have a "bake" on complex-unique entities like ships. We don't NEED to load/see "all of a ship" "all of the time" So that would be an important engine optimization. ->only send/render outer mesh past Xm. Update chunks if checksum changes past a significant threshold.
• "pre baked meshes" We have build-mode copy-pasta. I'm unsure if the pasta used from that during construction is or could be used to simplify the majority of load/render operations. I'd like to think that the majority of the LOD work could be taken out of most operations by clustering it around those. I'm thinking chunk damage updates particularly.
  
• adapt to scale by encouraging "shape" and whatnot. make "large thrusters" as a specific block pattern, say a 9^3 tube. Have that pattern specificly have an advantage, and transform it's blocks into a rigid entity in that location: blocks despawn, entire area is registerd as that non-block mesh, etc. Hell, "place capitol component" should be a build helper option

 

[kupu]

it is a VERY bad argument for a game in development to be balanced on "existing old" hardware rather than "within 1-2 generations of current hardware."

This game has an active player base though, it's very important it runs on the player bases machine and not wishfully hoping in 2 years time they will have upgraded to play Starmade again.

As previously noted, this is a sandbox game with currently very few build restrictions. No matter the computing power, you can still grind Starmade to a halt by simply building bigger again. You could have a Titan X and still spam blocks until you sit at 15 fps. ^^

Just a side thought, but in 2 years time i would bet a lot people are still using 970's and i5's to play latest titles and Intel is still using integrated graphics in laptops. The same issue would exist then as it does now.

 

[Malacodor]

Why are people butthurt that someone who has spent more time(resources required, design, etc) has something "better" ?

Very good question. StarMade is a progress-based sandbox game, which is the antithesis of fairness and equality. I don't like unfairness either, but one can't have all at once.

 

[Jasper1991]

Gigantasism is not a problem, never has and never will be (with the exception of performance issues but that is mostly the result of an extremely unoptimised server and client which I am hoping will be improved)

The people who complain about "big ships are overpowered" or "big ships are better in every way then small ships" are (in my experience) people who just got destroyed by one and now instead of putting effort into taking steps to counter/destroy/disable it want them to be nerfed so that they do not have to put any time and effort into destroying them.

• Bigger ships require significantly more resources to spawn in then smaller ships, this is a big one, if a small runabout is destroyed it is easily replaceable, a big ship is not as easily replaced even to an established faction.
  
• Bigger ships require much more time and effort to make them look pleasing to the eye than smaller ships, big ships in order to look pleasing require much more block placement and much more time investment, take something like Vaygr's intruder, looked like shit when it first came out and took them 1 or 2 years to get it to the point where people started saying it looked decent. A smaller fighter takes someone like aceface as little as 20 minutes to make look good while aceface took half a year to wedge his Apocalypse Battleship, and it still is not finished!
  
• Big ships are almost always slower than smaller craft (take note that I used to word *almost*) bigger ships are usually focusing on weapons and shields more than thrust unlike most fighters who do the opposite, the biggest weakness a big ship has is its speed, the biggest advantage a smaller craft has is its speed.
• One of the easiest ways to counter big ships for little expense is to spam lots of small drones, you do not even have to leave your homebase! just send them to where your scouts reported the big ship, and they can very easily destroy the big ship, they might even lag the big ship pilot enough that you can attack the big ship while its not piloted from long range!
• Bigger ships are impossible to cloak and difficult to radar jam while smaller ships are the opposite, I should not have to explain this
• Smaller ships have better velocity, get behind a big ship and without swarms they can not hit you at all!

The argument that big ships are better than small ships is flawed, in my experience "gigantasism nerf threads" are people who list the advantages a big ship has and avoid the large amount of disadvantages they have. Big ships have problems as well, and small ships can also easily counter a big ship with some of the methods mentioned above.

If you are stupid stare down the barrel of a titans largest gun in a small runabout, you deserve to be destroyed.

 

[Malacodor]

Gigantasism is not a problem, never has and never will be

It was a problem before the nerfs were put in place.

 

[Lukwan]

Just a reminder...

This thread is not a debate about Titan's Vs Fighters or fairness in SM. There are more threads on the dock that feature this debate than I can list here so please, just do a search rather than hijack. If every thread contained every perspective we might just as well have one giant thread for it all so no one could navigate the different subjects.

This is not about a being 'butt-hurt' (a thoughtless and insensitive term).
This has nothing to do with mismatched battles.
No one has said that Titans should be removed or dis-allowed.

Can anyone make a cogent argument for having no Caps at all to limit the growth of ships & fleets? Unless you can convince me that SM would remain stable and playable without some kind of restrain on growth this discussion remains relevant.

 

[Scypio]

Can anyone make a cogent argument for having no Caps at all to limit the growth of ships & fleets? Unless you can convince me that SM would remain stable and playable without some kind of restrain on growth this discussion remains relevant.

Even without the power cap huge titans would stay rare as they need a lot of work to put on. I do not even count on the mining time as it will be something done by unloaded fleets in the future. Also, do not forget that the ship will be overheating at 50% of it's mass destoyed while a fleet will fight until the last ship is at 50%, wich is more efficient. I do not say that everyones wouldn't use titans but curently caps or not it isn't a problem for this size of ships.
By the way i will quote malacodor on the previous page.

Aux reactors give a linear power growth after the soft cap, which still allows for arbitrarily huge ships. They punish ships with a few aux reactor groups almost as much as ships with lots of them, maybe even more, since bigger ships can protect aux reactors better. Replacing the soft-cap with a logarithmic power curve would have punished really big ships significantly more than not so big ships.

Funny thing is that with the current system it's ships playing around the soft cap or huge titans. If you don't get at least 50 layers of something to protect them then you'll be destoyed inside by the reactors exploding. I see some ways to use them on battlecruisers but it start to use a lot of brainstorming while huge titans are just so huge that they protect with their size aux power reactors.

 

[Malacodor]

Also, do not forget that the ship will be overheating at 50% of it's mass destoyed while a fleet will fight until the last ship is at 50%, wich is more efficient.

Actually a titan will overheat far sooner, since bigger entities receive additional SHP damage.

 

[Jasper1991]

Can anyone make a cogent argument for having no Caps at all to limit the growth of ships & fleets? Unless you can convince me that SM would remain stable and playable without some kind of restrain on growth this discussion remains relevant.

As requested:

Why?: Gigantic ships cause a performance loss for anyone not running the latest hardware. They are more prone to causing lag and a disproportionate draw on the server's resources which affect everyone playing on that server. They take a huge amount of time to make and often never get used because they are 'too valuable to risk' or they lord over a server, crushing smaller ships in mismatched Noob-stomps so everyone Turtles up. For a variety of reasons Gigantism can negatively impacts the 'Fun' potential in MP play. (in SP you can go to town...this becomes a non-issue) If we did not limit ship size people would break the game with giant ships...period.

1. Performance loss in this game is not the fault of the hardware being used, the game itself it extremely unoptimised as the devs are focused on spewing out features and then (hopefully) will start fixing things once all the gameplay mechanics are in place, Arkazan when he ran Elwyn Infinity did beta stress tests using very large (keep in mind this was back when docked reactors and shield supplies were still a thing) stations and ships, he also tested with a fucktonnes of drones, he found that the server itself preformed fine under the pressure he put on it, however the client lagged like a fucktonne (both the client and the server were running on his box), he ran tests with SERVER GRADE HARDWARE (not sure of exact specs given the time that has passed since he basically said "fuck this game") and the client still lagged, hardware is not the cause of "titan lag". The devs are capable of fixing this, however I am going to assume they are following the standard Software release life cycle - Wikipedia then they are going to wait until beta to do that.
   
2. While you are correct in that it takes a huge amount of resources and time to spawn in a titan, the problem is not that titans are "too valuable to risk" its more "we have no reason to undock because there is too much risk and not enough reward to doing it" Titans are not the problem, PVP mechanics in general are. I will use the Vaygr as an example because I am most familiar with it, we frequently show up at our enemies homebases and encourage them to undock, 99% of the time they refuse and we end up leaving out of boredom, they do not undock because they do not want to risk loosing any ship and even if they win they do not gain much out of it, and why would you undock when you can just sit in your homebase, afterall its not like the enemy can do damage and force you to undock...
3. As for "mismatched noob stomps" as I mentioned in my previous response:
   

   =
   

   • Big ships are almost always slower than smaller craft (take note that I used to word *almost*) bigger ships are usually focusing on weapons and shields more than thrust unlike most fighters who do the opposite, the biggest weakness a big ship has is its speed, the biggest advantage a smaller craft has is its speed.
   • One of the easiest ways to counter big ships for little expense is to spam lots of small drones, you do not even have to leave your homebase! just send them to where your scouts reported the big ship, and they can very easily destroy the big ship, they might even lag the big ship pilot enough that you can attack the big ship while its not piloted from long range!
   • Bigger ships are impossible to cloak and difficult to radar jam while smaller ships are the opposite, I should not have to explain this
   • Smaller ships have better velocity, get behind a big ship and without swarms they can not hit you at all!

   
   The argument that big ships are better than small ships is flawed, in my experience "gigantasism nerf threads" are people who list the advantages a big ship has and avoid the large amount of disadvantages they have. Big ships have problems as well, and small ships can also easily counter a big ship with some of the methods mentioned above.
   
   If you are stupid stare down the barrel of a titans largest gun in a small runabout, you deserve to be destroyed.

   TL: DR if you are going to face a big ship, there are plenty of ways to do so in a smaller ship, if you are stupid enough to stare down a titans main weapon then you are doing it wrong, and that is not mismatched, you are just not using your ships assets to its advantages (hint: SPEEEEEED)
4. So no, big ships should never be limited, they are balanced and there are plenty of ways to counter it without using gigantasism yourself.

 

[MrFURB]

Can anyone make a cogent argument for having no Caps at all to limit the growth of ships & fleets? Unless you can convince me that SM would remain stable and playable without some kind of restrain on growth this discussion remains relevant.

Having some sort of limit to the total mass or number of ships capable of being efficiently controlled by one person would definitely save a ton of performance (moreso after unloaded sector mining becomes a thing, woohoo exponential battleminer growth!) but you would run into issues in singleplayer with not being able to efficiently run your empire.

So what could we base an arbitrary 'population cap' on if not player count?
Faction points? In normal faction configs that ties right back into player count. Inverse faction configs would mean that the size of a faction's navy depends on the amount of territory controlled. There may be some potential in this option.

Maybe needing NPC crew for your unmanned vessels to function well? There could be all sorts of limitations to the number of NPC crewmen that can be attained.

Maybe a new resource, like the often mentioned 'fuel'?

 

[nightrune]

This is a lot more subtle of a program then you would purport it as.

Performance loss in this game is not the fault of the hardware being used, the game itself it extremely unoptimised as the devs are focused on spewing out features and then (hopefully) will start fixing things once all the gameplay mechanics are in place, Arkazan when he ran Elwyn Infinity did beta stress tests using very large (keep in mind this was back when docked reactors and shield supplies were still a thing) stations and ships, he also tested with a fucktonnes of drones, he found that the server itself preformed fine under the pressure he put on it, however the client lagged like a fucktonne (both the client and the server were running on his box)

Server grade hardware usually means that its slower and will last longer. Things like ECC ram and radiation testing are done to ensure a 5 to 10 year longevity for "Server Grade." Most of the xeons that I've seen tend to run slower even though they have things like dual processors. Games generally don't lend themselves parallelization well. I've seen schine attempt to make things parallel as much as then can without significant code complication. This is a really good plan since too much code complexity early on means less flexible later on when you need to be.

he ran tests with SERVER GRADE HARDWARE (not sure of exact specs given the time that has passed since he basically said "fuck this game") and the client still lagged, hardware is not the cause of "titan lag".

After quite a few talks with schema, the problem is actually hardware. The GPU is still one of the the slowest things in the chain. The move to chunk32 was great since there were less draw calls. Generating the mesh is actually fairly fast. The next problem is the number of triangles in a voxel game is pretty high. To keep the amount of VRAM low you use tiling and texture sheets to pull from, so for every visible face you have 2 triangles and the UV coordinates for those. Clients wouldn't lag as bad if they would just turn down the number of chunks rendered. They don't do this cause they need to see what's hitting them.

The devs are capable of fixing this, however I am going to assume they are following the standard Software release life cycle - Wikipedia then they are going to wait until beta to do that.

There are ways to fix it but they are large features in themselves actually. The biggest feature they'll need to scale out is Chunk/Block LoD This has potential huge framerate gains if the algorithm itself isn't that painful, but its not an easy problem to LoD user generated data.

 

[godmars]

Having some sort of limit to the total mass or number of ships capable of being efficiently controlled by one person would definitely save a ton of performance (moreso after unloaded sector mining becomes a thing, woohoo exponential battleminer growth!) but you would run into issues in singleplayer with not being able to efficiently run your empire.

So what could we base an arbitrary 'population cap' on if not player count?
Faction points? In normal faction configs that ties right back into player count. Inverse faction configs would mean that the size of a faction's navy depends on the amount of territory controlled. There may be some potential in this option.

Maybe needing NPC crew for your unmanned vessels to function well? There could be all sorts of limitations to the number of NPC crewmen that can be attained.

Maybe a new resource, like the often mentioned 'fuel'?

why not this. just limit the number of ships a lone player can field individually and give players a mass limit so they can't immediately hop in a titan and fly it by themselves like some kind of gigantic fighter. If its SP NPCs can be used instead, logistics officers or something

 

[Jasper1991]

This is a lot more subtle of a program then you would purport it as.


Server grade hardware usually means that its slower and will last longer. Things like ECC ram and radiation testing are done to ensure a 5 to 10 year longevity for "Server Grade." Most of the xeons that I've seen tend to run slower even though they have things like dual processors. Games generally don't lend themselves parallelization well. I've seen schine attempt to make things parallel as much as then can without significant code complication. This is a really good plan since too much code complexity early on means less flexible later on when you need to be.


After quite a few talks with schema, the problem is actually hardware. The GPU is still one of the the slowest things in the chain. The move to chunk32 was great since there were less draw calls. Generating the mesh is actually fairly fast. The next problem is the number of triangles in a voxel game is pretty high. To keep the amount of VRAM low you use tiling and texture sheets to pull from, so for every visible face you have 2 triangles and the UV coordinates for those. Clients wouldn't lag as bad if they would just turn down the number of chunks rendered. They don't do this cause they need to see what's hitting them.


There are ways to fix it but they are large features in themselves actually. The biggest feature they'll need to scale out is Chunk/Block LoD This has potential huge framerate gains of the algorithm itself isn't that painful, but its not an easy problem to LoD user generated data.

HeartUponSleeve did suggest something to combat this kind of issue where lots of voxels n shit are loaded ([ANTI LAG SUGGESTION] Generate Sprites for Entities at long distances) using an spirtes instead of voxels would help imo

 

[Malacodor]

I'd prefer a carrot-and-stick approach, so there also needs to be a carrot. There should be an incentive to spread out fleets across faction space instead of massing them together. Inverted FP, multiple invincible HBs and unloaded combat could help with that. Regarding the stick, I don't think people should be punished for building stuff, just for ship and fleet gigantism. I have an idea, but I need to flesh it out more before I can present it.

Done.

 

[Nauvran]

The next problem is the number of triangles in a voxel game is pretty high. To keep the amount of VRAM low you use tiling and texture sheets to pull from, so for every visible face you have 2 triangles and the UV coordinates for those. Clients wouldn't lag as bad if they would just turn down the number of chunks rendered. They don't do this cause they need to see what's hitting them.

Bit off topic from the general thread but why are we using triangles when game models tend to avoid using triangles? With what I've learned with 3D modelling so far everything should be kept as squares unless on flat surfaces, should in theory also keep the amount of polys down since we are basically doubling them with triangles?
Not complete sure so thats why Im asking.

 

[StormWing0]

Bit off topic from the general thread but why are we using triangles when game models tend to avoid using triangles? With what I've learned with 3D modelling so far everything should be kept as squares unless on flat surfaces, should in theory also keep the amount of polys down since we are basically doubling them with triangles?
Not complete sure so thats why Im asking.

Hint 1 square = 4 triangles at worst, 2 at best.

 

[kupu]

Bit off topic from the general thread but why are we using triangles when game models tend to avoid using triangles?

IIRC a gpu is built to read the simplest primitives (triangles). From what i've read meshes are processed as tri's in most circumstances because the math is quicker / simpler. A triangle is inherently planar, where as a quad might not be.

However, people advocate modelling in quads as it usually provides a more efficient workflow, helps avoid smoothing / deformation errors and allow certain editors to use sculpting tools with less issue further along in the pipeline.

...i think, anyway. ^^'

 

[nightrune]

IIRC a gpu is built to read the simplest primitives (triangles). From what i've read meshes are processed as tri's in most circumstances because the math is quicker / simpler. A triangle is inherently planar, where as a quad might not be.

However, people advocate modelling in quads as it usually provides a more efficient workflow, helps avoid smoothing / deformation errors and allow certain editors to use sculpting tools with less issue further along in the pipeline.

...i think, anyway. ^^'

Yeah pretty much, What you send to the GPU is in tris. If you model in quads it gets converted at tris to the lower layer. That's what can make GPUs so powerful. At some point you have a vector of three floats and a couple of UV coordinates for every point, That's 6 3d vectors and 6 2d vectors for every quad. Schine could be doing a bit more in the GPU but it still sounds like the mesh is built on the CPU like other voxel games. The sprite approach or an LoD system is the best possible system, based on what I know, to really scale the combat/gameplay. Now the other part of this is that even with LoD the server still has to load all of the block data of the structure and sync it with the client. So really, the client IS the current actual bottleneck, and the main thread of the server. It'll probably stay that way until untenable or the other features are in.
[doublepost=1477775807,1477775631][/doublepost]

why not this. just limit the number of ships a lone player can field individually and give players a mass limit so they can't immediately hop in a titan and fly it by themselves like some kind of gigantic fighter. If its SP NPCs can be used instead, logistics officers or something

Cause that's actually hard in a sandbox type game, and it limits how much you can grow in a game. Not something you really want for a space sandbox. A space sandbox that is supposed to feel like you can start from nothing and build an empire.