Minetest Forums

Github: https://github.com/gau-veldt/Minetest-Blockiverse
(future) Gamescript (TBA/future/TODO): https://github.com/gau-veldt/Blockiverse_game

Goal of fork: to add space travel to the existing 0.4.10-dev minetest engine (0.4.10-dev is where I copied the fork build from).

something like:
core.launch(ship_entity)
to go to blockiverse game/rendermode

something like:
blockiverse.reenter(planet_id)
to land on a planet (ie: core.start with that planet set as the world after player/ship appropriately positioned at touchdown point)

on quitting game (and restarting) player should still be in the same point in space if quit while in space, or his/her position in a landed-on world if on a planet. Thus it won't be possible to select a world in the same manner is unforked minetest in the main menu. You'd be selecting a universe instead or a Minetest-Blockiverse server (remote universe) to connect to.

Of course the main menu needs to be adjusted to display universes rather than planetary worlds and it is up to the game what world to start a player in.

some things need some planning such as how to have starsystem "biomes" in space affecting the distribution/size/resources/etc of planets/chunkoids generated within the starsystem. the starsystem "biome" basically categories differing sizes of the system's originating star (or absence of star in its place some other gravitational body such as a neutron star, quasar, pulsar, blackhole, etc) and will determine the volume/size of anything generated, nebulae, etc.

In this fork I also anticipate the need for server clustering support and as such will be migrating the database code to use a DBMS database backend (MariaDB, Postgre SQL, etc). Eventually I'll need to migrate player data to DBMS mediated storage as well.

EDIT: The rendermode for space would be a database table sparsely storing the locations of celestial objects, planet spheres textured with the world's 2D top-view landscape, ships, and smaller minable chunk-based things called chunkoids that may have differing radius chunkoid to chunkoid (8*r*r*r chunks per chunkoid where r is the chunkoid's radius). This second game/render mode in the engine and will be the meat of the fork. I also intend to have it expressed as fully as possible with a suitable api making it accessible to mods like the core game/render mode is.

Good luck!

.

Are you sure it's good decision to drop git indexes?

You might benefit from the enhancements in the following forks of Minetest:
http://voxelands.com/
http://freeminer.org/

Sol wrote:Are you sure it's good decision to drop git indexes?

It reduces Git clone size quite a lot, at the cost of a (possibly not so useful) history.

The rendermode for space would be a database table sparsely storing the locations of celestial objects, planet spheres textured with the world's 2D top-view landscape, ships, and smaller minable chunk-based things called chunkoids that may have differing radius chunkoid to chunkoid (8*r*r*r chunks per chunkoid where r is the chunkoid's radius). This second game/render mode in the engine and will be the meat of the fork. I also intend to have it expressed as fully as possible with a suitable api making it accessible to mods like the core game/render mode is.

I forgot to put that in the OP.

Esteban wrote:A fork based on space travel!?!
I wish you the best of luck! I can already imagine an awesome colony at mars! :D

Spoiler

Heck with just Mars, to lightspeed and beyond!

Travel the huge universe sparsle populated (possibly more dense around stars to form starsystems, with "bigger star" starsystem "biomes" having larger planets with better resources or you might find nebulae (basically chunkoids generated in a nebula biome) or other rocky chunkoids to explore/mine - nebulas might be dangerous if your blockship isn't properly equipped to navigate them [would be like going into lava with a poorly built blockship] but of course they have rare stuff you very likely won't find on planet worlds) with perlinized celestial objects, planets, chunkoids, as far as your ship has fuel to travel (and if you build a EVA suit you can even go outside your blockship (EVA suits have limited air and energy and stuff and must be recharged after use) and mine the chunkoids)! I'll actually be using a pair of values per axis: integer:pc + float:au (pc is parsec, au is astronomical unit where 1 au is the averaged earth-to-sun distance) so the au part of the value lets stuff be close together and the pc part lets it be very far away in space an int32 gets to around 2 Gpc in any direction which about a seventh of the way to the universal edge (http://en.wikipedia.org/wiki/Particle_horizon). If it takes a warpdrive/hyperdrive blockship a decade of real time to go a full million ly or 1/3 Mpc you're looking at like 30 millenia to get to even 1 Gpc!

