Showing posts with label mods. Show all posts
Showing posts with label mods. Show all posts

Monday, September 15, 2014

Geology Simulator - The Shape of the World

(Part 1 HERE)


THE SHAPE OF THE WORLD

Earth is a sphere. Due to their inability to fit rectangular grids, spheres are really difficult to work with in a program, though. Also, I'm making this geology engine for games that use rectangular environments anyway. So I'm not going to use a spherical planet. Instead, I need a different shape that satisfies the following criteria:
  1. Easy to translate neatly into a rectangle or rectangular prism
  2. Convenient to write code for (well defined, orthogonal dimensions)
  3. Only one continuous surface, so that plates can smoothly glide anywhere and LOOK like they developed on a familiar spherical world
The best shape I've discovered to fit the bill is a "torus." It looks like the image below. Notice that it has rectangular grid cells all the way around, nice perpendicular dimensions, no annoying poles where everything comes to a point, minimal distortion of the cells (which I can just ignore), and a single smooth surface:

(image by Dave Burke)

You can also turn a torus into a rectangle easily. Just slice along where the red arrow is and where the blue arrow is, unfold, and you have a rectangle of surface, or a rectangular prism if you keep the thickness. In fact, we don't even really have to run our program as a torus, we can just use a regular 2-dimensional matrix, where things that go off the edge are assumed to show up on the opposite side. This is just a another way of looking at (projecting) the skin of a torus:


There are a few differences from a sphere for world simulating purposes. For one thing, cutting around either entire circumference (red or blue arrow or similar), unlike a sphere, does NOT divide the world into two plates. You need to make two cuts like that (red vs. blue plates below). Alternatively, you can carve out a chunk with one single border that does not wrap all the way around (green plate below):


Rectangular and toroidal versions of the same
tectonic plate situation (sorry the number of
cells changes, ignore that)

Another difference is that north and south are not destinations like on Earth, where you're as north or south as you can get. Instead, they are just like east and west: they're just directions of travel only, that go forever, looping around. The red arrows in the first image represent north and south, the blue arrows east and west.

CLIMATE

Finally, climate would be very different than on a spherical world, and climate matters for geology (glaciers, frost wedging rocks apart, etc.). I should only take this into account, though, if the game world is actually supposed to be a torus, not if I'm just trying to simulate a sphere. So I will probably just cheat and overlay a sphere's climate. But if it were actually supposed to be a torus, I believe it would look something like this:


The inner portion hardly ever gets sun, and is permanently iced over. The top and bottom of the planet suffer extreme temperature swings, with the sun never setting for half the year, and in darkness the other (if tilted like Earth is). Temperatures might be near boiling and then a hundred below across seasons. Plants can't live here, so the rocks are barren (migratory species might spend some time in the area to breed or similar, and sealife is sustainable. Very hardy annual plants might survive). On the very outer edge, the climate would be similar to Earth's temperate zones (like Europe), but with a double speed cycle of seasons. This is easily survivable year-round, and plant life is sustained here.


I'm no meteorologist, but the weather should also be different. The seasonal instead of daily temperature fluctuation would either make more extreme weather (due to the larger difference) or less (due to less turnover/mixing things up), I'm not sure. This is something to keep in mind if I want to simulate an actual torus world later when I get to erosion parts of the model.

