World Generation

[Cervator]

Cool, that's the kinda stuff we need. We might be wanting to flesh out what world gen threads are for what though, the map gen thread also has some similar topics. I am also amused to remember the reference there in the first post to the Azeroth MC project, which I understand synopia might actually have working in Terasology somehow ..

That thread also has a couple of the other docs I was remembering from some early design work.

 

[UberWaffe]

Yeah, for now I am focusing more on the general layout and approach of the world system.

The general idea I have at the moment is something to this effect:

Universe

Spoiler

• Only 1 instance
• Contains variables such as:
  • Universal time, which indicates the number of ticks since the universe was created (i.e. first start of game)
• A universe consists of multiple dimensions

Dimension

Spoiler

• Consists of a world and various orbiting planetary bodies
• Where planetary bodies are "How many suns and moons and other "orbiting" things do we render in the sky"
• Hence planetary bodies will likely only consist of a texture, phase, current position, rotation speed, etc.

Note: Mods can then query things such as the position and phase of MoonOne, and make the player turn into a werewolf upon a visible (position) full (phase) moon

World

Spoiler

• Has an associated sky (which is simply what texture to render. Maybe move this to dimension?)
• Contains variables such as:
  • World time (time in ticks since this world was created)
  • Time of day (might not make sense with multiple suns, but is essentially its 'rotation around own axis' time)
  • Any module defined variable that should be associated with the world (Ex: TicksUntilApocalypse)
• A world consists of regions
• A world does not execute terrain algorithms for chunks and blocks, but for regions (i.e. how regions are to fit together)
• A world provides a list of constraints that its regions must adhere to:
  • Type of climates allowed
  • Max/Min restrictions to each axis: X, Y, Z
  • What sort of region type each region is (Air; Underground; Surface; Sky land; Inverted Surface; etc.)

Note: For instance, a world will define if its macro climate is banded (similar to real life, with the equator being hot and the poles cold). Or some other shape, such as spiraling, or increasing in elevation towards the equator, or whatever.

Region

Spoiler

• A region represents a (probably cubic) collection of chunks. The number of chunks in a region and its shape should be whatever is most suitable for performance.
• Contains variables such as:
  • Region coordinates: X, Y, Z
  • Any module defined variable that should be associated with the region (Ex: RegionalSuperWeather)
• Has a heightmap.
  • I'm thinking this should be stripped out. It doesn't really make much sense in all region types, such as air, underground, etc.
  • Besides, the region doesn't really care about height, the chunks do. So as long as method exists for a chunk to fetch or figure out what it's height should be, then all is well.
  • If we go with cubic chunks and cubic regions (i.e. large world height), then it might make sense to implement this heightmap as a form of sunlight map instead. See MC cubic chunks suggestion.
• A region consists of climates.

Climate

Spoiler

• A climate is a unshaped collection of chunks, that all have the same climate characteristics.
  • Note: Coding wise it might be required to be able to directly point between a region and a chunk, without having to drill through the climate region. Smarter people than me will need to consider this.
• Contains the variables:
  • Humidity (Average % humidity for this climate)
  • Temperature (Average °C for the climate)
  • RainfallNatural events:
    • List of types of weather that can occur
    • How likely it is to occur each day
    • The severity if it does occur
    • Note: Again rainfall doesn't make sense for all chunk types (underground). But other things might, such as earthquakes, etc.
    • Note: Not saying the core engine must implement weather or natural events, just that allowance for their associated data be made. In most climate cases this will simply be "Rain" or just empty.
  • A list of all allowed biomes:
    • Assocaited chunks pick randomly from this list when being generated
    • For most climate types it will be only a single biome type (Ex: Tropical jungle). But for more alien/bizarre climates, might be multiple
• A climate consists of chunks.

Chunk

Spoiler

• A chunk consists of blocks.
• Is of fixed dimensions (probably cubic).
• Has a biome-type associated with it.
  • Note: I know currently biomes do not line up with chunks, but rather follow their own lines. And is done to give more natural appearances.
  • Note: The assumption here is that a cubic chunk will be small enough (say 32x32x32) to logically be able to assign it what climate it is associated with.
  • Note: The actual generation of the blocks, to give smooth transitions and defined borders that aren't all square, can still be done via another algorithm.
  • Note: Also, given that a chunk would be able to query the climate/biome-type of its neighboring chunks, it can do a gradient approach, so that there are no obvious hard lines.

Next time: MoSCoW list for what we want the world gen to actually be capable of.
The above lists and explanations is more to get the creative juices flowing, and provide a base off which to do the MoSCoW.

Then, after an agreed MoSCoW plan, I'll iterate back over the graph and explanation, and start doing more detail. (Specific variables and functions for each. Flow of data between classes, etc.)

 

