Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GavJ]

The goal of this project is to have a 3rd party application that generates geologically realistic worlds for all sorts of voxel-based games like dwarf fortress or minecraft or others. The worlds will have actual plate tectonic history, volcanism, sedimentary stone that actually comes from eroded sediments, etc. This would be a very significant departure from any games I'm aware of, dwarf fortress included, which tend to just use fractals and maybe half-hearted shuffling of materials in lieu of actual geology.

Why? Two main reasons:

1) I believe that any game is much more fun, stimulating, and satisfying when the player's skills lead to success more so than the character's skills. Realistic geology means that people can actually prospect resources in their environment and gain advantages and overcome challenges through real scientific approach and cleverness, not by having a level 30 prospector or by dumb luck from clicking a lot. To a lesser extent: following veins intelligently, knowing what landscapes may be more or less stable for cave-ins (if a game simulates it), etc. This sort of thing seems like it should be a primary goal in any game revolving around digging and mining, and I'd like to enable that.

2) Realism and attention to detail have value in their own right, in the form of both better immersion in a role playing environment, and inspiration to learn and explore (whether it be actual or fantasy geology / geography).

I am running a devblog of the project at the link above, amongst other things. The list of posts specifically related to this dwarf fortress-relevant project, though, I will maintain here:

          Part 1: A Geology Simulator for Game Worlds
          Part 2: Geology Simulator - The Shape of the World
          Part 3: Geology Simulator - Plate Tectonics
          Part 4: Geology Simulator - Minerology and Petrology Systems

This is a thread for updates relevant to this community, but also by all means please provide any feedback you have! Share any ideas or whether you care about some features more than others, things I may be doing wrong or inefficiently or whatever, etc. I'd love to hear and discuss any of it.

[CLA]

I believe that any game is much more fun, stimulating, and satisfying when the player's skills lead to success more so than the character's skills.

I think there needs to be some abstraction (some player skills just don't translate well into specific games - physical traits), and I think ideally there should be some way to choose which "skills" you want to tackle as a player, and which you want your character to have (for example the difference between adventurer mode's shift+Attacking and just moving into someone); but I generally agree and It's always really frustrating for me if a game doesn't recognize player skill/knowledge due to whatever limitations.

Just curious, what are your qualifications? Geology background?
Do you plan to integrate procedural creature generation (read: evolution simulation) or keep track of necessary data structures?
I'd figure you'd need information for natural borders, how they change over time (splitting/merging plates, emerging mountains, islands, seas), and their properties (temperature, precipitation, drainage, etc); On the other hand, creatures in turn would influence the geological process to some degree: Erosion and climate stability depending on vegetation (and plant damage from large populations) coral reefs, limestone, coal and chert sediments. Not to mention finding index fossils! That would be awesome.
Though I'm not sure how much you have to abstract away for something like that to work reasonably.
In either case, these are probably features you can think about once you have a more or less functioning simulator.

Another question, how will you integrate this with DF? Just output it as regular world?

Anyway, I'm really looking forward to seeing this progress.

[GavJ]

I think there needs to be some abstraction (some player skills just don't translate well into specific games - physical traits), and I think ideally there should be some way to choose which "skills" you want to tackle as a player, and which you want your character to have (for example the difference between adventurer mode's shift+Attacking and just moving into someone); but I generally agree and It's always really frustrating for me if a game doesn't recognize player skill/knowledge due to whatever limitations.

For my purposes, this is more the responsibility of the game using the map. If they don't want any geological detail, don't use the app. If they want a little, then use it but implement "Scanners" or whatever to give superhuman information about the landscape so you have to realize fewer things yourself or take fewer risks. As long as the data is there, you can hide as much or as little as desired.

Just curious, what are your qualifications? Geology background?

No I am a cognitive psychologist, but almost everything relevant to this program is going to be very far from the bleeding edge of geology. The most recent post on mantle convection was probably the only thing that would be controversial in the field, and it's several steps removed from what a player of an end game would see in their rocks, so I'm not terribly worried about it. And it can be revisited if needed.

Do you plan to integrate procedural creature generation (read: evolution simulation) or keep track of necessary data structures?

