Educational gamification

Hey what an impressive site and code base you have here! I was working on my own simple tectonics simulator to make an educational game and came across this one which is significantly higher fidelity. The concept for the game was to show how tectonics impact the formation of life and to provide a little more context and interest to the life of a planet from conception to freezing over. Thinking about trying to make the whole game about 5 minutes long and have different objectives for the users. Target audience would be high school age and older.

I don't know how you feel about something like that and about sharing code with what you have. The game as I conceptualized it was going to focus a lot on the carbon cycle as well. I am a chemical engineer by training, but I am not looking to put academic rigor into the climate and carbon interactions.

I am really impressed with the site as it stands right now. It is impressively smooth and fast, and it certainly knows things about tectonics that I am oblivious to, judging by the discussion in the wiki articles. Gamification would include features like:

Ability to speed up time (~5 Gy in 5 mins ish, could fudge the numbers a little here to make the plate movement not too chaotic at this time scale), and how tectonics slowly fade out as the mantle solidifies.
A little more detail around ice ages and global temperature fluctuations
More detail around the flora/fauna and how it responds to temperature changes and climate
Depending on desired level of detail, basic comprehension of fossil fuel deposits and the interaction of the oceans with atmospheric carbon.
maybe a few animations for volcanoes or asteroids

Then the game part would include some objectives maybe some friendly competition and a leader board, etc.

Thoughts? It seems like a very different direction than this project is currently heading, but wanted to bounce the idea off and see what you thought. Maybe a game mode would be possible or maybe a fork with game hierarchy built in that version. If not I will keep plugging along with my uneducated tectonics version - it will be amusing to you if nothing else (assuming the project goes anywhere of course).

Best, David

Hey, awesome!

The model is licensed under creative commons. You're welcome to fork the code right away and do whatever you like! Forking is probably the best approach for what you have in mind. What you describe is a pretty agressive change in project objectives, and I expect you'll want to start now while you're still in the headspace. What do you think your timeline looks like? I'm only one developer and I struggle to find time even to implement original project objectives. You probably won't want to wait on me. I think it's best if you have full ownership over the code on your fork, and we can work changes back in where appropriate. A few things on your list intersect with my own list of improvements - we might be able to work on some of those together, or see who is able to implement them first. I think there's a tremendous opportunity for collaboration and I'm excited to see what comes out of it.

Now, onto your feature list:

Ability to speed up time (~5 Gy in 5 mins ish, could fudge the numbers a little here to make the plate movement not too chaotic at this time scale)

You can play around with speed, yourself. Just open the dev console in a browser and type something like sim.speed = 1e9*Units.YEAR/Units.MINUTE. It's definitely possible, but there is some loss of precision that's unavoidable.

and how tectonics slowly fade out as the mantle solidifies

A quick search reveals this paper which we might be able to base some behavior off (the paper is summarized in a news article here if you prefer light reading). Sounds like this would switch off tectonics if mantle temperature crosses the solidus temperature, however it says nothing about speed. A better approach might be to set mantle viscosity to a function of mantle temperature. The model correctly simulates speed from mantle viscosity, so if that changes all else will easily follow. We can probably use one of the functions described here. I might prefer the Arrhenius model since I'm already familiar with it and I know it can be used elsewhere.

A little more detail around ice ages and global temperature fluctuations

The orbital mechanics submodel is pretty well generalized, and it can be modified to describe changes in insolation due to milankovitch cycles. However, the whole atmospheric submodel is in a cursory state. For one thing, the model makes no attempt to model the carbon cycle. The carbon cycle is extremely important for getting climate right and right now it's not modeled at all. There's only a single factor expressing the greenhouse effect and it's a hardcoded constant. I think any attempt to model the carbon cycle will be better than the current state, especially if drafted by someone with a background in the area. Chemistry isn't my strong suit.

More detail around the flora/fauna and how it responds to temperature changes and climate

