E Unibus Pluram

The most recent thing I've done in my world simulation is to break up the 1:1 correspondence of languages and nation-states. Each tile on the map can now contain any number of different population communities, each with its own racial makeup, language, national identity and "culture" (for the moment, just a flag indicating whether or not they use agriculture), and each state is a collection of tiles.

States start out tied to a single language, nationality, and racial composition, but as populations expand and intermingle, these change: small speaking populations switch to more common languages, racial compositions converge, and communities take up agriculture when surrounded by other farmers.

Conflict and trade decisions are still made at the state level, and states can still expand and break up over time, though these mechanics both affect and are affected by the new variables. Polyglot states tend to stay that way, but if a state with a strong dominant language absorbs neighbors, the conquerors will either convert people to the dominant language or find their own language subsumed into the conquered's (if a resource-rich state is able to conquer a more populous one). When nations break up, the lines of fracture are more likely to fall along national and linguistic lines, which has the potential to have states overextend imperialistically and then balkanize.

I think one missing possibility here is when there are a bunch of adjacent fellow national/linguistic minorities in distinct neighboring states (Kurds would be a real life example): they should be able to break off together into a new state (or be absorbed into a similarly composed neighbor), but right now the decision about whether a state can break apart is based only on its own size.

This screenshot highlights the state of Ridhef, in which after 50 years of history, its founding Rid people still constitute the majority, at 61% of the population. They speak three dialects of their original Ridchiz language (languages branch into dialects when their speaking populations are cut off from one another).

The Ungyech are a sizeable minority of 17% (their original state was probably conquered), and while many speak one of the Ridchiz dialects, others speak Ugea (not sure if that is their original language, as languages are currently named by adding a suffix to the nationality name and "Ugea" seems pretty far from "Ungyech").

Also significant are the Thithe and Wid people, at 10% and 9% of the population respectively. Thithes speak two different Ridchiz dialects as well as five dialects of E'pez (again, not sure where that came from, does not seem etymologically related to "Thithe"). Wids mostly speak three dialects of their original Widmi language, and some speak Ridchiz.

There are three more small minority nationalities, whose populations probably migrated rather than being conquered: the Se speaking their original Sebezh, Echash speaking Ngiegem and Ethe speaking Neqe, though only the Se don't have a majority speaking Ridchiz.

Code.

Making History

The next phase of the planet simulation involves the history of people on a smaller scale. First, every terrestrial hex tile is subdivided by two levels, from its prehistorical status,

to a view with national boundaries along finer boundaries (two "steps" finer, roughly 120km apart, versus the coarser tiles separated by about 365km):

The next step is populating each tile with flora and fauna, based on the local climate (lighter tiles support more species):

Nations are created by picking random capital tiles probabilistically based on the tile's characteristics (climate, whether its population is agricultural or not), then assigning other tiles to a capital based on proximity modified by local concerns (mainly terrain features, like what Martin O'Leary describes here).

Each nation gets its own language, currently just a word for each species within its bounds; they evolve through sound changes and borrowing words from other languages (through trade or conquest). There's a separate mode to play with languages:

As time advances (also on a smaller scale, 25 years or a single human generation, per tick), nations trade with neighbors when they can benefit mutually, merge together when one has the strength and reason to take over another, and split up when they get too big. Languages borrow words for species as they encounter them (through trade or expansion).

Here's the same world from before, 450 years later:

The yellow highlighted area shows one huge nation that's selected, with part of its language visible in the detail panel on the bottom. Dark green tiles are boundaries between nations with trade relationships and dark red ones represent unresolved conflicts.

Code here.

Gridding the Sphere

While trying to dig up an awesome tectonics simulation I had found before (it was Tectonics.js, and it is even awesomer now than it had been when I saw it before, with a plausible ocean crust simulation that drives the tectonics), I came across Andy Gainey's planet generator, and he took a really cool approach to the problem of tiling a sphere in hexagons.

