About the System Manager and understanding it for epic success

Heya, a True Story about TL;DR
i wanted to make a guide for the System Manager, any ideas and help very appreciated, will add things other find out or I in the long run. For reasons I will capitalize certain words.
Things I'm going to cover so far:

• Map Sizes, performance, comparison to "2D" RTS Maps
• Mass
• Possible Map Scenarios e.g. (Settings to force different Strategies, example see pics below)

So first about Mass, if you want to make a planet and keep it's Mass at the same ratio all the templates have,
you have to multiply the Radius by 5 and deduct 1000 so an example:

let's say we want a Stellar Object with a Radius of 666 we do

Code:

666*5-1000=x
x=2330

easy as that, but leaves us with the problem that an Object with 200 Radius would have 0 Mass,
since that can't be we have to arbitrarily chose fitting Mass below 1000.
If you don't use the Slider you can input it, this works for most editable values and is awesome.
I chose these for asteroids (R adius M ***)

Code:

50R=100M
70R=120M
125R=200M
150R=500M (it was a Metal Planet/Satellite, so I chose to give it more Mass)
200R=400M
300R=700M
350R=1000M
400R=1000M (original Value for a 400 Radius Object)

I could have done better, but I was unable to map Spherical Volume to the in game Mass System.
When you create tiny Stellar Objects, be aware that below a Radius of 100 it starts to glitch and not every
Seed will work properly with every Radius, but for example really tiny Asteroids/Moons (R=50-70)
look super awesome if you get a Seed that works well, imho a lot better than the larger cousins.

Important to note: this makes creating small Asteroid Belts feasible and performant when you want to play or create themed Maps, especially nice is that NO Teleporters fit on them. (Tho I forgot if that's true for 70R, on 125R upwards you can easily bild Teleporters (tho there might be ways to prevent that
with certain Settings) they're all halleyable.

About halleying: with R <250 it needs 3 halleys, from 250 to 349 they need 25 Halleys,
with R =>350 they're not halleyable anymore.
If an Object can be halleyed solely depends on the Radius, NOT the Mass.

Since which Objects can circle/attract which Objects depend on Mass often it's easier to place tiny ones first, alternatively you can drag them in a way (circle is shown as red for unplaceable) where the
Object jumps to the first possible place.

behind it you see the "Tiny Tiny Satellite" with R=150 and M=400,
it looks cute when you place a portal on it.



On to RTS Maps, how they compare to Planetary Annihilation, what's with all the RAM, why do I need it?
What's a good Planet Size, etc.

