Hypothetical discussion about a planet idea, can you find an issue ?

[Digi]

EDIT: Please read: The only reason why I posted this in the StarMade forums is because you guys discussed this topic alot, but I didn't see anything about this idea, I don't care if this gets added in the game or not, I'm only curious about why this won't work in a practical application, not necesarily in StarMade.



Let's say hypothetically that StarMade would have much larger planets and supports separate flat maps that support looping (you go in on one side and you get out of the other in a seamless way, I don't know how it works, but the video game 1NSANE did it just fine on multiplayer).



The idea that I want to throw out there is that planets in space are just a huge 3D fake sphere that would act as a teleporter to the flat looped map versions of the planet.

So when you approach a planet by ship you'll see some flame effects then you wake up in the planet relative to your entry point.

Some nice shaders to make the planet seem spherical or fog limitation of distance, although it is actually flat and would allow nice building and easy gravity.

Additionally entering a planet as a pilot would burn you alive :}



So.... let's say this would be implemented into StarMade, what would the problems of this technique be ? I'm just curious about this, I know that alot of discussion was made about how planets should be but I didn't really see this method, separate maps.



Also, seeing the planet from space would be a top-view render of the map without dynamic entities... and shooting it from space would also carry the projectile in the relative spot, should be quite easy to program... should, but like I said, I really want to know what problems would an practical application of this theory arise.

 

[EpicFailLord123]

Uhhhh

1. Your profile picture offends me.

2. We have been discussing this for weeks now, and the answer is no.

 

[Digi]

Sorry but you haven\'t actually read the thread and provided no useful information, read it and then explain why this wouldn\'t be appliable... also note that I\'m not actually suggesting this, I just want to know why would this method fail in a real application.

 

[ltmauve]

THEY DISCUSSED THIS ON THE FAQ AND ARE DOING OREO PLANETS THANK YOU AND GOOD NIGHT.

 

[Digi]

I KNOW ! READ THE THREAD.



Thank you :P

 

[PlagueDoctor42]

To me, the main problem is that this would ruin the \"Seamless\"-ness that schema would like the game to have, and he has already decided to have oreo cookie style planets

That\'s really all I personally got.

Good day to you sir! sorry the other residents are being..less then helpful.

 

[therimmer96]

As far as I am aware, the problem is that schema wants the game to be 100% seamless, no loading screens after the initial logging, no matter how fancy it looks, even with flames. Also, what would happen to current planets? schema doesnt like just forcing resets of the universe/sectors.

You also have to think about performance. The game already struggles with 1 universe, and you want to implement more, with people switching between them in ships. That would put alot of strain on the server, and single player is already bad, this would cripple it.

 

[Digi]

It would be realistically no diferent than it currently is... there\'s a 3D sphere already that disappears and then blocks load... so, with this style the transition would also be more transparent because of the effects of fire and clouds and whatever.



Not sure if I explained it exacly how I\'m imaginating it... it\'s more close to reality than anything honestly, with minimal complexity.



But anyway, I\'m trying to find a more technical reason for this not being a good idea, I understand that Schema does what he wants in his game, I have no problem with that, I\'m just curious if this method would practically work, that is all.



PS: Thanks for an actual answer :P

 

[Digi]

Yes, well, it wouldn\'t be a loading screen, the fullscreen effects would act like \"loading screens\" but it\'s no diferent than waiting for the blocks to load as it is currently.



Since current planets are already flat they would be relatively easy to convert into flat individual maps... but the looping technique needs to be added, like I said, I don\'t know how that works, but if it worked flawlessly in an old game, it should work to a degree, preserving everything in the planet.



Also, something that I didn\'t say, inside the planet map thingie, digging far enough down would hit either hot indestructible lava (core) or bedrock... I think a core would be more awesome and would have a huge amount of health, shooting it enough would trigger the planet to explode or something :P



About performance, I belive multiple maps would actually help performance, since there\'s an easier way for servers and clients to know what to calculate in relation to other stuff, they\'re basically isolated from eachother. This is still not a game breaking thing since performance is theoretical until actually done and optimized.