This one I would love to implement! My background is in ecology, and this is right up my alley. There are so many ideas I have in this area, which may or may not be in line with what you're thinking.

On a short term scale, I'd like to model plant biomass as a state variable that changes based on several limiting factors, starting with insolation and precipitation. A trivial trophic pyramid can be constructed based on energy/biomass considerations to describe the biomass that's allocated to herbivores and carnivores. A reaction-diffusion equation can be implemented to represent the propogation of life across space, traversing land bridges and the like. If we accompany this by a vector field that mutates over time, we have some way to visualize evolutionary lineage (picture a color map indicating place of origin). We may not be able to species individually, but we can at least see how species ought to be related spatially. Lastly, if we assume the biosphere is ergodic, then we can assume any type of animal life will evolve to occupy a certain niche, and we can give quick statistics about what animals within that niche could look like. For instance, the trunk of a large tree will have a width that is a function of the planet's gravity.

Depending on desired level of detail, basic comprehension of fossil fuel deposits and the interaction of the oceans with atmospheric carbon.

I've wanted to model fossil fuel reserves for a while, as documented here. A critical step will be to model plant biomass as a state variable, as I describe above. Given that, we can assume a certain background mortality rate and a certain fraction of dead biomass that gets converted to fossil fuel, though I'm not sure how to find those or whether they'd be sufficiently generic.

maybe a few animations for volcanoes or asteroids

Your perogative. I want to implement impact craters but don't really care about animating the impact. If the code is there I might pull it in. I just hope whatever comes out of it ties in nicely with orbital mechanics/solar accretion.

Then the game part would include some objectives maybe some friendly competition and a leader board

This is your fuzziest point. A huge inspiration for the model was SimEarth, but SimEarth was never known for its compelling gameplay. Its more like an executive toy, or a super complex lava lamp. Do you have any ideas?

Great - sounds like you still have lots of ideas and energy for development. It sounds like we have a few areas of overlap that I could start developing before completing the game fork. It sounds like you are also interested at some level in a carbon cycle simulation and climate. Maybe I can do a little on that front as I familiarize myself with the code, then from there start some of the other pieces.

You are correct that the game aspect was fuzzy - still working out details. The basic structure of the game as I am imagining it now is something like this:

PHASE I - ACCRETION (0.5 Gy) *maybe just find a video of earth accretion PHASE II - (Hadean) Liquid water, first anaerobic life develops (1 Gy) goal: create CO2 from CH4 features: deep and shallow ocean, Phase III - (Archaean) More of Phase II, (1 Gy) goal: create O2 in the atmosphere; Phase ends when complex life is developed. Phase IV - (Cambrian and later) Complex life! (slow down the game here?) goal: avoid ice ages and temperature runaway due to GHG, Features: ice age, volcanoes, maybe a couple asteroids; Another game objective could be to figure out what needs to happen so the mass extinctions don't totally wipe out life on earth. Phase V - Quiescence; mantle solidifies to a certain extent and the plates stop moving. Game ends - I guess at this point all the land would erode and eventually the carbon cycle would essentially stop.

Supercontinents might be a good marker of the passage of time and progress into each new phase ... that is a little more visual than atmospheric composition.

Cool bonus features to make things more interesting: Volcanoes Asteroid impacts Ice Ages Algal bloom / fossil fuel Mass extinctions

Game controls: So far the way I imagined it was just the tectonic plate directions and speeds. For example, the goals would be to make lowlands and shallow water to encourage life.

Game Indicators