[UberWaffe]

Design has slowed between me being back on site, getting some new games, and some new books.

So, only MoSCoW for now. Have to still design the data structure.

World Generation:

Spoiler

MUST:

• Be able to describe a universe with any number of worlds
• Be able to describe a world in terms of:
  • Its climates
  • Its overall shape
  • Its backgrounds (world bounding-box textures)
  • Its orbiting bodies
• Be able to designate areas of:
  • Specific climate
  • Specific topography/geology
• Be able to provide world description (or part thereof) to external code queries
• Be able to execute world/terrain generation in sections

SHOULD:

• Be able to use any compatible algorithm for defining areas
• Be able to use any compatible algorithm for block generation & placement
• Manage variables associated with the universe, or parts thereof

COULD:

• N/A

WOULD LIKE TO:

• N/A

Pretty straight forward requirements.
Hopefully the detailed data structure will be more interesting.

 

[Linus]

Nice and compact MoSCoW list.
You called it world generation, but I think the list describes universe generation.

What do you mean with the shape of the world?
Why did you choose to go for a world centered approach (world + orbiting bodies) instead of a sun centered approach (star + orbiting planets)?

 

[Immortius]

I'ld actually say the celestial relationship between worlds falls outside of engine functionality, and is gameplay functionality. The need to support multiple worlds is engine functionality though.

 

[Linus]

I might have been looking at it from a wrong perspective. The game universe doesn't have to follow same logic as the real world universe, as I was wrongfully assuming.

The Dimension definition in the previous MoSCoW makes more sense when I think of it like a mythological universe with a normal dimension, a hell dimension and a candy dimension.

Maybe it is a good idea to rename dimension to 'world collection' or something general like that to prevent any kind of assumptions being made on how exactly worlds are related to each-other in the engine.

Edit: 'world family' seems to be a more fitting term, as it tells you that the worlds in it are related to each-other, without saying anything about how they are related.

 

[UberWaffe]

What do you mean with the shape of the world?

Variables and methods that describe what the world looks like.
I.e. the ability to pick which algorithms are used for what (within reason), and supply them with input parameters to obtained tweaked results for the world.
Ex: An ocean world would increase the amount of surface that is water.

Edit: 'world family' seems to be a more fitting term, as it tells you that the worlds in it are related to each-other, without saying anything about how they are related.

'Dimension list' perhaps? I'll see what can be done with the semantics.

 

[Cervator]

World shape could also be quite literal - sphere, cube, donut, ringworld, and flatworld (not flat flat, but not round)

I like "World Family" since we've already got family in a place or two, but admittedly they might differ quite a bit at a technical level

 

[UberWaffe]

I've currently have universe changed into Teraverse.
Kinda gets the point across that it is 'everything', but also hints at the fact that it is not by default your 'normal' reality.

Also, I'm busy drawing up a spreadsheet of all the variables and methods for the various classes. Not going too badly. Probably will need loads of redesign, but the spiral of the design has to start somewhere...


Edit: Question, what would be the best way to represent the position of orbiting bodies (sun, moon)?
As two angles (horizontal plane and vertical plane) or some other form of coordinates to place it upon the sky-box?

 

[Immortius]

I have no idea what would be best for the skybox. I would suggest you would start a model in terms of a solar system and that would be used to derive skybox position though. What that model looks like depends on the detail you want to go for (ternary star systems? Non-circular orbits? Non-eliptical orbits?), but something like this would be my first cut on representing a solar system.

1. Star in the center. Every other body orbits another body, which may be the star (for planets) or a planet (for moons) or whatever.

2. Each body has a distance from the body it is orbiting, the angle of tilt of the orbit, and a speed measure of how fast it orbits.

3. Each body finally has the radian measure of its current position in the orbit, so 0 -> 2pi. This could actually be derived from a start time and current game time though.

 

[UberWaffe]

At the moment I am approaching the whole world data structure from the point of the player's view.
So that the way the data is stored is the way it 'appears' to the player how things are orbiting.
(I.e. even in real life we talk about the sun 'rising' and 'setting' in the 'east' and 'west' even though it is merely the earth rotating.)

So, if the game engine was to render the sun for the player, in a fashion that would it look like a sun, how would it do that?
Would it be a 2D texture layered over the sky background texture? (Two angles probably best)
Or would it actually be a 3D object rendered really-really far away? (X, Y, Z position probably best)


Sidenote: At the moment the approach is to allow as much freedom as possible for modules. For example, with orbiting bodies I allow a method for the calculation of the current position, that has the current time as an input. A module could overwrite the method and thus specify whatever orbital pattern they want, though the default method would do a simple straight orbit.