EDIT:
Also, something I realized... the planet maps would need to calculate if a ship would fit inside,.. those would add RAM usage and some CPU usage but it wouldn\'t be that severe.



However, planets should be alot bigger for this to work, but since this is a hypothetical discussion, let\'s assume all of these details are true.



Also, maybe make the flame effects a minimum amount of time so that it avoids spamming in/out of the planet, 3-5 seconds or so, nothing major =)

 

[NuclearLemons]

i can say no more



You can say its hypothetical but surley EVERY suggestion is, thats why its a suggestion.

If you choose to read the last 126 pages of suggestions you may realise that this is nothing new so stop reposting,



Also a second world would not benifit anwhere on server memory because if there was someone on the world and people on planets then the poor RAM is having to calculate everything the game does several times over, even worse what happens when a big ship hits a planet,



Also loading like chunks would not work as it still would not be fluid afterall depending on server speed it could take seconds or minutes(which is bad)

 

[Planr]

Digi, do you even like, bother to read the news updates? Schema himself explained why this is not a good solution.

 

[Digi]

But I don\'t care if this doesn\'t get added to the game, that\'s why this is not in suggestions.

I posted this in the StarMade forum just because you guys discussed this alot, but I never seen this method being discussed.

I\'m only interested in the issues with this idea, nothing more.



There\'s nothing much new added... the planet itself is removed from space and moved into separate world... this can only benefit view calculations and in turn add some extra calculations when trasitioning, therefore no actual performance hit.



Doesn\'t the current space in StarMade load like chunks anyway ? They\'re named sectors but the space is still partitioned in big chunks that are progresively loaded, since there\'s no way the server can hold the entire space in memory.

A diferent world as a planet wouldn\'t be any diferent since it replaces chunks from space and makes them a separate world so that making spheres is not required.

 

[Digi]

This exact idea ? I missed that \'news\' apparently... since most news were fixes and stuff, only one was about planets and those were with planets physically in space, not as separate worlds as far as I saw... and you can\'t really blame me for missing posts in this forum system.

So, please tell me what are the technical and logical problems with this, I don\'t care if this doesn\'t get added, as I said before.

 

[ltmauve]

You never saw this being discussed? Really? This has been brought up countless times.

 

[Calbiri]

We\'d like to avoid any in game loading screens (this includes cover ups such as an \'atmospheric entry effect\')

Spacial distortions can get pretty severe moving ships/weapons fire between a spherical border (the fake planet orb) and a flat grid layout (your desired world). This is most readily seen by looking at lattitude/ longitude lines on a globe.

Ship size can become an issue based on atmospheric depth on the flat world (which imposes a hard limit on ship size, = against our design goal of no hard limits)
Also imposes a height limit on structures (nobody could build a space elevator)

 

[Planr]

What calbiri said ^^

and here is what schema said about it

http://star-made.org/content/starmade-dev-update-why-spherical-planets-dont-fit-block-world

 

[Mariux]

+1

 

[Digi]

Again... loading still occurs in the current game, after you get close enough to a planet you must wait for the blocks to load.

The atmospheric entry effect wouldn\'t really be a cover up, you could do it instantly if the server pre-loads worlds when someone is near them, which again, is no diferent than it is now... the only thing this idea brings diferent is a flat plane in 3D world without it looking weird from space.

But this:


Spacial distortions can get pretty severe moving ships/weapons fire between a spherical border (the fake planet orb) and a flat grid layout (your desired world). This is most readily seen by looking at lattitude/ longitude lines on a globe.


Looks more like a valid argument, I\'m not really sure what distortions you mean when it comes to moving ships or shooting through the border, can you explain that more ?

 

[Digi]

I still don\'t see schema saying anything about this idea in particular, link me to the exact comment, since the news itself is about planets in the actual space world, not as separate worlds.

 

[ltmauve]

Near the poles, there will be distortion. On the planet there is still the same amount of longitudal space as the equator, but there will be much less space on a sphere at the poles than the equator. Imagine trying to shoot a turret near the poles. If your shots are off by 10m at 85 degrees latitiude, they will be 110m off when they hit the planet.

Or in reverse, suppose you have destroyers near the poles and you leave atmosphere. They will become much closer together and cause a bunch of collision issues.