Life is probably more of just a categorical simple thing for most of the simulation like: none, then simple chemotrophes (which fix carbon that matters geologically), then photosynthesizing (which starts affecting oxygen levels), then eukaryotic (which starts making shells and limestones and things), then land life (which will contribute to erosion or lack thereof, global temperature, and fossil fuels, etc.).  That sort of level of detail.

At the very end, I'm not sure. It could populate in specific plants, or it could just save data about rainfall and temperature and soil and so on, and leave that as an exercise to the game developer at the end. I'd prefer the former, but it may be beyond me.

Index fossils are a really cool idea! Again, it could range from specific fossils, though, to just "here is the data you would need to know where to insert your own relevant index fossils, Mr. game developer" or somewhere in between.

Another question, how will you integrate this with DF? Just output it as regular world?

I am led to believe that dfhack (from asking their IRC channel) can pretty much already just change any tile, possibly even just using a modified existing tiletypes script. So after embark, you sould be able to read from a geological world file and just replace tiles one by one, with fairly minimal porting code, until the whole map is an equally sized section from the 3rd party app.

[CLA]

Life is probably more of just a categorical simple thing for most of the simulation like: none, then simple chemotrophes (which fix carbon that matters geologically), then photosynthesizing (which starts affecting oxygen levels), then eukaryotic (which starts making shells and limestones and things), then land life (which will contribute to erosion or lack thereof, global temperature, and fossil fuels, etc.).  That sort of level of detail.

Yeah, that's what I had in mind. I don't think it's necessary to model individual species. It's enough to have data like "this tile currently produces that much oxygen; reduces erosion by that much; leaves that much lime, and that much coal"

I am led to believe that dfhack (from asking their IRC channel) can pretty much already just change any tile, possibly even just using a modified existing tiletypes script. So after embark, you sould be able to read from a geological world file and just replace tiles one by one, with fairly minimal porting code, until the whole map is an equally sized section from the 3rd party app.

It seems to me creating the world like Perfect World does would be a good starting point, only using dfhack for things that can't be saved in "world files".

[Orange Wizard]

Wosting to patch.

[GavJ]

A question for my intended audience:

Currently, I'm working on a system for individual voxels (geological voxels are abstract but something maybe like 16^3 or 32^2 game tiles) to keep track of their chemical makeup of the 8 major elements in the crust, textures, temperature, pressure etc, in a continuous fashion, which works decently well.

But for certain things, like melting point or density, I can't just predict from the mixture of elements or pressure alone. I need to base on real world data, because it depends on crystal structures and stuff that would be insane to program in. So for real world data, I can do that in two ways:
1) Make something like raws for every mineral, and then make a system that takes any given chemistry and situation and finds the nearest neighbors by features and extrapolates remaining properties based on those anchor points of real data from prototypical rocks, or
2) I can just hard-code in rules and tables for earth minerals, and do lookup tables basically. Easier, faster, but totally uncustomizable.

My question is: would anybody using this program give a damn about altering their own custom minerology? Like doing xenogeology or something? If so, must be #1. If not and Earth rocks are all fine, then I shouldn't waste my time on that.

[mifki]

I expect people to vote for more modding possibilities:) But for me Earth-only geology is fine. And yes, VERY interesting project.

[Orange Wizard]

I think I'd prefer having the ability to mod it, but I'm not sure if I'd ever actually do that.

For demonstration/proof-of-concept purposes, I believe a hardcoded lookup would be fine.

[Putnam]

In my experience, moddability of that kind is better simply so that stuff can be modified more easily down the road. While it's unlikely that certain classes of rock or certain minerals are going to change in physical properties anytime soon, it's still good to have an easier way to add stuff.

[CLA]

It sure would be nice to have the data not hardcoded; but I think it's not a priority, and it would be nice just to get the program to a reasonable state faster.

[jwhite.df]

I'd imagine you'd want to not hardcode things because of fantasy minerals. Adamantine, for example. I'm imagining a world where some earthquake exposed a deep layer, and 3dveins of adamantine are exposed by everything else being weathered away (like Monument Valley. Except with adamantine).

[GavJ]

Okay, I'm settling on an intermediate solution that should be good enough.

I need to enforce the same classes of rocks as on Earth anyway -- because those have to be there for most of the rest of the simulator to make sense. Igneous versus sedimentary for example. So there's no reason for me to calculate neighbors for the entire possible variable space, because there are hard logical boundaries within it that divide the space of rocks into several smaller 2-D spaces.