What the heck, I'll slap the design as I have it at the moment (not yet done) up, and have it garner some feedback...

 

[Cervator]

That looks awesome

Detailed analysis for me will have to wait a bit, but paging begla for skysphere questions since he might be playing with changing the moon(s) anyway

Edit: Looked at it a bit more. Not bad, nice view of stuff outside the world. Main bits missing is various phases for inside a particular world, like city generation, river generation, roads, etc. But then maybe that's too granular for that analysis

 

[Immortius]

UberWaffe : Are you aware that Terasology uses an entity system rather than a traditional object oriented class system for most game logic? Most of what you have listed there are classes should really be entities and/or components. And your methods are either systems (that would update those entities) or events. If you are not familiar with the entity system I advice getting familiar with it before jumping too low level in the design, although whatever helps with getting a feel for the way you want things to behave.

The sun and moon(s) are easy to do like that, yes. If you want to put planets in the sky box it is not so great though. The reason I would suggest a sun-centric simulation is because calculating the positions of planets in the sky is pretty awful otherwise - read about early astronomy and you can see all the crazy models they came up with to try and explain the movement of the planets as observed from earth. By simply modelling the orbits in around the center and then deriving their positions from that the maths is a lot simpler. This is all a gameplay decision though. Doing it earth-centric has the advantage you can do completely impossible planet movement, altered by ingame events (like moving the Eye of Gaia into the constellation of Doom).

 

[UberWaffe]

I've only started glancing at the Terasology code, since for iteration 1 I was mainly aiming at just fleshing out an idea of how it would all fit together. (I.e. "what bits do we have and what can they do?" irrespective of how exactly it is best programmed).

I've just started with iteration 2, which is taking the breakdown and fitting it into the Terasology coding approach.
So hopefully soon I'll have a design that actually ties up with how Terasology works.

I'm very new to the concept of component based programming, so expect a certain level of stupidity.

Off Topic:

Spoiler

While designing I had thought of a really simplistic way of modelling a basic form of structural integrity for blocks.
Each block type would have structural strength defined by three floats:

Compression = maximum weight of the block on top of me.
Tension = maximum weight of the block suspended from me.
Shear = maximum weight of each block attached to each of the sides of me.

Upon placing a block (event triggering only, no tick based repeated processing) it would check all the blocks it is adjacent to (i.e. connected to).
It would then take its own weight and start 'distributing' it.
First, it would check the block below, subtract that block type's compression value from its own mass.
If it still has mass left, it will check the block above, and subtract that block type's tension value.
If it still has mass left, it will check the blocks adjacent, and subtract each block type's shear value.
If it still has mass left (i.e. > 0.0) then the structure fails and the newly placed block breaks and falls.
And in the case that there was a block beneath it, that block also breaks and its adjacent blocks do a recheck of the structural integrity. (Leading to a possible cascade).

Anyway, entirely off topic.

 

[Cervator]

Your off topic bit is pretty close to my block integrity desire, although yours focuses more on in-place calculations of more detail, which may beat my hackier block-level variable which records integrity based on neighbor blocks, slowly weakening with height (so no infinitely tall iron columns). We should put a proper design together for it in its own Incubator sometime

And yeah I sort of figured the methods and variables above were more illustrative than exact. Was more interested in the areas they touched. The level of detail could be reduced and the scope increased to cover other generateable stuff (city/river/roads/etc), although I suppose at some point we're just talking about plugging arbitrary generators into appropriate phases.

 

[UberWaffe]

Still busy reworking the design to fit the entity & component & system approach.
Certainly makes a lot more sense, since it quickly becomes apparent how much re-use you get out of generic classes.
Also, utterly surprisingly, nearly exactly how we approach and program industrial control systems in real life.
Never knew the method was actually a mainstream approach, with like 'proper words' associated with it. Instead of 'that bit' and 'this thing'.
And here I was thinking I'm clever and unique.

Anyway, iteration 2: "The composite approach" graph.

 

[Marcin Sciesinski]

TimeOfDay has no sense with multiple stars or no star at all. Unless there is always exactly one star in a world. I'm not entirely sure though, why would you need TimeOfDay construct at all. It's probably better to be able to query a world for a number of celestial bodies and then for position of each such body.

 

[UberWaffe]

Marcin Sciesinski I imagined the TimeOfDay to essentially be the same as "What is my current rotation angle around my own axis?"
Mainly because I envisioned that you would require that information to properly query what your point of view is.
A simple float would likely suffice, except that I figured a class would allow for more variety (think mythological or unnatural worlds, or ones that spin around more than one axis).

Do you feel that this is unneeded?
Also, can the naming "TimeOfDay" be improved?