Surface Temperature
Mantle temperature (linked to volcanism, tectonic plate size, and tectonic plate speeds possible) - might need separate volcanism measure??
Carbon Cycle Indicator (probably need to simplify the typical 6 to fewer reservoirs) - may also need more indicators here to follow mass extinctions more closely
Atmospheric Composition (CH4, CO2, O2; probably don't need to include NH3 or N2)

A lot of these were going to be simplified by just having a single number for the whole planet. Using the given code base, there is an easier path to have more rigorous calculations localized.

I think the biggest challenges will be figuring out the controls and not making it too complicated. Everything else I think we can adapt to whatever seems to make sense.

Hi! I'm also working on the game idea - and I'm 100% sure that we should share code. I'm not 100% sure about the idea of doing an actual fork right at the outset.

Forking is evil - and although it's sometimes necessary - it should only be done when all else fails.

What might make more sense would be to try to take your existing project and carefully divide it into a "Tectonics Engine" and a "UI/UX" part and turn those into separate GitHub projects. We could then share the engine part between game and simulation - so we can BOTH benefit from improvements to it - while the UI/UX part would be a complete do-over for the game project - that you wouldn't have to ever care about.

The main reason I suggest this is that I (personally) believe that we should use C++ code via WebAssembly for the "Tectonics Engine" part because it would allow the math loop to run MUCH faster. This would entail someone (probably me) translating the core engine code into C++. I'm a professional game and simulation programmer with 35 years of C++ and 20 years of JavaScript experience - so this is something which I hope I could be trusted to do with very great care!

We might even be able to leverage the GPU to speed it up still more - my speciality is in graphics - so writing intricate GLSL shaders is "what I do". Moving heavy-duty math code into the GPU can sometimes offer 100x speedups over C++ and 1,000x speedups over JavaScript - so this is something that definitely needs to be considered.

Making that core engine code run MUCH faster would allow us to have multiple math iterations per display iteration - which should help the issues of stability at higher years-per-second rates - but to do that and maintain some sort of useful frame rate, we have to make the code go a lot faster.

We could do that speedup only in the game 'fork' of course - but that would be a shame because you could be benefitting from it too. Hence the idea to split the code base so we don't have to fork the engine code...or at least, we don't have to fork it forever.

Another benefit to not forking the engine code is that we'd very much like to retain your expertise. I think it's fair to say that nobody on the game team has even a fraction of the expertise that you evidently have - so if there are issues about how planets develop - then we don't want to lose your improvements when they happen in some other fork.

Similar issues might show up in the graphics stuff (which I'd say was in the UI/UX bit) - but that's more controversial. We might (for example) want to artificially exaggerate elevations so you can visually see erosion happening - we would certainly want some dramatic lava oozing effects in ocean-bottom spreading and some nice volcanoes where the physics says they should be. We would probably want to add some purely decorative texturing to make things look more detailed than the underlying math actually is. Not sure whether you'd want those things on the simulation side - but for us, they are "Must Have" items.

So I think we should spend some effort thinking about creating some libraries that can be shared between the two projects BEFORE we consider forking anything.

An alternative (since I'm sure you're already feeling nervous about a bunch of people coming in and ripping apart your engine code!) would be to divide your project (per above) then fork just the tectonics engine library. We could define an API for that which the game version would promise to remain backwards compatible. Then when we're finished with any major upheavals, you could make a decision as to whether to switch your simulation over to our fork - or to simply divorce yourself from it.

But the delicate decisions about how to dissect out the engine part from the UI part really needs to be something that both projects discuss carefully because it's a critical decision for the future that would be hard to undo.

So BEFORE we rush into forking code and diving in and ripping and tearing stuff - let's at least take a few days to consider HOW we do this.

@berg44:

Maybe I can do a little on that front as I familiarize myself with the code, then from there start some of the other pieces.

Check out noncompiled/model/Atmosphere.js and noncompiled/academics/AtmosphereModeling.js. This encompasses all behavior within the atmospheric submodel. All submodels use "rasters" as their basic building blocks, and you can see code for these data structures within the "raster layer", under precompiled/utils/.

PHASE I - ACCRETION (0.5 Gy) *maybe just find a video of earth accretion

I do want to implement a solar accretion submodel at some point. For a quick first pass, we can use the accrete/starform/stargen model, which is the de facto king of solar accretion models. There are several javascript ports available.

Game controls: So far the way I imagined it was just the tectonic plate directions and speeds. For example, the goals would be to make lowlands and shallow water to encourage life.

I should mention plate directions are deterministic within the model - we calculate them from crust age and density. You could override this behavior, though. Might require some discussion.

I think the biggest challenges will be figuring out the controls and not making it too complicated. Everything else I think we can adapt to whatever makes sense.

I do think it's important to understand where the player lies on an abstraction hierarchy: what do they control, vs what gets abstracted away. For instance, are you like Kerbal Space Program, where you control an individual rocket, or Children of a Dead Earth, where you order entire fleets to perform orbital maneuvers? Personally, I wouldn't mind seeing a game where you micromanaged some aspects. Rather than order up an asteroid impact from a menu, have the player find an asteroid and try pushing it on a collision course, then they can see if that accomplishes their objectives. Make them feel like they could shape the planet in real life. Make them feel powerful for knowing what they do. Stuff like that.

@SteveBaker:

What might make more sense would be to try to take your existing project and carefully divide it into a "Tectonics Engine" and a "UI/UX" part and turn those into separate GitHub projects.

Agreed. The app already has a clear separation between model and view that we can leverage to accomplish this. I was already thinking about doing this after the port to C++. But we might consider doing this before the port. It depends on how fast you want to move. This will involve creating a new Github project, "tectonics engine", which will be included as a git submodule within the existing tectonics.js project.

In principle, we could also break off "Rasters.js" into its own library. It's sufficiently general to function as one, though I doubt it will see much use outside the model.

The main reason I suggest this is that I (personally) believe that we should use C++ code via WebAssembly for the "Tectonics Engine" part because it would allow the math loop to run MUCH faster.

I agree whole heartedly. Performance eventually always winds up limiting development of the model, and I expect porting to C++ will help immensely. Porting to C++ will also enable future development paths, allowing the model to work in many environments, and as an engine for many applications.

It's actually funny you should mention - I'm already working on a C++ port. Check out the "wasm" branch off master. It has a partly implemented C++ port of the tectonics.js's "Raster" layer, complete with a wasm wrapper. You can build to wasm by running make, and run a set of unit tests using make test. All unit tests pass on my machine.

I'm a professional game and simulation programmer with 35 years of C++ and 20 years of JavaScript experience

I would appreciate your contribution. By contrast, I have about 2 years of professional C++ experience and I'm aware I have a lot to learn. Feel free to make whatever contributions you feel are appropriate.

We might even be able to leverage the GPU to speed it up still more - my speciality is in graphics - so writing intricate GLSL shaders is "what I do". Moving heavy-duty math code into the GPU can sometimes offer 100x speedups over C++ and 1,000x speedups over JavaScript - so this is something that definitely needs to be considered.

I was of this mindset when I first discovered shaders. However, I found that using shaders to express model behavior significantly slowed development time. Once something's in a shader, it's hard to get it out. It's hard to transform it. It also reduces portability.

There's even been times where I decide to implement something in javascript, even though I know it would normally be implemented in shaders. Case in point: insolation. You'd normally use shaders to determine how much light strikes a surface, right? But I wind up reimplementing that code in javascript anyway, since insolation is important for determining things like temperature and plant biomass. And since I already calculate it in javascript, I just take the output and feed it into the shader. That's how we're able to display day/night cycles, right now.

I should mention that WebGL is based off a very old version of OpenGL with significantly limited shader functionality. Whatever parts of code we share should be able to continue working with WebGL.

By the way, what sort of platform do you have in mind for your game? Do you still want to work with browsers? Do you want to port it to desktops using Electron? Something else?

We might (for example) want to artificially exaggerate elevations so you can visually see erosion happening... Not sure whether you'd want those things on the simulation side - but for us, they are "Must Have" items.

In developing view code, I've always wanted to make the planet look photorealistic. Anything that works to that end I'll port to my UI/UX project, one way or another. So textures are possibly yes, but exaggerated landscapes are a no.

I'm sure you're already feeling nervous about a bunch of people coming in and ripping apart your engine code!

Not really, that's what pull requests are for. 😀

I'm usually pretty liberal when it comes to accepting pull requests for new features, because developer time is precious. It can be hard to find time to implement features and for someone to spend their time on a feature speaks volumes to how important it is to them.

However, I am going to give extra scrutiny to anything that changes model behavior. There are right and wrong ways to do things in modeling, and I think calling wrong stuff out is an easy way I can add value to the endeavour.

I reserve the right to be picky about stuff like arbitrary name changes, but I will concede to changes made for consistency, particularly when there's an established standard in code that isn't being followed, or where we establish a convention ahead of time.

Same goes for architectural changes, but I may concede to well reasoned arguments.

In short, communication is generally good.

We could define an API for that which the game version would promise to remain backwards compatible

That's actually what I'm more nervous about, since this will also probably bind myself to the API. We'll probably have to define an API anyways when we're breaking up engine/uiux, but I don't want to commit myself to an API unless necessary.

Then when we're finished with any major upheavals, you could make a decision as to whether to switch your simulation over to our fork - or to simply divorce yourself from it.

Eh, let's try not to make monolithic pull requests.

But the delicate decisions about how to dissect out the engine part from the UI part really needs to be something that both projects discuss carefully because it's a critical decision for the future that would be hard to undo.

Agreed. I actually don't think the dissection is going to be hard, though. We already have a well defined model (noncompiled/academics and noncompiled/model) and view (noncompiled/view and precompiled/view), which correspond well to your idea of Engine and UI/UX. There is some discussion to be had for parts that could arguably belong to both (mostly stuff under noncompiled/model/Simulation.js). We could also discuss what the API for the engine might look like: the stuff that we need to promise not to change.

Hey, sorry if that was a lot to digest. The gist is you have my full support for this endeavor. We should have a discussion for how to split off the engine code and go from there.

No that sounds great! I'll probably let you guys figure out the C++ and engine thing for a while. I think I want to start on the carbon cycle next.

Hey just a quick question on plates - it looks like the plates can co-inhabit the same position and continue on their merry way ... is that intentional? Is that a behavior seen in reality?

It seems to be exaggerated at elevated speeds -- at 10My/s things seem to work pretty well, but the plates seem to turn into strips along north south boundaries

I am also curious about the land masses in the middle of plates - I was expecting most of the land mass to be along the edges of plates, but it seems like that doesn't hold true for the plate behavior in the simulation.

Hey just a quick question on plates - it looks like the plates can co-inhabit the same position and continue on their merry way ... is that intentional? Is that a behavior seen in reality?

Could you clarify? Is there a particular seed that replicates this behavior, or would you be able to capture it on video?

There was a time when plate velocity were assigned only at the start of a new super continent cycle and wouldn't change based on the configuration of crust. This meant that plates sometimes did some really wierd things, but this has since been addressed. The model now calculates plate velocity at every timestep as the average terminal velocity of subducting ocean crust. If two continents collide, then any ocean crust that's pulling them together will likely be destroyed soon, after which there's no force to pull them together anymore and the continents will slow down.

However there is no "frictional" force in the model that slows the crust down when overlaps occur, so it's possible for there to be some remaining issues. There probably does exist an analogous force IRL, and I think the modeling framework is designed well enough that it could be straight forward to implement, but I'm not sure how to quantify it, and thus far I haven't seen a reason to investigate it.

As for land masses in the middle of the plates: I have no direct control over that. The model draws boundaries based on a velocity field, which itself is derived from crust buoyancy. Old ocean crust is the only thing that generates negative buoyancy, so plates will generally split landmasses if appropriate, however it's not a hard and fast rule. If a landmass is only surrounded by new oceanic crust, it will not split - simple as that.

davidson16807 / tectonics.js

Educational gamification #33