Basically, he found the bunch-of-hexagons-with-twelve-regularly-positioned-pentagons grid aesthetically offensive, and solved it by introducing a bunch more random irregularities, replacing a number of clusters of four hexagons with pairs of pentagons and heptagons. Basically, the twelve extra pentagons are still in there, but they disappear among all the other new irregularities, and it ends up looking really cool:

Anyway, a neat idea.

The Humanity

I recently picked up my old planet simulation code, which a couple years ago I had modified to run on a mostly-hex grid. I think I just got busy at that time and stopped working on it, but also was frustrated because, after the hex change, it was running too slow to make the evolving world much fun to watch.

My initial thought recently was to port the simulation to C++ so it would be real fast and hence fun again, but I quickly realized that the main source of slowness was just rendering, so I fixed that enough to make it fun and now I'm still just hacking away in Python.

I added a human population simulation: once a world has life, there is a probability that humans will pop up on some savanna, and then they spread out from there, initially sticking to amenable climates along the coast and then becoming more dense and spreading out when they develop agriculture. All of this takes place on a much shorter timescale, so tectonic plates have stopped moving and glaciers are advancing and retreating.

Here is some early humanity (light yellow-gray in the lower-right) in the midst of a glacial period:

;

here is how they spread out to other continents as glaciers retreat:

;

and here is how the population explodes when agriculture pops up (the brighter yellow) as glaciation hits a minimum:

.

This is the new slow point (~10s per simulation step), which gets frustrating, but maybe that can be improved.

The code is now officially GPL.

Hextonics

Updated the old tectonics simulation to work on the mostly-hex grid. It was relatively painless: most of the codebase had been written with the idea of "tiles" on a planet just being points on the unit sphere, each with some arbitrary number of neighbors.

The climate model, such as it is, was pretty much hacked in from earlier experimental code that had made more assumptions about data structures, so there was some refactoring to take care of there. But otherwise it seems to work like before, just on a bunch of hexes instead of a bunch of rectangles.

Two sides of a planet:

Source here: https://github.com/tps12/Tec-Nine/commit/2f49be89c5d36a5ca1b8236e9aa6044d51ee4a9d

Tiling a Sphere With Mostly Hexagons

I saw this thing where a person generates planets using a grid that looks like a bunch of hexagons: https://github.com/vraid/earthgen-old

Hexagon-based grids are popular for things like strategy games, because adjacent tiles are separated by a constant distance. I used the math from vraid's code as the basis for a demo of this kind of tiling system. This video shows sphere tiled with RGB colors based on each tile's vector location on the unit sphere, and a 2D detail view for navigating around a local region of the grid:

The grid starts as a dodecahedron (made of twelve pentagons), and each vertex is squashed into a hexagon to produce a soccer ball shape. That process is repeated to create each higher resolution grid. This video demonstrates the process, sampling from ETOPO1 data to color each tile:

One really cool thing is that you can define these grids lazily, with hex locations determined for only a small region of the sphere at a given resolution.

You can imagine a game where an entire planet's climate is simulated with 500km tiles, the weather for a single continent is simulated with 10km tiles, battles take place on a grid of 10m tiles, and hand-to-hand combat on a grid of 1m tiles. (The memory cost to store even a single byte of data for each tile of a planet-sized sphere at this resolution would be prohibitive.)

This video shows a grid lazily subdivided to achieve this kind of resolution, using a noise function to color the tiles:

As mentioned above, the grid begins as a grid of pentagons. At each iteration of the vertex-squashing process, the previous grid's faces are carried over to the new one with the same number of sides and centered at the same location on the unit sphere; while each of the previous grid's vertices becomes a hexagonal face of the new grid.

As a consequence, the twelve initial pentagons can be found in the grid for each resolution. Trying to render these in a 2D local view can be challenging as they necessarily break up the hex grid. This video shows one option (other people who have talked about these kinds of grids, again in a game context, have proposed putting mountains or seas or some other inaccessible feature around each of the pentagon locations, to avoid having to deal with this entirely):

Code for my demo program is at https://github.com/tps12/hey-grid. Also vraid appears to be rewriting their code in Racket, which is interesting.