Naturally if you don't like the planet you are (minetest engine) on you can build a blockship, take off into space, find another, land and explore the world there instead (maybe the griefers won't find you there :P). Also there will be security support for blockships (access levels/whitelist) so you can lock out unauthorized griefers from messin' with yer shipz (unless they got one with weapons of course).

Travelling blockships, building your own custom blockship designs (but the bigger they are the more fuel they consume of course) like you'd build a house in minetest proper, flying around your current planet (world) in your newly-built blockship (run out of fuel tho and its long way down :D ) to find interesting landscape, drone blockships (eg: probes), blockship battles, alien mobs/npcs, alien invasions (if you juice your world too much with rare stuff (found on other planets) without building planetary or regional defenses), modding api for it all just like minetest core proper to make most of that cool stuff possible (a bunch of the later stuff I mentioned here would just be game/mod scripts), etc.

That's an overview of the kind of game I'm shooting for here...
However with an api for mods to access the spacefaring part just as they do with minetest core now, a lot more is possible.

What about gas giants? For example, falling into them could be fatal, but the higher layers of their clouds could be used somehow. Also, don't forget the noises they make:
https://www.youtube.com/watch?v=nYNjm2r-wqc-Jupiter
https://www.youtube.com/watch?v=Q000bEMEG2o-Saturn
Gas giants like Jupiter could be bright places with lots of clouds and even flying lifeforms. Of course, the lower layers of the clouds down to the area where players take damage and could die could be darker, but could still be dimly lit. Down in these layers, more dangerous lifeforms could be found, but so could valuable gases/materials. As a final idea, lush islands could be found prominently in the upper, brighter layers. Meanwhile, drier islands could be found in the deeper, dimmer layers.
As for gas giants like Saturn, those ones could be dark, frightening places. Sure, the upper layers of their clouds could be bright, but could pale in comparison to the upper layers of gas giants like Jupiter. Desert islands with water could be found in the upper, brighter layers of gas giants like Saturn, as well as a pretty small number of flying lifeforms. In the lower layers of their clouds, things could get far more sinister. For starters, things could be pitch black down there, thus making lights mandatory. Also, the lowest layers down there could go from causing massive damage to instant death to players. Finally, terrifying monsters, demons, and ghosts could be plentiful down there, but so could very valuable gases/materials. As for the islands in the lower levels of gas giants like saturn, they could be artificial, abandoned spaceships with color schemes that consist primarily of purple and black.
In the end, players could learn to be very careful with Jupiter-like gas giants and very fearful of Saturn-like gas giants. Needless to say, items that fall to the damaging layers of both kinds of gas giants could be destroyed, and the individual objects themselves could have minor differences from each other.

Inocudom wrote:What about gas giants? For example, falling into them could be fatal, but the higher layers of their clouds could be used somehow. Also, don't forget the noises they make:
https://www.youtube.com/watch?v=nYNjm2r-wqc-Jupiter
https://www.youtube.com/watch?v=Q000bEMEG2o-Saturn
Gas giants like Jupiter could be bright places with lots of clouds and even flying lifeforms. Of course, the lower layers of the clouds down to the area where players take damage and could die could be darker, but could still be dimly lit. Down in these layers, more dangerous lifeforms could be found, but so could valuable gases/materials. As a final idea, lush islands could be found prominently in the upper, brighter layers. Meanwhile, drier islands could be found in the deeper, dimmer layers.
As for gas giants like Saturn, those ones could be dark, frightening places. Sure, the upper layers of their clouds could be bright, but could pale in comparison to the upper layers of gas giants like Jupiter. Desert islands with water could be found in the upper, brighter layers of gas giants like Saturn, as well as a pretty small number of flying lifeforms. In the lower layers of their clouds, things could get far more sinister. For starters, things could be pitch black down there, thus making lights mandatory. Also, the lowest layers down there could go from causing massive damage to instant death to players. Finally, terrifying monsters, demons, and ghosts could be plentiful down there, but so could very valuable gases/materials. As for the islands in the lower levels of gas giants like saturn, they could be artificial, abandoned spaceships with color schemes that consist primarily of purple and black.
In the end, players could learn to be very careful with Jupiter-like gas giants and very fearful of Saturn-like gas giants. Needless to say, items that fall to the damaging layers of both kinds of gas giants could be destroyed, and the individual objects themselves could have minor differences from each other.

would have to do something about MT's pesky 62k axis limit first though (as I am still using the MT engine for planetary exploration) :P

.

Esteban wrote:

Inocudom wrote:-snip-

I love the idea of the mobs, yet I don't know where you get the idea of Saturn being evil, but weird creatures hiding deeper on the planets is fascinating concept for game play. Don't forget the satellites surrounding those gas giants. For example, the moon Titan is similar to Earth, but with a whole different chemistry. Instead of water it has liquid methane, if I remember well. Anyways I just hope this fork gets accomplished! I could give ideas, but they are so many and I don't have the time to write them all! xD
Comets, black holes, super novas,etc.!

Right now I just want to get the mechanics and building blocks sorted out as actual goals for the fork, the blockiverse design goal being to be an engine in the manner MT proper is an engine, with enough api available for all the sexy ideas you mention being saved for the Blockiverse_game game script. :)

Sounds like a very intresting idea. I'd love to play a game where space travel and beeing able to manipulate the scenery are combined!

I'm just afraid that it might be very difficult to reach. One of the major obstacles is space and the human perception thereof. Minetest is more than large enough to encmpass more "world" than could ever be used by a single player or even by plenty of players on a server Space..is big. Very big. So big we can't really imagine it as it has no real meaning in our everyday life. And also so big that travelling through it has to be shortend in order for the player to arrive anywhere before the player looses patience and deletes the game.

"Planets" have to be far enough apart so that players with a good graphics card can't wave at players on other planets and tell them to stop jumping up and down on their beds - because that's what they can see from the next best planet. There has to be some illusion of width and space, although there's no way to actually store that much data at a resolution of 1m. And - in the vast majority of cases there's no point in storing that data anyway as it's empty (in space) or scenery (on a planet). Where it gets intresting is where players start to really interact with the world, to gather ressources or to build something of their own, or to drop a probe or start building a space station etc. "Gravity" in a game universe is where the player does something (and even if it's only taking a look at something).

With the recent addition of models as blocks, the "universe" might consist of a map where a planet has the size of a block (only spherical). Even then, scale is something which will have to be something...unheard of. The sun will have to be far smaller than it actually is, the distances more linear than anything, moons far larger in relation to the planet than they actually are..

Sokomine wrote:Sounds like a very intresting idea. I'd love to play a game where space travel and beeing able to manipulate the scenery are combined!

I'm just afraid that it might be very difficult to reach. One of the major obstacles is space and the human perception thereof. Minetest is more than large enough to encmpass more "world" than could ever be used by a single player or even by plenty of players on a server Space..is big. Very big. So big we can't really imagine it as it has no real meaning in our everyday life. And also so big that travelling through it has to be shortend in order for the player to arrive anywhere before the player looses patience and deletes the game.

"Planets" have to be far enough apart so that players with a good graphics card can't wave at players on other planets and tell them to stop jumping up and down on their beds - because that's what they can see from the next best planet. There has to be some illusion of width and space, although there's no way to actually store that much data at a resolution of 1m. And - in the vast majority of cases there's no point in storing that data anyway as it's empty (in space) or scenery (on a planet). Where it gets intresting is where players start to really interact with the world, to gather ressources or to build something of their own, or to drop a probe or start building a space station etc. "Gravity" in a game universe is where the player does something (and even if it's only taking a look at something).

With the recent addition of models as blocks, the "universe" might consist of a map where a planet has the size of a block (only spherical). Even then, scale is something which will have to be something...unheard of. The sun will have to be far smaller than it actually is, the distances more linear than anything, moons far larger in relation to the planet than they actually are..

The trick for space is to switch from a solid world (i: MapBlocks) storage model to universe that stores data sparsely. A second db table and a second rendering/game engine mode would be needed to render/interact with the objects referenced by the sparse table. Planets can be rendered as worlds with the existing minetest engine (even using existing mods as the blockiverse api will be separate) when landed on.

My plan is for a second render/game mode (with a separate lua api included for itself) using a sparse representation of objects using a DB table whose rows correspond to a single object in space and contain coupled parsec + astronimcal unit (value pair pc as an integer+au as a float allowing close and far objects) coordinates (two values for each axis, an integer in parsec, and a float in au's). The space is filled sparsely rather than in a solid manner as world maps are (I'm sure the perlin noise threshold can be adjusted to have empty space between useful data points). Some heuristics can be applied such as more detail around stars (the larger the star, the more detail generated). Special chunkoid objects using chunks based on MapBlocks could be generated to create minable rocks, nebulae, gas giants (which would be hollow chunk-wise to save on storage), other such things from the space faring game engine. Planets would be a special case in that they could be landed on once in range and then the normal game engine takes over to render the world of that particular planet. I'd render a top view of the world onto a texture padded to a square which could then be used in a diamond-folding algorithm and textured onto the planet's sphere to display the planet in space (so that planet view from space resembles the world contained by it).

