World Generation

[metouto]

Speaking of stargates, image if each of these worldlets had a random number of gates/portals on it, say between 1 and 4, and each portal/gate was linked to a single gate/portal in another worldlet. That would give you something to explore for.

Now this is an idea my mind can get a hold of ... especially the ..." would give you something to explore for." Could this not be a cool way to get from one bio section to the next bio section??? My thought also go back again to what woodspeople said about traveling through tree roots ..... hummmmmm


note to self .... * go read article posted by Immortius* .... after lunch ....

 

[overdhose]

i see we finally reached the stargate syndrome.

that was my idea to, ever since minecraft really.
A big finite world with overlapping edges, and portals to other worlds for other resources etc. I personally think I would enjoy it more then an infinite stretching world where you easily loose direction of where you are and why you are there. Add the better biome distribution and organic vegetation and I think that would compose my ideal vision of a game world setting atm.

Could also lend itself to create dungeons in a finite setting and use portals to access them. Would have to clear portal 1 to spwan portal 2 etc

 

[Cervator]

Yeah I like it - goes well with the portal approach, obviously

Also would give us an excuse to do more with the skysphere - since other worlds may have other moons, suns, etc

Argh so much to read!

 

[eleazzaar]

Also would give us an excuse to do more with the skysphere - since other worlds may have other moons, suns, etc

Procedural suns, moon, stars & planets!

 

[Cervator]

Also would give us an excuse to do more with the skysphere - since other worlds may have other moons, suns, etc

Procedural suns, moon, stars & planets!

Aww yeah. Next up: Elite!

 

[eleazzaar]

Food for thought...