So from <random RTS> we are used to flat square minimaps (yolo, I know there's other RTS too, swag)
In some we see things like this: small 200x200, medium 225x225, large 255x255
which everytime is a size increase of about 21%, this example is taken from an RTS where a lot has to be emulated (plants growing, spreading, naturally dying, mobs, enemies, physics, catastrophes, weather, etc)
so they are very conservative with the Map Size Increase, it's a good way to go.

Other RTS just double the Surface Area everytime they increment to the next Map Size:
256x256=65536
double that'd be
~362x362
double again and we have
~512x512
i think it's the most common variant, anyhow there's also the variant where they quadruple the Map Size,
this is due to 256x256 being a quarter of 512x512 being a quarter of 1024x1024, being a quarter of 2048x2048 etc.

Obviously these map sizes are TINY for modern computers in most games since adressing/bitrange has increased so much, but bear with me
here a few visualizations in order of the examples above:

this is the 200x200>225x225>255x255 variant, it's a minor increase in Map Size

256x256>362x362>512x512>etc variant
Above is imho the way to go when increasing Map Sizes for Standard, the surface Area in the smallest Map is 65k, the next step 130k, the one after 260k and so on.
In Planetary Annihilation Orange would be an Object with a Radius of 72, blue would have a Radius of 102, Black a Radius of 144, the next larger iteration 203 then 288 > 407 > 576 > 814 >1152 etc


This is the least used and I guessed most lazy variant.

Anyway based on the above I came up with an Arbitrary Classification of Stellar Objects and their Size
(I really don't like the in game variant with Class 1 - 2 - 3 -4 etc, it might be applicable in the finished game tho, performance and optimization wise as well as stuff)

But not everyone has a big rig with 8 steaming CPUs, rockin GPU and 16GB of Ram waiting for the rest@2166mhz

so it would be nice to know how many Stellar Objects of what Size I can fit onto a Map without breaking everything,
or what if I'm from Mother Russia or some other place where not everyone has the best rig and I want to have fun with Mass Projectiles (halleying) too.

From that Classification, some Testing, the Data and a little time people can easily find out
what kind of Universe their PC can easily handle while a fight with thousands of units is going on.

The Sizes are arbitrarily chosen, tho they reflect the Surface Area doubling (I rounded for feel, did the Meth afterwards) mil means in million Vogontri

Code:

Class       Prefix        Radius      SurfaceArea  Halleyable TeleportPossible          PerformanceHit
   Z           -            ~50        ~0,03mil          yes         no            neglicible (max=testing)
   X           -            >70        ~0,06mil          yes      sometimes        neglicible (max=testing)
   A          tiny          >200       ~0,52mil          yes         yes                    tiny
   B          mini          >290       ~1,05mil          yes         yes                    minor
   C          small         >410       ~2,10mil          no          yes                    little
   D          medium        >580       ~4,22mil          no          yes                   noticable
   E          large         >820       ~8,44mil          no          yes              absolutely, quite some
   F         * large        >1160      ~17,0mil          no          yes         one of these, ideally only Object
   G         gigantic       >1630       ~33,3mil         no          yes           haven't tried yet, LET ME PLS

So I'll try to put it in other terms, since Orange (256x256) has a Radius 72 in terms of comparable Map Area (see above), for modern computers these type of map sizes are easy to handle and we've seen that in Spore a long time ago. So basically it's fine to add a lot of these, for beauty or strategic reasons.
Objects with a Radius of 100-140 basically are fine too, R100 has 0,125mil Surface and R140 has 0,246.

A Test
with which you could try to find out what the limits of your righ are, would consist out of building a System that has a certain Surface Area (on one Object or shared among a few)

let's say
You picked a "Map" that has a total of 50million squareVorgontri and your rig handles this fine, you had 3 Planets, one 17mil, the other 8,4mil, as well as a 4,2mil and two 2,1mil (this is a very unrealistic scenario for most people, seriously, don't have such a large map yet until they could do further optimization and what devs do all day, beside, with cruel intent, not letting me test experimental map sizes) :3

with that Knowledge
comes the chance to optimize the "Map" for fun, performance, themes/scenarios (like no rush, castle defense, 1 hour eco phase/no war, etc)

so let's say we want to have a dozen possible Mass Projectiles, because we're crazy, but we also don't want anyone to get there easily with a teleporter and just spam halleys, so we pick 12 Class Z Asteroids, they will do the job and only have a Surface Area of 0,36mil, which is only like ~70% of a tiny Object and a tiny fraction of whatever is running well for most people.

you get the ghist?
If 12mil Surface Area runs smoothly for you, you can put a lot of smalle Objects into the Universe, but only a few big ones.
So we have 12 Zs now, need 3 Homeworlds and a small starting Planet (coz there's peace for an hour!)
The Homeworlds shouldn't be too large (like the prebuilt template Earth, they clog up Area)
So we go for 3 Class C @ R500 or a little lower depending on stuff, that "costs us" about ~9mil
the rest we happily spam with Class B or A Planets/Moons or X/Z Asteroids/Mass Projectiles

obviously there's a little performance loss over a lot of Stellar Bodies, but with the engine it seems very neglicible because it handles a lot of them as performant as few gigantic for me.


Such Great Game

Much Wow

p.s. I'll probably add graphs later, did them by hand and am too lazy to use wolfram.
Also I'm hoping for some ideas conversation/brainstorming for a good system to put in a faq.
I think small Mass Objects should be drawn in by large Mass Objects
Question to People that know, commonly known as Them
Why is the Mass to Radius relation R*5M-1000=x ?

wow.....

Edit Planet
Seed - is the number from which the map generator draws it's 'random numbers' heavy impact
Radius - explained above
Height Range - affects mountain placement (does it affect elevation/curvature?)
Biome Scale - no clue what it does, possibly how much nature there'll be
Water Height - basically affects ocean depth/land coverage, but also reduces Height Range in a way (reduces mountain placement, setting this to 0 has interesting effects and takes longer to load.)
Temperature = biome availability (100=no frozen poles, 0=only ice)

Possible Scenario
Setting Water Height to 0 will result in a map with a lot of mountains, pathways, mazes, this forces the player to adapt a lot. Good for people who don't want the good old send mass production to XY games, but more use of aircrafts and defenses, these maps increase the strategical options and require more strategy.
This doesn't work for Lava Planets, Moons and Metal Planets.
Tho 0 Water Height on a Lava Planet makes it look a lot more like Mars, which is really nice.

hold on... got a nosebleed

Good lord...

Thanks for such a work. I wonder if wouldn't be nice having the Default System in-game being inspired by the data you've here exposed.

I'd be surprised if even the devs didn't learn something form this thread x'D

*Copied down to note sheet*
Thanks a lot for doing all the this, going to start using this to create maps

Damnit xd i had to learn all this the hard way. Also, yes biome scale impacts how much obstacles like rocks, icestuff glachers and other stuff to annoy land units and buildings. Hally limits are 249 for 3 hallys and 349 for 25 hallys. And you can set the scale of the planet lower then 200 when manually inputted. Not advicable for a serious match, and dont go lower then 50 ever XD

Ah sweet, gonna edit this now, so with heightscale and biomescale you can impact the placing of obstacles?

Tho I like the 50-70 ones even for a serious match, imagine 3 big planets and the rest tiny planets that can't be accessed by teleporter but can still be halleyed or whatever other scenario.

https://forums.uberent.com/threads/facts-about-planets.53451/

That's my tread, it's very similar, but it got buried by newer threads.

Make graph with planet surface vs radius (you know 4*pi*r*r ). Mark planets with sizes 100..150.200 etc. Numbers in list say less than nice graph. You can also mark lines with numbers of halleys needed etc, put memory requirements as additional scale. Very important is to visualize that surface and memory demand is not linear with increasing radius.

Also keep in mind that bigger surface means more metal spots, and that makes economy bigger, so players get more units faster. So some data about biodome, size of planet and average number of metal spots would be helpful. No matter how good on optimization is Uber, there is limit how much one can optimize, and number of units grows expotentially in time. So even if Uber really tries, it may be difference of 5min later or earlier when game drops to crawl.

I'm going to incorporate/add the ideas from nawrot and the data you collected zweistein many thanks!
tho today i'm to fatigued ^^

also they fixed the mexes don't spawn on small bodies, at least for me they did

I like the idea, I guess the real question that needs to be answered by a Dev would be if planets are primarily rendered by Ram or if its a combination of the computer processor/Video Ram.

Otherwise this would be useful for low end computers. I know Max Payne 3 in the graphics menu tells you how much Vram your computer needs to run Shadows at low/medium/high. I wonder if its easy for developers to give that information or not.