If you have Earth-sized planets, you might not be able to find/fight other players in a reasonable manner, and you might have way too many resources.
1KM diameter or so might be fine. And one gigantic planet near the core of each galaxy might be cool too.
Others would probably have more ideas why we don't want planets to be 10KM wide.
I never did like the idea of full-scale planets in Starmade (I wasn't the one who suggested that), nor the idea of people mining them from orbit for this reason. I don't think orbital mining will be something that carries into the final game. There will probably be a better and more enjoyable way to mine planets and orbital salvage beam mining may not work. If the ideas I have outlined here were implemented, planets wouldn't be quite the full size of a sector because there would still need to be room for the atmosphere and planetary space above it. I would imagine they would spawn at different sizes and probably still be configurable, although making them too tiny might feel a little strange because the surface feels flat, and you wouldn't expect it to be. I don't think I'd set them to less than 1 km diameter.
Ah sorry to burst your bubble but I totally just talked to Scheine about this, here's the transcript:
Me: So, Scheine, can you do it?
Scheine: Who the hell is Scheine? Can I do what?
Me: Thanks, that's what I thought!
So it's impossible, just give up and never discuss it again. By the way I've played this game for like, hours, so I am an absolute authority on all matters involving it.
WE NEED BIGGER PLANETS!!!!! I only work on a 1:1 scale and that makes even frigates at 120m so big they can't land on a planet and a destroyer at 230m way bigger than a planet and a cruiser at 450m is just huge it isn't just planets but the entire game world that needs to be made bigger
Wow, this method looks fine to me. In StarMade there are already worse planet transitions (Planets change color from certain angles, the dodecahedrons you see from outside the planet sector have nothing to do with planet terrain...) so something like that would be great.
WE NEED BIGGER PLANETS!!!!! I only work on a 1:1 scale and that makes even frigates at 120m so big they can't land on a planet and a destroyer at 230m way bigger than a planet and a cruiser at 450m is just huge it isn't just planets but the entire game world that needs to be made bigger
yup, which is why my sector sizes on my server are 20km across (using the 10k in server.cfg), I really wouldn't mind seeing 1k - 5k diameter planets using a new method.....ya know, something to start with and see how things go. If all is great, then have the option in the server.cfg to go up to 10k+.
Wow, this method looks fine to me. In StarMade there are already worse planet transitions (Planets change color from certain angles, the dodecahedrons you see from outside the planet sector have nothing to do with planet terrain...) so something like that would be great.
That game made the same mistake as Schema's first attempt at round planets: using the squashed cube, which is a terrible idea. The difference is the Seed of Andromeda team is more persistent and is trying to force a geometric impossibility to work. They're doing surprisingly well though. They think they can get away with it because it only severely affects one spot on a full-scale planet, which I think is dumb. If they used my parallelogram map instead, the geometric impossibilities would be eliminated and replaced by a slight size distortion as triangles approximate hemispheres.
The way I've suggested doing this in starmade would take the distortion out of the equation when blocks are loaded by making the distortion relative, i.e. bending space client-side relative to a ship's distance from the planet. Schema could substitute an abrupt transition if he likes the idea of the parallelogram map, but not space bending. It would still be less immersion-breaking than a loading screen and would simply act like a sector transition. In any case, the whole relativity transition theory needs to be refined a bit more to be usable.
EDIT: This is an old post before I discovered a flaw in the idea referred to here. There are still better ways to handle it than Seed of Andromeda does.
That game made the same mistake as Schema's first attempt at round planets: using the squashed cube, which is a terrible idea. The difference is the Seed of Andromeda team is more persistent and is trying to force a geometric impossibility to work. They're doing surprisingly well though. They think they can get away with it because it only severely affects one spot on a full-scale planet, which I think is dumb. If they used my parallelogram map instead, the geometric impossibilities would be eliminated and replaced by a slight size distortion as triangles approximate hemispheres.
The way I've suggested doing this in starmade would take the distortion out of the equation when blocks are loaded by making the distortion relative, i.e. bending space client-side relative to a ship's distance from the planet. Schema could substitute an abrupt transition if he likes the idea of the parallelogram map, but not space bending. It would still be less immersion-breaking than a loading screen and would simply act like a sector transition. In any case, the whole relativity transition theory needs to be refined a bit more to be usable.
Did you read my second idea about using a parallelogram map (made of two equilateral triangles put together) to fix the issue with the map being a torus instead of a sphere? The torus world isn't that bad, but it's still a poor solution. The two-triangle map has one equator and two poles, which is better. The edges of the triangles form the equator and the centers are poles.
I like the ideas here but I feel like the larger these planets get without the memory leaks being fixed will cause havok on multiplayer servers as well as slower single player people
could you imagine the amount of ram loading just 5 of these planets 20km's would take? and on a slower machine you might as well throw out the ideas
I'm not trying to rain on anyone's ideas I like the concept but it seems like unless they really recode the laag caused by such behemoths you will be in trouble - I mean if I get near a large ice planet I go from 150fps to 20fps and I've got around 14gigs of ram dedicated to the game several players I know can not even land on planets as they are now
and I think the concept of planet mining should be looked at and replaced - maybe smaller moon like objects around a planet that respawn would give the players who live on the worlds a interesting way of netting resources (such as a turret loaded with a salvage beam firing at the moon) maybe like a 24-72 hour respawn on them and reduce the ores on a planet to 10% making them way to much time to mine efficiently
I mean I know in long running solo play (for the people who still mine in solo play) games you can destroy dozens of planets getting resources as is and in online play you can fly through entire systems devoid of life and the laag of people mining effects every person on the server
That's why you don't load the whole flipping thing into memory at once. That's what the game does now and it just doesn't work well with anything very big.
nd I think the concept of planet mining should be looked at and replaced - maybe smaller moon like objects around a planet that respawn would give the players who live on the worlds a interesting way of netting resources (such as a turret loaded with a salvage beam firing at the moon) maybe like a 24-72 hour respawn on them and reduce the ores on a planet to 10% making them way to much time to mine efficiently
Planet mining definitely needs to change. My home server is going to ban it soon, once we move everyone's things over to a new world file (clean reset without grief to fix unacceptable database bloat). Instead, the overall mining multiplier will be increased so asteroids are more productive.
[DOUBLEPOST=1433096938,1433096874][/DOUBLEPOST]This section of the OP addresses your concerns about too much ram.
Loading Mechanics.
Current loading mechanics use the same algorithm as stations, ships, etc. That's simple and uniform, but it's not a permanent solution because it requires planets to be small.
When you're far above the planet, you don't need to see the surface. It's just a waste of graphics memory and rendering power. Don't load the surface. When you begin descending into the atmosphere, the game will check the closest segment and the server will start loading it, but not all of it. If you load all of a segment into memory, it will limit the size of segments. Take a page from Minecraft's book and only load nearby chunks into client and server. This should also allow planet segments to be very deep.
Weapons fire entering the atmosphere? Loading blocks for every shot would overload CPUs in no time, so display a little fire or explosion effect on the surface texture, then queue up the shots. When the CPU has enough time, load the part of the ground to be hit and register hits in an area. Doing it instantly isn't necessary when the blocks aren't loaded.
yeah I've seen allot of servers about to do a bit of what you said - no planet mining - selective or total wipes of sectors - several being corrupted and server crashing (one starmade server a friend plays on not on crashed from the massive data leak it took out the entire set of servers it was based on) cause by the new planets / the weird errors from old docking system interacting with new rails to create glitches
I'd love to see planets 3-5 times the size of the current ones I just want to be able to play the game when they are released lols
yeah I've seen allot of servers about to do a bit of what you said - no planet mining - selective or total wipes of sectors - several being corrupted and server crashing (one starmade server a friend plays on not on crashed from the massive data leak it took out the entire set of servers it was based on) cause by the new planets / the weird errors from old docking system interacting with new rails to create glitches
I'd love to see planets 3-5 times the size of the current ones I just want to be able to play the game when they are released lols
I want radii of at least 2km.
Based on what I've deduced of the dev preferences, we'll likely see an highly-refined version of dodecahedron planets in the final release. I hope I'm wrong though. I hope we get the parallelogram map and a seamless transition with relativity.
or just steal a D20 from any pen and paper dice game and use that as a model the curves wouldn't be bad enough to stop someone from transitioning and seems like it would work with the game mechanics decently allowing larger worlds
or just steal a D20 from any pen and paper dice game and use that as a model the curves wouldn't be bad enough to stop someone from transitioning and seems like it would work with the game mechanics decently allowing larger worlds
The thing about D20 is that it has more seams. A LOT more seams. Seams are bad. Therefore D12 is better than D20 because it still looks a lot like a sphere.
Anything other than a flat, wrap-around map (like an edge-wrapping version of a minecraft map) or a perfect cube will have places where blocks don't line up in a grid. A cube has gravity issues at the edges. Other polyhedrons have ugly seams. Flat maps wrapped around spheres require some sort of distortion unless you're REALLY clever. EDIT: They always have either distortion or some other weirdness. Polyhedrons are necessary.
This is NOT a torus world like my square map idea was. It has two poles and one equator. This has the same advantage that a squashed cube does, but eliminates the geometric impossibilities at each corner. A squashed cube tries to join three squares at one point, which is just a mathematical train wreck. My idea just wraps around two triangles (or one parallelogram, whichever works best code-wise). This makes it superior to both torus world and squashed cube. The overall map in memory is shaped like this:
Such a parallelogram can wrap around its edges without problems. Now don't be fooled: there is distortion, but it is far less severe on the surface of the planet. There are two strange things about this configuration when walking on the surface:
Two given paths from pole to equator may be of different lengths.
The edges of a square block only line up north and south at one line that stretches around the planet (this line can be considered the meridians of the planet).
If the edges are stretched and the points compressed, there will be visual distortion of the surface from orbit, so space (or at least rendering) must be bent to account for this so that things don't change size as you come in for a landing. The relative distortion idea can come into play here.
This diagram demonstrates how the wrap-around effect works. Keep in mind that these are not the actual shapes the triangles would be, as these are not equilateral. (Also note that I drew two triangles joined into a diamond rather than a parallelogram as shown above.)
a wraps to a and b wraps to b. SP is south pole and NP is north pole.
So for this to work, those will have to be turned into equilateral triangles...
How the heck do you do that with integers? The same way the pentagon edges are done now. Approximate. However, a provision must be made in the algorithms so that the faces that will wrap to each other fit nicely against one another.
Shortly I will tackle how to determine the insertion point on the map when entering the sector. Stay posted. EDIT: I have thoroughly cooked my brain so this part will have to wait until tomorrow.
OK, so here's the model I have for allowing interaction between outside space and the two-triangle/parallelogram map. I'll cover this in two sections: How it works, and how to make it feel right.
How it works:
There is no block distortion
Spatial distortion occurs within the planet sector to increase immersion
Making the planet appear round is done with rendering tricks by inserting objects into triangle space at an angle that makes them feel like they kept their same angle from outside. This transition is somewhat comparable to entering a rotating planet sector but more complicated.
Crossing the boundary is something like this. You have to get from cubic space to a sector shaped like two of these:
To do that, you have to determine the position at which the ship will enter this sector. Here's how I would do it, although there may be a better way:
Take two angles relative to the sector center to determine the craft or projectile's position on the projected/illusory sphere.
First pick the hemisphere the craft will enter based on entry angle/position. From the horizontal angle, draw a line to the equator. The craft will enter along this line. To determine where, compare the ratio of the vertical angle to 90* and go that fraction of the line's length "up" toward the pole. Translate this position into a position in the double-triangle sector and the ship/projectile enters at this point.
The angle at which a ship enters should feel as though angle relative to the planet does not change at the moment it crosses the boundary. I'm not sure how to work the math for that right now. It would take me too long to figure out and Schine would probably have to come up with a more program-friendly way to do it.
As you advance downward, the surface will begin to load.
Making it feel right:
Now we've made it across the sector boundary. Making that part feel right is as simple or complicated as rendering the planet in front of you as a "ghost image" of a sphere, textured to look like the actual surface of the planet. Some tricks will have to be used to project things onto this surface at a more-or-less consistent size, but I expect that is quite doable.
Now this is a little odd. We're flying around a "sphere" but there's no difference in the distance based on altitude. Either this can be left as is, or ships can be made to fly more slowly relative to the surface the closer they are to the sector boundary. There's one more problem. We appear to be flying around a sphere, but another ship that just flew into the opposite side of the planet appears directly in front of us... ??? That's no good. I know there's some complicated stuff here, but the end result needs to be that the ship looks like it's on the opposite side of the ghost image when it's on the opposite side of the planet map (help! I need a mathematician!).
From here, we begin entering an area of special relativity. As we descend, the "ghost" planet appears to approach below until we hit the atmosphere. After entering the atmosphere, the planet appears flat and terrain loads below. A radar blip on the opposite side of the planet now appears directly in front or behind or wherever depending on the shortest line to it. In other words, it now appears to be where it actually is on the flat map.
Ultimately, all distortions are done by rendering and a bit of alteration of weapon shot trajectories when fired within the sector and above the surface. Alternatively, if an aiming reticule for "leading" aim on a moving target is introduced, this becomes easier as weapons don't really have to fly straight. The aiming reticule can put put the the real location and shots can be seen curving out of sight around the planet due to gravity. That would be strange for beams, though. On the other hand, beams hitscan so as long as there's line of sight past the planet, the beam could just be rendered as a straight line from weapon to target from all reference points.
There may be other ways of doing it, but I recommend using a line of sight check around the pseudo sphere to decide sensor range. This would be determined from the highest altitude and the range would be retained down to the surface... I hope that wording makes sense.
One final problem arises: planetary bombardment. When weapon fire comes in, the chunks to be hit must be loaded to make damage calculations on their blocks. It's not a problem if there are people near the surface and that part of the surface is already loaded, but bombarding previously unloaded chunks could get REALLY CPU intensive on the server side if not coded carefully. Here's what I suggest:
Ignore any shot or spray of shots that wouldn't even destroy one block. Assume such small weapons fire cannot penetrate the atmosphere.
Queue up shots flying toward an area of the surface. Every few seconds, load up the needed chunks server-side and register hits as the CPU has time to do so.
Do not load the "hit" chunks to the client of course, as the client isn't close enough to need them. If it were, they would be loaded already.
To make it look right client-side, add small explosion or fire effects to the pseudo sphere texture. These should appear at approximately the time weapons fire might have hit the surface if the queue hadn't "grabbed" it.
As I'm an inexperienced coder and have little knowledge of the engine, I have no way of knowing how well any of this will perform, but I think it is a reasonable conjecture that it could be made to work. I'll restate this one more time: all distortion should be handled by rendering and special entrance/exit algorithms for the sector. This is many times better than trying to squish a polyhedron into a messed-up sphere.
This stuff is my idea for making planets sphere-like without block distortion or ugly seams. It basically tricks you into thinking you're on a sphere when you've actually transitioned into a special sector that is actually a flat plane. It sounds like an instance at first, but unless you consider each sector in the game an instance, this isn't an instance either.
I had some good ideas, but it turns out that (as far as I can tell) all flat maps that map to spheres have one or more of the following traits:
Doesn't act like a sphere. Square maps act like a torus. My parallelogram map idea acts... weird.
Bent blocks, because the angles at the edges of segments don't add up to 360 degrees
Double vision. The angle addition problem is repaired, but multiple copies of the same thing at different angles end up getting loaded in different directions when you approach certain parts of the map.
So the only logical solution is using a polyhedron, like our current dodecahedron planets. The problem is obviously the seams that you can't really build across. I'm trying to think of ways to further improve these edges now.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
If all is great, then have the option in the server.cfg to go up to 10k+.