Geologeez Nutz

Not done anything lately on tectonics simulations, but I realized that there was a bunch of crap I'd done last fall that I had never posted about, so thought I'd describe it, to remind myself where I left everything if for no other reason.

The main change was making tiles have layers of rock instead of just single elevation values, and different rock types for each layer.

The first continent is a hunk of igneous extrusive rock of varying composition, and the planet begins with no atmosphere or life:

When the atmosphere kicks in then you get erosion, which varies based on climate and grinds layers from the top down to create sedimentary rock of progressively smaller grain sizes.

When life shows up there is an additional organic component to sediments, which makes limestone and chalk in the right environment that can in turn make marble, though probably too rarely. Life marks tiles as having peat bogs where it makes sense as well, so there's the potential to figure out where fossil fuels end up.

Crustal thickness leads to regional metamorphism, and subduction causes igneous intrusions with associated contact metamorphism. Erosion affects rocks based on how tough they are, so fresh mountains should grind down to craggy hornfels and granite shields should eventually emerge.

The merging of tiles due to the constraints of math on a sphere tries to preserve uniqueness, so peak elevations and metamorphic layers don't get averaged away. Not scientifically justifiable, really.

I added the ability to click on a tile (in the Mercator and Sinusoidal projections) and see the layers of that tile, with a tooltip showing the full composition of a given layer. I also added the crappy "color" display mode that mostly just suddenly turns green when life shows up and then shows you where mountains are:

I also did some profiling that led to some optimizations, mainly around the bogus climate model but also caching various calculations that were repeated all over the place. This got things moving quick enough that I could start thinking about supercontinent cycles again, but none of the various forays I made into getting any of that to work out nicely panned out.

The other improvement in the offing is figuring out metals, basically banded iron formations and the veins of stuff that go along with igneous intrusions and create placer deposits when they erode.

Also found a dude on Reddit who has a similarly-conceived project, pyTectonics. He's taken a more scientifically rigorous approach and does things on a Fibonacci grid, which looks pretty awesome. I'm not exactly sure, but it also sounds like he creates and destroys new grid points as needed, which is a cool idea.

Edit: Forgot to link to the source.

My Christmas Vacation

Mountain? Climate!

I had put together a crappy climate model before I had really read anything about meteorology: basically, vary insolation based on season, have prevailing winds pick up moisture from the sea and rain it down according to elevation, and then use the results to classify the climate.

So no meandering jet streams or mid-latitude cyclones or anything, but I've had enough trouble even figuring out where to start on a more legitimate climate and weather simulation that I decided to just bring the old broken one into the tectonics simulation as a placeholder.

Here's my fake climate simulation at work:

.

Note the great Saudi Arabian jungle, the desert in the Southeast US (but not the Southwest), the frozen British Isles, &c.

So despite the brokenness, I wanted to get some sort of climate system in so it could contribute to the erosion algorithm, modulating the erosion amount from each tile by its annual precipitation and "polar" status (on the theory that glaciers cause a lot of erosion regardless of precipitation).

Compare erosion under the old algorithm (reddishness represents height lost to erosion, greenishness height gained by deposited eroded sediment):

;

versus the new erosion modulated by precipitation:

.

I had to tweak a magic number that had been picked to keep mountain building and erosion somewhat in balance. But after that, a newly created world came out looking pretty good:

;

and its "climate":

.

In any case, it doesn't really change the current simulation very much, but it does lay the groundwork for some more interesting recording of geological history. Source.

Fixing a Hole

My previous "plates on a sphere" simulation tended make continents that were too round. This was because of how I tried to resolve an issue stemming from my whole approach to the spherical geometry.

The sphere is divided into "tiles" of approximately equal size, each with a fixed location (a vector on the unit sphere). So at any point in time, a continent is defined as a set of those tiles.

When a continent moves, the vectors of all of its tiles are moved (that is, rotated around an axis) by a given amount; then the closest tile to each of those resulting vectors gets the value of its source tile.

