Re: Game world and implementation

Suggestions
,
1

Hello,

I guess the first step in this sort of project is to lay down the basic theory. According to GregoriousT’s plans, “Mechaenetia” will be set on one or more virtual planets, represented by a 3-d tiling (tessellation) of 0.25m3 cubes.

The shape of each planet is not that of a sphere, tetrahedron, cube, isocahedron, or dodecahedron. Neither is each planet flat. Just what shape are you planning on using? A two dimensional grid will fit on a torus, for example.

As this is a Minecraft clone, I assume the cubes will be stored in some sort of matrix. Will every quarter-meter cube in the universe exist on the same matrix? Or will you create matrices for each planet, or even separate matrices for different parts of each planet?

How do you plan on storing the virtual universe? Will it be generated on the fly, or when first starting a new game? Will the universe be exactly the same for every game, or procedurally generated? If procedurally generated, to what extent? Compare procedural generation in Minecraft to a game like Terraria.

If some region is generated on the fly, do you commit it to permanent storage a la Minecraft? Or do you plan on only committing changes to the world state, then generating the up-to-date region on the fly? Or perhaps you plan on doing something in-between, where after a threshold of changes are recorded, you simply commit the whole region down to the last cube to a file.

When it comes to “entities” such as people, animals, trees, houses, etc, are these going to be represented in the matrix with cubes, or in a separate list, or both? For example, in Minecraft people and animals do not actually take up a block in the dimension’s array of blocks. But trees and houses take up blocks. How will this work in Mechaenetia?

Just some thoughts.

~Max

3 Likes
2

Congrats on guessing the Donut right. XD

Each Planet or similar Object will be its own Octree Block Grid. If gravity ever went diagonal then there would be some Issues.

Procedural Generation for literally everything, even the Sky. Just the closer you get to stuff the more “resolution” you get on the objects. (far away Stars only need to be one Pixel worth of Data until you get close)

Changes to the Worldgeneration can happen, so including only changes would result in Issues. While many Blocks will be like Schrödinger’s Cat and stay “undiscovered” until actually witnessed, like Stone layers being filled with Ores the moment you look at the Stone, but the Stone itself stays “?” until you uncover it. The “Height Map” of a Region will be generated right away to some point, to make sure we dont get massive Chunk Slices, and so stuff like huge Mountains can be seen far away on the Horizon.

Since when are Trees and Houses Entities? Aren’t those by definition Stationary Blocks
As for Mobs and such, the whole thing is gonna use an ECS, and explaining how that works would take way too much time, so here have a Wikipedia Article:

3 Likes
3

Will it look like a real donut (with thickness) or a ring (without thickness)?

2 Likes
4

Well it wont be a flat band if you mean that, I am not sure of the diameter yet, but it could look like a Donut if the ratio between the Diameter of the Ring and the “Height” of the World is small enough.

2 Likes
5

But how to bend the cube into a donut? If the planet is small enough, many strange situations may occur.

2 Likes
6

As long as there is a “bottom” to the flat world, like the ring shaped “core” of the planet, it is still possible to pretend that there is curvature where there is not. XD

The World will be huge so it is very unlikely you reach bedrock like in Minecraft. And coordinates will be based on frame of reference, with each Donut Planet being one of those Frames of Reference. Usually Frames of Reference dont collide with each other, so that is something to deal with far later.

2 Likes
7

So the surface of a planet will be a circular two-dimensional plane?

2 Likes
8

The wonderful thing about a Torus or Donut is you can take an elongated RECTANGLE and wrap it around it. You cannot do that with a Sphere. This means you can put two Maps typical for the Civilization Games and easily make a Donut Planet out of it by pasting one map on the inner Side of the Donut and the other on the Outer Side of the Donut.

2 Likes
9

When you reach the “core”, you should be able to reach the other side of the planet by walking a few steps forward; and if you stand on the side, you may see a curved surface.

2 Likes
10

Handling the curved surface is an easy render trick, but i do have to say that you cant just compress the block grid once you are close to the Core. That is why there is a Core in the first place. Though I might add some way to go through the Core to the other Side. This depends on if I design the Core as Lava or as some sort of Ultra-High-Tech Gravity thing you cant break.