Various travel speed will be possible with it possible to travel super luminally in space (it's a game we don't have to follow physics exactly as we set the rules) on blockships with appropriately-crafted engines and fuel. At would actually require exploration in that you'd have to point a ship in some direction travel several lightyears towards a star and see if anything interesting is there (which there should be if the generator is adding detail around stars) with the generator creating stuff in the direction blockships are moving towards if nothing is currently there.

Sokomine wrote:I'm just afraid that it might be very difficult to reach. ... ... , although there's no way to actually store that much data at a resolution of 1m. ... ...

As I mentioned in the post before this I intend to use a db table that stores the locations of pieces (objects) rather than the entire 3D chessboard. Google tells me 2^89 meters is around 20 gigaparsec out, which is beyond the 14.4 Gpc observable edge of the universe. So I get a 96-bit or 128-bit signed integer class, compose 3D vectors from them and use those to store the locations of stuff in the db table. Keeping everything in one unit (m) simplifies the translation step (see below).

The only tricky part is appropriate normalization and LOD. We obviously can't show everything up to 14.4 Gpc range to the player. We can however use a much more reasonable and smaller viewing range suitable to what the 20-20 eye would see out the window of a spaceship then noramalizing the large-scale coordinates by translating them to be relative to the player (makes player pos 0,0,0 and everything else relative for the renderpass in order to factor out the very large potential number of the object's absolute position and thus fitting within irrlicht coordinate range limitations) and using appropriate LOD culling to cut stuff down when it gets too far away to be worth the additional cycles to render entire blocks of the object's chunkoid. Stuff in space is really far apart so it's large amounts of space with only a handful of objects in comparison. A simple algorithm would scan the currently-generated universe for stars in advance and generate highly simplified meshes (a cube will do) so they'll emit light dots when looking out the window of a ship. A good "universe generator" should probably first use the perlin stream to generate a starscape first (stars, their locations and sizes being varied by the perlin noise). Subsequent generation cycles generate detail around a specified star to create a solsystem, with other chunkoids and planet objects being generated using invisible "biome" spheres generated around a star. This of course may be extended to generate clusters (of stars) or even our universe's constellations (but to be truly unique let the perlin do its job and make a unique universe :). You'd need to fudge the first solsystem's biome after initial perlin generation to support a livable planet (what the trekkies call "Class M") where the first player starts. After that player(s) would need to build ships and explore the generated space to find livable solsystem biomes (ie: "class M" planets). The "class M" planets would be special. Landing on one invokes the normal minetest engine and the player explores the planet he or she would a normal minetest world, with the possibility of once again lifting off into space in his or her blockship. Other structures would be ships, stars or chunkoids. Chunkoids are composed of ChunkBlocks (similar to MapBlocks but using s32's opposed to s16's to allow chunkoids to be much larger than ordinary worlds) and generated hollow to avoid too many chunks being generated for huge gas giants when a player would only be able to survive the first several layers of chunks. Planets would be rendered from space at more-or-less earth-sized using a diamond-fold algorithm to map the image of a top-down render of the world (the image then padded until square) onto the sphere of the planet. This would mean planets seen from space would somewhat resemble the actual minetest world the player would encounter when he or she landed on it.

As a general rule, you should at least get a prototype working before making a post announcing a project. Unless you asking for help or input.

It is an interesting idea though.

rubenwardy wrote:As a general rule, you should at least get a prototype working before making a post announcing a project. Unless you asking for help or input.

It is an interesting idea though.

I am open to both right now. I am still scouring the engine coding looking for where to fit in the swap in and out of another engine within the same game.

... and researching larger int libs... I'll probably need to add boost as I hear horror stories about GMP being way too slow (like 18 minutes with boost 128-bit ints versus 90 hours with GMP's bigint type slow).

I'll also probably be making small PoC's of various ideas mentioned here to test them in isolation such as chunkoid rendering (minimizing the meshes generated to only the visible surfaces, etc)