Because of how the tiles are distributed (near the equator, almost a grid; at the poles, not anything like a grid), there is never a neat 1-to-1 mapping of source to destination tiles (unless the continent is centered on the equator, moving due West or East).

Which means there are lots of instances of more than one source tile mapping to the same destination tile, and tiles that are visibly part of the continent in its final position but that weren't mapped to by any source tile, and thus appear as holes.

My previous solution to this problem had been, at each step, to map each source tile to the nearest two destination tiles; to prevent the continent from growing out of control, I then trimmed off a bunch of tiles, starting with those most distant from the middle of the continent. This caused the progressive roundening, which sort of makes intuitive sense (sharp edges ground down over time) but doesn't look very realistic (Earth has lots of pointy continents).

My new strategy is to identify potential holes (tiles adjacent to those identified as belonging to the continent in its new position but that aren't themselves part of the continent's set of tiles), and rotate their positions backwards to see if the nearest tile to that location was part of the old set. If so, then add it to the new set, then check the tiles adjacent to that one, and so forth.

The resulting continents are much more satisfyingly pointy:

Tectonic Youth

I've been working on a somewhat reasonable-looking plate tectonics simulation.

Looking for something along these lines, I had found an open-sourced VB app called World Builder, which uses David Allen's cdrift (around halfway down) algorithms for simulating something like continental drift on a toroidal topology; I believe that was influenced by Mark Isaak's plates.c (same as last link) program.

From my very rudimentary understanding of geology, it seems like the major disparity between how these simulations played out and what an Earthlike planet should look is purely geometrical: continents that split up and move around a torus are going to run into each other in different ways than on a sphere, and continents tend to break up along 120-degree angles.

So I basically implemented cdrift's general approach (build up continents' leading edges, erode to neighboring tiles, and split and merge plates at random), but on a sphere broken up into approximately evenly-sized tiles (latitudes spaced evenly, and as many squarish tiles as fit in each latitude). The results aren't terrible (same simulation state in three different projections):

 

It's slow as hell (maybe ~2s a step on my computer), because math is hard, though there are surely opportunities for optimization.

Source.

Icosahedron of the Day

It's this icosahedron right here: http://www.ngdc.noaa.gov/mgg/fliers/04mgg02.html

Good enough or worse than not at all

I was reminded recently of an idea mentioned in an xkcd mouseover text: to keep yourself from being distracted by crap on the internet, put a 30-second delay before opening up a new webpage. I searched and someone had wroten a little script to do that.

I don't know if I screwed something up installing it or whatever, but the script appears to work erratically: sometimes correctly, sometimes showing a countdown on its icon but not obscuring the page, and sometimes having no effect at all.

The upshot being, the anti-distraction mechanism itself ends up replicating the "slot machine" sort of dynamic that makes things like web forums, Twitter feeds, and news sites so distracting in the first place. Being able to instantly check Reddit for new stories whenever you want is habit-forming, but only being able to do so 10% of the time is even worse!

Anyway, just found that amusing or whatever.

Celestiality

I wanted to be able to generate random but plausible celestial spheres of stars visible to the naked eye from the vantage point of a solar system like ours, situated in an arm of a spiral galaxy.

I grabbed all the stars in ESA's Hipparcos catalogue with apparent magnitudes below 6, which comes to a little over 5000 stars. Mapped out on a sphere according to apparent magnitude and color they look like:

That's a sinusoidal projection of the whole sphere, as would be seen from inside of it (on the Earth, for example). I sanity-checked it by filtering out all but the stars of the Big Dipper and made sure it dipped in the right orientation and hemisphere.

Plotting their absolute magnitudes versus their color index looks like this:

The hunk on the left is made of stars on the main sequence, and the other splotch of giants, with a spattering of others. Most of the stars around us are red dwarrows, but since they're too small and dim to see with the naked eye, I don't even care about those.

A histogram (excuse the rotation and scaled-up x-axis) looks like:

I smoothened that out to make a probability distribution (scaled up, and apologies for yet another axis rotation):