2 Likes
11

But how should a “bridge” (such as some kind of elevator) span the hollow section work? If such a project is built in a cube, the bridge will be cut off in the center. Similarly, orbiting the entire planet from the inside will be faster than from the outside

2 Likes
12

Yes the whole thing will bend spacetime a little, kindof like the globe projection on a flat map, but thanks to the Donut shape at least there is no points at which everything starts like a North Pole, and more importantly, you get a more evenly spread amount of planet wide Biomes, since the North Pole is not a point but a line, similar to the Equator.

And who said the High Tech thing would be hollow? It would be a magnetized tube with high velocity fluid inside it, you cant get through that. I meant going through Lava is the easier way. XD

But with the High Tech thing I could add a Teleporter alike thing so you can go through it to the opposite side.

3 Likes
13

OK. Let me describe the mental model and you can tell me if I understand correctly. You have one universe grid, a 5x5x3 section of which might look like this:

            [ ]
         [ ]   [ ]
      [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
[ ]   [ ]   [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
      [ ]   [ ]   [ ]
         [ ]   [ ]
            [ ]

            [ ]
         [ ]   [ ]
      [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
[ ]   [ ]   [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
      [ ]   [ ]   [ ]
         [ ]   [ ]
            [ ]

            [ ]
         [ ]   [ ]
      [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
[ ]   [ ]   [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
      [ ]   [ ]   [ ]
         [ ]   [ ]
            [ ]

Then we might put two planets on the grid, planet “P” and planet “Q”, each taking up 2x2x2 units of the grid at this level of detail:

            [ ]
         [ ]   [ ]
      [ ]   [ ]   [ ]
   [P]   [ ]   [ ]   [ ]
[P]   [P]   [ ]   [ ]   [ ]
   [P]   [ ]   [ ]   [ ]
      [ ]   [ ]   [ ]
         [ ]   [ ]
            [ ]

            [ ]
         [ ]   [ ]
      [ ]   [ ]   [ ]
   [P]   [ ]   [ ]   [ ]
[P]   [P]   [ ]   [ ]   [ ]
   [P]   [ ]   [Q]   [ ]
      [ ]   [Q]   [Q]
         [ ]   [Q]
            [ ]

            [ ]
         [ ]   [ ]
      [ ]   [ ]   [ ]
   [ ]   [ ]   [ ]   [ ]
[ ]   [ ]   [ ]   [ ]   [ ]
   [ ]   [ ]   [Q]   [ ]
      [ ]   [Q]   [Q]
         [ ]   [Q]
            [ ]

The universe grid does not actually contain the individual cubes present on each planet. Instead, each individual planet has its own grid stored separately. This way it is easier to move planetary bodies around, but rendering celestial bodies becomes a special case since the universe grid does not actually describe them in detail. This is good since individual planet grids are stored as if the planet were flat.

So for example, when the player is on the ground of planet “P” they might see planet “Q” in the sky during certain months of the in-game year, as the two planets grow near in orbit. This might be accomplished by prerendering a new skydome at the start of every in-game month, calculating where on the skydome planet “Q” should appear, and then rotating the skydome in real-time according to the spin of planet “P” and the position of the player upon it.

Alternately, when a player is in space the render engine will be looking at the universe grid to determine gravity, collision, etc. Question: will a player spaceship launching from a planet into space experience a seamless transition? From the player’s perspective, will there be a loading screen or cutscene when crossing the boundary between a planet and open space? If I have my mental model correct, I recommend using a loading scene or cutscene and maybe implementing a seamless transition after completing other more “core” features of the game.

On the other hand, if you want orbital physics to be a major feature it might be worth putting more thought into the transition. I think satellites, space stations and the like are not well fit for the same grid as a “flat” planet, especially if your planets are conceptually solid tori. Let’s say you want to launch a missile from the surface of the planet to a satellite across the donut-hole. Should a passing spaceship be able to watch the missile from launch to impact?

2 Likes
14

There would be a regular 3D Model of an actual non-cube-ified Torus in Space, with a Top-Down View of the Octree Chunk Grid being the Skin of the Torus. (It is not going to be THAT basic, there is gonna be depth later too, this is just to imagine it)

The closer you get to the Surface of the Torus the higher the detail of the Resolution of the Octree Grid becomes on the Torus, until you get close enough to hit the ground and its at full Resolution at the place where you are at. No Transition Cutscenes, just actual live Transition.

So if you fall from Space onto an Island, you only see a Green Dot on the Torus at first, then the Dot becomes a 2x2, then a 4x4 with a few missing pieces since islands aren’t perfectly square, after that the Island will be in an 8x8 Resolution, then 16x16, 32x32, 64x64 until it has reached full resolution.

This concept also works on the ground Level and not just from space, so a far away Mountain may just render as a few big pixels in the distance until you get closer. ^^

Makes Ocean Rendering simpler too, since you can essentially render the far away Ocean as one big blue pixel until the Horizon cuts it off, without needing that white Fog that Minecraft has to hide the fact that Chunks aren’t loaded.

Each Octree Node is planned to contain the 8 Sub-Nodes and a Color representing a mix of all of those Nodes for long distance rendering.

The Sun could for example look like a Pixelated Image from the distance with only a couple hundred pixels representing it, but when you get closer or zoom in, you guessed it, it gets rounder and more detailed.

Oh and each Planet/Satellite/Object in Space will have its own Octree Grid, just like Vehicles will have much later on.

2 Likes
15

How are you going to render oriented entities?

Let’s forget about how planets are tori for a second and just imagine a player looking at two satellites in space. Satellite #1 partially obstructs the player’s view of satellite #2. The player’s orientation matches the universe’s reference orientation. Satellite #1 is rotated by (θ:π/4, φ:0, ψ:0) and satellite #2’s is rotated by (θ:3π/2, φ:π/4, ψ:3π/2), where θ is the angle between the reference z-axis and the entity’s z-axis, φ is the angle between the projection of the entity’s z-axis onto the reference x-y plane and the reference x-axis, and ψ is a magnitude of clockwise rotation about the unit rotation vector (θ, φ). Below is an illustration of the scene.

oriented

Both stations have their own voxel octrees with different orientations, which greatly complicates the rendering process. The most straightforward method is to march through all octree entities on-screen… which possibly implies a performance drop from linear to polynomial time. I also wonder if jumping from one octree to another will involve lots of cache misses.

2 Likes
16

The Universe itself does not have a reference grid, it would render everything 3D, so the Sun would be a Sphere made of Blocks, essentially. Unless I misunderstood that question.

As for Cache misses, I think since it is about rendering the GPU would be responsible for that, so I am not sure if that applies to Rendering an essentially predefined Model consisting out of a few Cubes, if it is far away. Ofcourse Integrated GPUs exist so I guess that can be a thing. I’m just gonna ping @OvermindDL1 on that question.

By the way, the Player Model would also be rendering Octrees, so that far away Players don’t end up wasting Frames by being all high resolution.

2 Likes
17

Oh, I see. So you have a universal coordinate space (and thus a reference orientation) but floating objects in space are all entities with a minimum of these components: a position, an orientation, a voxel (or polygon) model.

At some point I assume the player’s position switches from universal coordinate space to the planet’s local coordinate space. Otherwise that’s a lot of extra math.

If I have that right, the next question is whether all entities have the above three components. For example, would a bird have its own voxel model independent of the planet’s, able to rotate by odd angles such as 30%? Or is a bird pretty much a polygon model projected onto the planet’s voxel grid - like a timelapse animation of original LEGO bricks or a multiblock structure in Minecraft?

This is what I was asking before when I thought trees and houses were entities.

3 Likes
18

Every Entity has its own Grid ofcourse, why would it not? And there will be frames of reference for making sure Maths stay fine.

2 Likes
19

What is the full definition of your octree structure? Eight handles per node plus one color? Are you going to use a palette, or embed four bytes in each node, or something else?

3 Likes
20

It will average the major Colors of the things inside the Node and cache that. I might even make it turn into a sloped shape if the blocks inside align right.

Certain things like Leaves will also end up marking the Octree Node as blob from way closer than normal other things, making Trees look more dense from afar but when you get close you can actually see through the Leaves.

2 Likes