That makes it fast and efficient enough to just search for nearest neighbors without it being a whole big problem, so the actual specific rocks and minerals can be in raws. (searching distances in 5 2-D spaces is way the hell faster than a 10-D space).

But within those constraints, you can decide that schist and gneiss are no longer meaningful metamorphic categories, remove them, and add in your own superwondermagicmetamorph in that same pressure/temperature space (relevant to metamorphism), and it will correctly interpolate around that point.




This seems plenty sufficient, because what would it even mean to have a custom rock that erodes differently depending on pressure and temperature, for instance? (crossing over between the variables of the different search spaces). No logic or need for that.

[GavJ]

Organizing my thoughts anyway, might as well share:

So to search for a rock's hard to predict properties and its name (weathering resistances, density, melting point, name), you look it up in small lookup tables according to the following flow chart. Spots in between raw entries are filled in at startup with appropriate blends of nearby neighbors in that subspace.

Sort by major class first:
a) Igneous Extrusive -- Lookup the rock in a dynamically generated table of "deep chemicalspace"* (16-bit)
b) Igneous Intrusive -- Same, but a different table than extrusive.
c) Sedimentary -- classify by flags into biological, chemical, or clastic first:
   Biological: By default there is only one kind, which is lignite (further coals are metamorphics of lignite and limestone is treated as chemical). Lignite will occupy part of an abstract "biological space" of which it is the only member by default. But if modders wanted to have 3 kinds of special separate coal series, they could use that bio-space to separate them and define as they please (i.e. coming from different soils, also eventually customizable probably to perhaps themselves come from customizable types of lifeforms.)
   Chemical: Lookup by dynamic table of deep chemical space only (limestone, halite, gypsum, etc.)
   Clastic: Lookup in a 2-dimensional table of grain size by deep chemical space (This table is bigger than all the others combined at ~15 megabytes, still reasonable probably).
d) Metamorphic -- begin by using special flags that keep track of what major type (of the other 3) the parent rock was. Each of the three have their own 3-D lookup tables: highest temperature on record as of last metamorphosis (4-bit) x highest pressure as of last metamorphosis (4-bit) x shallow chemical space** (8-bit), still < 1 megabyte each. Rocks can be double or triple listed in the different tables -- for example, high grade metamorphism gneiss doesn't really care what the original rock was, all that texture has been smashed out, so it just gets repeat-listed in the raws to represent that.

*16-bit "Deep chemical space:"  (whichever is closest to actual value)
Oxygen: 3 bits, 0-7 each step represents step*10% by weight -- helps classify everything
Silicon: 3 bits, 0-7, non-linear space, by step: 0%, 15%, 20%, 24%, 26%, 28%, 30%, 32%, 40%  (the narrow, highly sampled range is crucial for bouyancy and many classifications, and pure quartz only gets up to 47%) -- mafic versus felsic rocks in middle, and 0% / 40% are generally crystalline minerals of different kinds
Aluminum: 2 bits, 0-3, 0%, 10%, 20%, 30% -- paraluminous rocks and feldspars
Iron, Magnesium, Calcium: each 2 bits, same as aluminum. -- all sorts of mafic rocks, ores, and limestones, etc.
Alkali metals (sum of sodium and potassium): 2 bits, 0-3, 0%, 3%, 6%, 9% -- mostly indicates feldspar type, also giveaway for halite (9% and everything else 0's)

**8-bit "Shallow chemical space:" At startup, take all of the rocks defined in the raws in that search space, and procedurally determine the most diagnostic single cutoff for each individual element (the level at which closest to half and half of the raws fall on the two sides). Define that for this run of the application as 0 and 1 for each chemical. For silicon, allow 4 steps, attempt to equally divide raws amongst them, and give it 2 bits.  Total, this all now adds up to 8 bits, keeping the metamorphic search spaces reasonable (otherwise they take up half a gig)

Toy example including only silicon and oxygen, being made into shallow version:

Note that it doesn't have to perfectly divide like this. Still just one of three metamorphic classifying dimensions.

[Rose]

This could go places.

[Vattic]

Glad to see the level of detail you are using.