You can't see it, but outside the main globs there are big regions of "off-white" (grays 253 and 254) where there are small but nonzero probabilities of finding stars.

One thing I had not expected was that even without rendering a "milky way," the visible stars are noticeably more prevalent closer to the galactic disk. So I also found a best fit great circle and recorded each star's angular distance from that. Plotting those on the z-axis gives:

You sort of need to move it around to tell what's going on, but basically stars are more likely to be near the disk, and more so if they're brighter and whiter. I didn't even try to quantify this any better, just fudged it.

So I generate 6000 (or however many) stars with color and magnitude selected according to my smoothified histogram. Each star gets a random distance within visibility range (because my initial sample only included stars of a given color close enough to be visible to the naked eye, I can't create any too far away to see without throwing off the distribution) and is either randomly rotated away from the galactic plane or rotated according to a normal distribution, more likely the latter the brighter and whiter it is.

Results shown on the right, alongside plots of the Hipparcos data set on the left (and as shown above).

The results aren't too bad, though that lowest-probability shade in my smootherized histogram is too dark: it should probably be like gray 254.9 or something.

Finally the whole thing gets a random rotation from the galactic plane, and the results might look something like this:

So pretty good! Next step (after tweaking the distance-from-galactic-plane function) would be generating some realistic views from a planet according to axial tilt and times of day and season. And then inventing constellations?

Also maybe the possibility of a perspective from outside a galactic arm? Though how likely is that, if you're looking from a class G or K main sequence star?

I don't know. I think it's cool though.

Source here, requires pygame, numpy, and matplotlib.

Software Idea

You enter the ingredients list and nutritional information of a food product, like what's printed on the package. The system looks up the nutritional data for each individual ingredient. That information, plus the inequalities implied by the order of the ingredients list, allows it to solve for the relative quantities of each ingredient (giving ranges where an exact amount can't be determined, such as for ingredients with no measured nutritional value).

Basically I want to reverse engineer this here granola.

31337 is Prime

Did not know that.

Polygons on a Sphere

It's this shape:

And a couple of instances of them go around a sphere in different directions (the blue dot shows the orientation, which is different from the direction of travel, and the red dot is the centroid):

Far from the center of the projection, they get distorted:

When one wraps around to the other side of the projection it gets all screwy, but I couldn't get a screen cap.

Same repository as last time, now additionally depends on Shapely.

Livin' on a Sphere

I've been mucking about trying to get something that looks something like what's described here, but on the surface of a sphere (not about to try modeling any kind of actual fluid dynamics, just trying to mimic the behavior).

I used a sinusoidal projection so each screen pixel represents about the same area of the sphere. It took me way too long to figure out I should be using regular old vectors in R³ instead of muddling through with latitudes and longitudes.

Brighter green points are heavier, and the blue point is their weighted average. The red point repels the green points and moves to the blue point whenever the green ones slow down sufficiently.

So this is early in a cycle, when the red point has recently moved to the weighted average location:

And this is later on in a (later) cycle, as the repelled points are converging towards the antipode:

Source here ("Heat2.py" is shown, but there's other related crap in there), requires Numpy and pygame.

Out of Comptrol

I didn't know that

1. "controller" comes from "counter roller," meaning I guess that "to control" comes from "to counter-roll";
2. "comptroller" is a misspelling of the same word, "born of ignorance and continued in darkness" (that's what she said); and
3. the "P" is silent.

What I'm still not clear on is whether "the 'P' is silent" means that you're supposed to say "com'troller" because you wouldn't say the "P" in French (would you? I have no idea), or whether you're just supposed to ignore the ignorance-born/darkness-continued–ness of it and say "controller."

More Dorkiness

I've adapted the code from the other day to use real-valued characteristics, the Euclidean distance in characteristic space representing the probability of agents interacting. And I added some histograms to the display:

They converge on a wishy-washy moderate consensus pretty quickly, so there's a distance threshold in there to keep everything from joining together right away:

Source here.