PROGRAMMING STUFF
(Non-programmers: worth skimming, but don't worry about the details too much)

Organization


I'm writing this in C++, so in order to define the world's shape and behavior, we also have to start thinking about the world's major object classes. As of right now, I'm carving the physical world into the following organizational classes (there are also custom vector classes and things not mentioned):

WORLD: The whole world stores the plates in it and its dimensions. It also keeps track of the time. It has many important methods involving interactions between plates, like actually determining how far plates move together, which boundaries subduct versus crumple, and how much pressure and resistance plates get from the direction they try to move in. 

VOXEL: A voxel is a 3D cube that is the smallest size that would be seen during eventual gameplay. Such as a single block in Minecraft. These are not actually simulated during geological timescales.

GOXEL: A goxel (geological voxel) is a 3D cube that is the smallest size considered during geological simulation. I'm likely to change how many voxels make one goxel as I go, and have it later be a user-defined parameter. 16x16x16 voxels is a good starting point. Goxels don't do much, they mainly just store information about material types, temperature, pressure, etc. and get pushed around by other methods.

COLUMN: A column is the smallest size unit in the 2-dimensional rectangular projection of the world. It is a stack of some number of goxels (the thickness of the crust changes in different places around the world). Columns do various things as a unit that makes them a useful class. For example, they float on the mantle of the planet, and this can cause stresses that cause them to crack away from neighboring columns and cause fault lines. They're also convenient for erosion and other things, like efficiently swapping real estate between plates.

PLATE: A plate is a collection of columns. It gets moved by the world object, but it does various other things itself, like checking the buildup of pressure under the crust to calculate the likelihood of splitting into two plates (more likely the bigger it is) it also checks for whether columns have managed to create so many fault lines that they have effectively made a new plate.

REGION: Possibly a generic "region" superclass that has methods and variables relevant to keeping track of areas of the world that have other areas inside of them (i.e. all of the above except voxels).



Input

Whenever possible, I am going to attempt to make every constant number in the whole program come from a user-variable text file, which will be the main source of control and input, for a good combination of user friendliess and coder friendliness (I hate GUIs, especially in C++).

Output

I'm probably going to output as color coded image files or ASCII for now. One of my design principles is definitely to have all of the output be modularly separate from the simulation code, though, so other people could swap it all out later.

NEXT TIME


I'm going to try to tackle just plate tectonics alone first. Plates splitting, moving due to new rock in ocean ridges, slowing down as they smash into things, deciding to subduct or not, etc. I will keep track of crumpling or uplifting of rocks as just numbers for now stored in columns ("7" = more crumpled rock is sitting here than "3," etc.). Same for volcanism. I can use these to output colorful pictures and get an idea of whether it looks reasonable or not. Actually storing more useful versions of that information can come later.

Wednesday, September 10, 2014

A Geology Simulator for Game Worlds


THE STATE OF THE ART IN SANDBOX WORLD GENERATION

Unless you've been living under a rock for the last several years, I'm sure you've at least heard of the game Minecraft (and if you have been living under a rock, don't worry: you've been getting a very similar experience). 

The game uses a procedurally generated 3D world of blocks. You run around freely in a world that looks like the one below (default Minecraft) and dig and rearrange blocks to build things, such as the luxurious dirt hovel I put together especially for this blog post.

(Terrain generator by Markus "Notch" Persson)

(Built by yours truly! I also made this, by the way.)

I played minecraft for several years, as part of a server full of 20-40 year old nerds (the Voxelbox). We were not terribly impressed by the default gameplay, controls, or creative options. However, we did recognize an excellent core concept and a very modifiable set of bones to the game. We went about making a variety of tools to ease the creative process, allowing of course infinite free blocks, building from a distance, boolean shape logic, smoothing operations over thousands of blocks at a time, etc. Basically, the goal was 3D multiplayer photoshop. We eventually ended up being able to make landscapes like this:

or


BUT CAN I PLAY IN IT?

As nice as these end up looking (for a voxel engine), they doesn't really function as anything more than essentially a 3D painting on the wall. What if we still want to play the actual game?
  • The custom landscaping is only a thin veneer for looks. You could never play an actual game on this landscape that involved any sort of digging under the surface. It's all just solid gray down there.
  • It still takes hours of hand sculpting to make a section of land like this. It's fine for a proscribed experience like Skyrim, but not procedural games.
  • They're made by fantasy artists, not people who actually know anything about geology (or biology), so these scenes still tend to lack a lot of realism even at the surface, something a mining sandbox game should probably care about.
What if we just forget it when we want to play the game, and use the vanilla terrain generator? Well, even though Minecraft does a somewhat decent job of procedural surface terrain, its underground situation is just plain terrible. When you cut open the world, it's little more than a random jumble of uniform gray "stone" and caves and such. Clearly this has no geological realism to it:


Considering that the game involves spending a huge amount of your time underground--you know, mining--this becomes a serious drawback of game design.  Other games, like Dwarf Fortress also heavily focus on 3D procedural worlds. Dwarf fortress does a better job of realism, including some layers and stone types in somewhat reasonable locations:

(Terrain engine compliments of Tarn Adams)

...But we are still looking at completely flat, fairly random jumbles of rock types, mostly shallow, rounded, boring mountains, perfectly straight vertical volcanoes/tubes pasted abruptly into the landscape with only 3 feet of obsidian around them, and no correspondence to any broader geological history, other than putting the broadest categories of rock in roughly the right order.

A significant improvement is needed. I plan to attempt this by making a terrain generator that simulates actual geology, rather than faking an end product with simple fractals like these games do. If successful, this should exceed the realism, variety, and gameplay richness of the current leading games in the sandbox genre for world generation, both above and below ground.



TO MAKE A REALISTIC GEOLOGY ENGINE FOR GAME WORLDS


I am planning on implementing the following features for a geology simulator:
  • Proper plate tectonic-based continental history. Actual world plates will move around in a simulated history, collide, subduct, join together, break apart again, etc., forming realistic mountain ranges and continental shapes and compositions.
  • Bouyancy of plates causing bending, uplift, and fault lines.
  • Rock strata that curve in 3D when appropriate, for example when plates crumple together.
  • All continents come from somewhere. The world begins as all oceanic plates, and any continent can trace its history back to simulated volcanism, uplift, etc.
  • Realistic volcanism, with volcanoes of different types appropriately existing along corresponding plate boundaries. 
  • Magma is modeled underground and may not reach the surface, instead bubbling up in intrusive plutons that solidify into granite for example.
  • Metamorphism occurs from actual simulated pressure or heat from geological events.
  • Erosion follows (simplified) watercourses, weather patterns, and frost wedging.
  • Different rock types weather differently, leading to certain interesting and realistic features like Yosemite's Half Dome.
  • A rough simulation of life as it is relevant to geological history at first (for iron oxidation, mass extinction coal and oil layers, limestone formation, etc.), as well as more detailed climate and biome types added at the very end of the simulation.

The goal is to get cross sections that look more like the below image, with obvious geological features like this old, solidified lava tube, volcanic cone, sedimentary rocks filling in above over time, and the oldest rock strata down below pushed apart into curved blisters when the ancient magma forced its way between them:


(pixelated version: this is lower resolution than would be used)


NEXT UP IN THIS PROJECT

I'll lay out my plans for the basic framework of the world (and of the program, written in C++), including the main data storage types, the shape of the planet, and some other high level planning.

Later on, I'll dive into large scale plate tectonics by themselves as the first major benchmark to get working.