• * Should the worldlets all be of the same size or vary?
  
  * Should the worldlets have a single biome, a few biomes, or usually have all biomes?
  
  * Should the player be able to build shortcut portals to known worldlets, or should he even be able to build portals to unknown worldlets? (this would assume that some part of the portal is unique to the destination address, like runecraft
  
  * Should the geometry of the worldlets all be the same (the stuff discussed earlier in this thread) or vary?
  
  * Should the later worlds discovered have more and harder enemies, or should it be random, or constant?
  
  * Should any creature besides the player be able to move between worldlets?
  
  * Should the player be able to move equipment/items/blocks, between worldlets?

 

[metouto]

Interesting article:

The difficulties of an infinite video game world

immortius ....how do you find great articles like this ???? It has lead me to 5 other articles that I have to read I am not a coder or a programmer but this idea of an never ending world touches the ..."I need to explore" ...part of me.

thanks for stimulating my thinking ....

 

[Immortius]

Someone linked me to another article on the same blog (the one on cheating by abusing directx interception), and I browsed around to see what else was on there.

 

[dei]

Ahh, Stargate brings me to another Idea regarding multiplayer:

Why not make it possible to travel from one server to another? Ok, servers would have to approve other servers from where you can travel to it to avoid cheating by manipulating your transferred inventory.

Another Idea would be to make an entrance world, where you land directly when starting the game. There you are able to go through a small tutorial and then enter your different worlds (multiplayer or singleplayer) through some portals (eventually resetting your inventory depending on the type of portal).

 

[Cervator]

There's some very good potential for unusual multiplayer-like integrations, yes. I've got a few in mind for down the road...

 

[Mooncalf]

In my opinion there are two problems that make a realistic world generation undesirable for a game such as ours:

1. Size: The world is friggin' large. Walking around it is practically impossible, especially as a past time activity; pretty much everybody who will play the game will only see a fraction of what the engine can put out before giving up and moving on.

If you give the players fast transportation like planes, spaceships or teleporters they will simply try to use those to skip the content to get to the interesting parts, which are probably a lot harder to find since there is so much ground to cover during the search for them.

In addition all that procedural generating takes up time; when it is done in real time during play, people will constantly stutter through the game as new chunks are generated, which is a very unpleasent gaming experience and moving faster makes it worse.

2. Biome exclusivity: A biome is restricted to where in the world it can be located; you simply can't have a jungle in vicinity to a tundra. This in combination with the large land sizes of a realistic world means that a player will only ever experience a very small selection of related biomes in any given game world, which renders a lot of game content that depends on biomes void for an individual game session, thus forcing players to keep generating new worlds in the hope to end up in a new biome right at the beginning.

Generally we would want to have all the different biomes we can come up with in the reach of the player, although we can certainly have large biomes that have restrictions as to what type of biomes they can be neighboured with and we might even distribute them according to geographical orientation (e.g. North gets colder, South gets warmer) so the player can influence what kind of biome he discovers.

Much more interesting than the biomes themselves is what you can find in them. Having large abandoned cities, hidden ruins of ancient civilizations, secret underground military bases, natural hazards and wild life can all tremendously spice up mundane things like a temperate forest or digging tunnels into a mountain range.


As for the idea of the ring world: It's a nice idea, but I would rather focus on being able to render the next 5 km of the gaming world in your vicinity than the 2000 km² at the other half of the world, which you will most likely never see.

 

[Immortius]

In addition all that procedural generating takes up time; when it is done in real time during play, people will constantly stutter through the game as new chunks are generated, which is a very unpleasent gaming experience and moving faster makes it worse.

This doesn't actually have to be the case.

 

[Mooncalf]

This doesn't actually have to be the case.

Well, I'll take your word for that.

In MC that was a crippling issue; at least for me.

 

[overdhose]

pretty much everybody who will play the game will only see a fraction of what the engine can put out before giving up and moving on.

people don't explore minecraft because there is no incentive. Install a mod like millenaire and all of the sudden you will explore more : because the mod gives you incentive to do so.

So if you want people to explore your world, give them incentive, that's all.

And yeah, Immortius : any more detail on what you have in mind?

 

[Immortius]

Well, chunk generation is already background threaded, so that should be quite smooth without causing stuttering. The one thing that still causes stuttering on my system is the setting up of the physics for a chunk, which happens regardless of whether a chunk is new or not. But that will hopefully be fixed by the new physics approach I'm working on that doesn't require generating anything for physics.

Still, it take a bit of time for chunks to appear regardless, so if you move too fast the world won't keep up. And I otherwise agree with Mooncalf except maybe on the biomes - not every instance of the game needs to involve every biome. Some of the issues can be offset by letting players select their starting location from an overview/world map.

 

[Ten'son']

Generally we would want to have all the different biomes we can come up with in the reach of the player, although we can certainly have large biomes that have restrictions as to what type of biomes they can be neighboured with and we might even distribute them according to geographical orientation (e.g. North gets colder, South gets warmer) so the player can influence what kind of biome he discovers.

I'm playing Minecraft and they just added 'large biomes' , wich I was expecting for a while, and it's awesome to be completely lost in a desert and not seeing snowed trees or even the end of the desert (complete immertion). So yeah large biomes ! ;p
Also, to be sure that there will never be a 'snow biome' near of a 'desert biome', biomes could be generated from a 'temperatures map' (like this one : http://paramoteur.franceserv.com/meteorologie/carte-temperature-en-altitude.gif). So every pixel of this map has a temperature and so represents a chunk. Thus, nature will progressively changes.
Also, voxels could progressively change, for example, from sand to dirt like a fade.

 

[overdhose]

We actually have a proof of concept in the works I think (I don't know the status on it but we have an open issue in github https://github.com/MovingBlocks/Terasology/issues/233)

 

[Immortius]

We have both humidity and temperature maps (or noise functions at least) at the moment, which feed into world generation. Certainly room for further work in this area.

 

[Zidane]

Personally I love the WGEN I have seen from testing out Terasology.

So much so that I would probably drag over one of the guys (DDoS) within my Vanilla Team working on Project Vanilla (which is a recreation of the Minecraft Server/Client for Spout platform) and see if he can borrow some ideas/code.

As for some potential feedback here, right now our WGEN is still in its infancy (the implementation in Vanilla that is) but it uses a Whittaker model as the biome selector that has a master Voronoi noise for main biomes, a minor Voronoi noise for minor biomes and then you simply change attributes within the specific biomes to adjust the look of the final generated terrain in-game. For generating noise, we use a port of libnoise (called jlibnoise made by RoyAwesome ).

 

[UberWaffe]

First quick draft at a structure for the dimension and world structures, to tie in with world generation.

Each rectangle in the structure is meant to represent a class on its own (though in the case of world and region variables it might simply be a standard java class capable of supporting any data type).

Relationships are indicated as 1-to-1 or 1-to-M(any), but does not imply a database storage per say.
For instance, it should be possible to get a world and get a list of all its regions from it.
Ans also, take a region and get what world it belongs to.

General idea is that each region (a world consists of many regions) will have associated noise-maps attached for various things such as heightmap, temperature, humidity, etc.
The class for the regions should not generate the maps, just be able to accept already generated maps.
I.e. whatever noise generation or algorithm is used does not matter, as long as the result (or a part of it) can be given to a region to store as its relevant maps.

Still busy fleshing out more detail such as variables and function associated with each class.