p(tree_goes_here) > random()

If one did this, such a game would have value not only from the game itself but it might open up a whole subculture of archaeologists who go from planet to planet studying the evidence to piece together the events that led to the planet's present state.

Otherwise, you're right. Each world would end up being different much in the same way that listening to static noise is different each time you hear it.

That is, it's more challenging and rewarding to me to simulate tectonic movement than it is to generate terrain from random noise and tweak it until it feels okay. But the important question is, is the game noticeably more interesting either way? Do mountains affect gameplay in a way that gets more compelling if they're placed according to tectonic movement?

There are certainly games where the answer is yes, but there are a hell of a lot more where it isn't. And if your game is one of the latter, then complicated simulations are a dangerous trap - not only do you waste time, you also hinder yourself by making your game's content harder to tune (in that you can't just, say, make the mountains 30% higher if mountain height is determined by a complicated process).

IOW, they tried so hard to make the game realistic that the intended gameplay was no longer enforceable. Setting up all these intricate puzzles and writing the procedural generators was fun, but actually playing the game was immensely dull unless you went out of your way not to take the path of least resistance.

They ended up using some of the lessons learned in Prison Architect by making the "level design" the actual gameplay. There's actually a very interesting presentation of how Subversion was intended to be played versus how it would have actually been played somewhere on YouTube.

As a counterpoint, RimWorld is a game that's largely based on procedurally generated worlds with heavy inspiration from Dwarf Fortress. But the entire premise of the game is that you build a colony which the game tries to actively challenge to create an interesting story for you.

Realism is sometimes a misguided goal. Games are media, just like movies. What you want most of the time isn't realism, but an impression of realism. Robert Crumb and his son sometimes do "realistic" portraits, but in the biographical movie about Crumb, he reveals that his "realistic" portraits actually contain very subtle elements of caricature, to draw the user's attention to the most interesting aspects of the subject's face.

Contrast this with films of war vs. actual war. Head-cam movies of modern soldiers in combat look like people in battle gear taking cover while yelling at each other about people you can't see or barely see, then calling in air support. There's nothing cinematic or easily parseable by the viewer. If you're on a modern battlefield, and you're posing for the cameras in a nicely composed scene laid out by the "Rule of Three" you're likely to get shot in the very next second.

Documentaries and action films are very different things. Both of those are very different from documentary-styled fictional films. Analogies to sandboxes, various other game genres, and sandboxy games apply.

Similar to fiction: it's more dramatic and makes more sense than ordinary life.

A simulation is akin to a tech demo, which can be impressive, but usually isn't a game.

Switching gears, I'm interested in how you've done tectonics. I was thinking of doing it as a magma fluid simulation (very slow, only one timestep every few hundred frames) and using convection to move and rotate plates.... though it turns out, the cause of tectonic movement isn't nearly that well understood. My concern is that using a fixed direction/speed will eventually mess up the world. If tectonics really are governed by convection, movement must change at the end of that magma cycle. Maybe a bit over the top! How are you doing tectonics?

One (expensive) solution to the 30% mountain height problem is monte carlo: rerun the simulation til it fits the parameters. What's nice is that you don't distort the generation probabilities, apart from the explicit constraint. Of course, not plausible for very unlikely constraints, esp. combinations thereof!

If you just want the end-produce (not an ongoing, evolving world like mine), some people have used a more declarative approach. e.g. Instead of generating rivers by waterflow and erosion over a terrain, you can generate a hierarchy of rivers and tributaries first, work out the watersheds implied, then generate the terrain based on that constraint.

At a more fundamental level though, doing evolutionary-type stuff in a procedural world is a problem I'm wrestling with. I'm running an infinite world that's generated one chunk at a time, like Minecraft, so you can't, say, "start by generating all the rivers, and then...". Obviously this means everything has to be deterministic, but also it means that whatever macro-sized calculations I do need to be re-done for each chunk, or else cached somehow, etc.

I've looked for articles on such things but not had much luck. Maybe others here have approaches they've tried?

I.e. once you encounter a river, you will then generate the whole river, from source, to sink (either you have a sea, or some other already existing, but undiscovered river?)

You would then need to account for 3 states of your world: a) blank canvas b) pre-generated but yet unexplored terain c) already explored terain

The world in state b) would then be the one both cached and available for re-calculating :-)

If I were you I would read up on pen&paper sandbox designs, i.e. Stars Without Number [1] relies on lots of random tables to generate a sector of space with different factions/tech-levels/ecosystems, combined with rules for faction interaction. This gives it a nice "I am just a small ship in a big universe" feel :) You can generate example sector [2]

[1] http://www.drivethrurpg.com/product/86467/Stars-Without-Numb... [2] http://swn.emichron.com/

For large scale features like rivers, generate those at coarse resolution on very large chunks. When generating the detailed chunks, take input from the coarser resolution levels which overlap the same spatial region, and add fine scale detail.

A couple of levels of detail might suffice in practice, but if you want to go crazy you can more or less make as many as you like: As long as each level is downscaled by at least some constant factor of the more detailed level below it, you'll only have O(log(N)) overhead for O(N) chunks which is small even for very large N.

Compare mipmapping, which is more or less the opposite of this process.

One of the supposed problems with No Man's Sky is planetary isotropy (uniformity at a global scale, variation only on a local level). They're all single biomes and once you've seen the local area, you might as well find another planet. But you're right: I don't know that people would be any more impressed with planets if they were more 'realistic' in regards to geomorphology.

when the universe follows simply-governed rules, then of course there's little for the player to do; he wins by understanding, and understanding simple things is, well, simple.

And ofc, the internal rules can very well be trivial to implement. Its the rules to from the players viewpoint that matter. And vice versa; the engine could be infinitely complex, but if all it does is spawn the same mountain repeatedly, then there's not much left once the player bests the first.

For me the canonical example of this is Nethack, which is full of such things - monsters that are slightly more dangerous during a (real-life) full moon, and so on. One can argue that NH is a special case, with its rich tradition of players reading the source code as they play, but in general I think it's an anti-pattern for game developers to beware.

I think the key comes down to basics: Games are media. One of the key attributes of great media is a focus on the audience experience. So if you're going to spend a lot of effort on procedural generation, then this procedural generation had better be "paying rent" commensurate to the resources taken up by it.

If your game is about tactical improvisation and combat, then the procedural generation should be directly contributing to enhancing those experiences; therefore tweak the statistical properties of procedurally generated tactically useful things to enhance the user experience. Likewise if your game is about survival, or managing resources, or what have you.

If your game is about viewing scenery, then good luck to you. People will get "remix boredom." Furthermore, if you've sunk all this energy into producing "interesting" to view scenery, then people are let down by your tactics and combat -- well go figure!

Several types of plants would grow, and randomly catch on fire and burn half the planet to the ground, and so on. I had a primitive water cycle, too; water flows to low points or gets absorbed by plants or evaporates. When plants burn, they release their moisture into the air, which rains back down on the ground. It's interesting how small changes to the cellular automata logic can cause major changes in emergent behavior.

That was a very fun experience and I could imagine it being the basis of a game. And being a finite world (unlike Minecraft's practically infinite expanse) it's computationally tractable to simulate a complete ecosystem that's constantly changing; even the parts you haven't explored yet.

[1] https://wiki.haskell.org/IcoGrid

I'm going to do something like this, but for one specific class of enemies: The dire "it's time to do your best to survive" encounter. Specifically, I'm going to see if I can't use genetic algorithms to evolve "kill the crap out of the player" combat groups. You can't write a fitness function for fun or player involvement. But you can write a fitness function for "kill the crap out of a player" -- even equalized for level. So the trick is to hand-balance the timing/opportunities for a player to encounter the dire situation.

I'm going to let players post-mortem the genetic algorithm tuned AIs and ship/item configurations. So instead of archaeologists, there would be hackers and xenobiologists.

I have an idea for a fairly simple possibly: The user just declares that certain features of the scene are interesting and relevant, maybe by "taking a sample", so that the algorithm can boost the weight of inputs that have a relationship to those features. But, I suspect that you have something much more interesting in mind...

I think that the most straightforward way to do this is to have the Archaeologist player indicate features of the combatants or the scenario that led to victory/defeat, like you said. The Adversary then uses those to guide its optimizer. For example, you might indicate something like "The Monster won because: Monster had high armor, Player had low jump height, this platform in the middle of the room". The system then knows to put those features together more often.

Hmm, now that I think about it, there's actually a metagame issue here: Players will tend to support each other by trashing the AI. It'd be more effective to set players against each other somehow. Or we need a better way to reward players.

So what we want to do is tie the monster's success to the player's success. A simple answer is "I want this": The player gets to choose something to take from the monster's ship and add to their own. The Adversary might be able to use that somehow, but there's a little bit of a mismatch there because the player's ship and style will be different than the monster's, and a feature might be selected to shore up something about the player's ship rather than to point out a useful bit of the monster.

Maybe have the investigator player redo the fight with tweaks. The player's job might be to change the monster until it loses a rematch. Could do this by having the player take over the past player's ship and fight "in simulation", or could just do it automatically. Player gets a better reward the less they have to change the enemy to win, which encourages efficient changes. The Adversary then changes the monster in the opposite direction and sends it back out.

Could split things up into teams and set players against each other on a grand scale? The player's job is to find battlefields where their team's monsters lost and then optimize the allied monsters. You never actually see another player - might do something asymmetric here, with a dimensional boundary or something that prevents players from interacting with other players except via salvaged guncam footage from allied monsters.

Now that I've had some hours to think, this'd actually work better in a single-player format: The player can only advance by tweaking enemies until they can defeat them, knowing that the next time they encounter that enemy it'll be stronger in exactly the wrong way. Then it becomes a complex game of managing how the enemies grow and balancing tactical concerns ("how do I beat this one enemy") versus strategic concerns ("I could beat this one by decrementing its dex, but then it'd be unstoppable in the future.").

EDIT: this feels a little bit like "warning forever" but maybe with more depth and a clearer focus?

So what we want to do is tie the monster's success to the player's success.

One thing I've played with is to let Players take "contracts" to build security drone warships. The players will get paid a small royalty, plus a sizeable bonus for combat success.

To keep players from trying to rig the system in their favor too easily, the AI scripting language can be processed by the genetic algorithm. The players will still be able to exploit the system by nefarious means, but they will have to create bots that are tough on the surface, and hope that not too many others will discover and also exploit their backdoors. (I would love it if players started doing this!)

Genius nefarious builds could definitely be flavored as a reward, and I agree that that's one of the big draws of this system: if you manage to build something that's good enough to survive and spread but still flawed in a way that you can exploit, kudos to you! Reward: you get to break into anything that's guarded by your creations. :P Just good luck building something that you can exploit that not enough other people can for it to not succeed.

(I think I'd love to check this game out when it's further along, BTW. Do you have a news list I could throw an email address at?)

Getting destroyed encourages you to try new tactics to counter the superior designs and build more efficiently.

[0]: http://en.spaceengine.org/

A sentiment captured perfectly by: https://www.penny-arcade.com/comic/2016/08/17/infinite-and-i...

EDIT: That sounds snide but I'm actually being sincere. I'm planning on including items in my game from a procedurally generated tech tree with location-dependent item availability.

No, I still don't. Games to me are about interesting choices. I don't care about rare "loot", or about finding yet another key to open this lock, or about improving some score by 0.35 angstroms. I care about "do I castle kingside or queenside? Because if I castle queenside then my rook will be opposite his queen and blah blah blah but if I castle kingside then I won't have to worry about a quick a5 strike with the potential to undermine my b pawn." These choices (with chess only as an example) are interesting because they have serious consequences that can be reasonably foreseen but are not totally obvious.

It's sometimes the case that the space between reasonably foreseeable and totally obvious is a very fine narrow one, but then your game might be lacking in depth. Adding procedural puke special snowflake enemies doesn't add any more depth than "rare Blatovian power generators" does, unless the tradeoff over using a "Snargglemoofian power generator" is that your ship can no longer turn left or something.

So I as a budding star ship pilot had to seek out the best vendors in order to buy the right equipment to competitive.

There was a lot more to it but it was the complexity of the emergent gameplay that gave the psuedo randomness of some aspects a real role, and drove your personal story.

"I managed to find a vendor who has access to large amounts of high grade titanium, and he crafted me this engine with 10kj/s faster recharge time, which allowed me to escape that bounty hunter.." was a story that emerged and happened to me in the game, for example.

In some ways the randomness was abstracted away enough to not be obvious, and I think that helped sell the feeling.

I am going to have a procedurally generated tech tree in my MMO. I'll only know statistically that certain powerful combinations in crafting are possible, but even as the dev, I won't know precisely where they will be, what they look like, or exactly how to get the components for them.

That's totally not what I was getting at. It's more like, "do I castle kingside or queenside? Because if I castle queenside then my rook will be opposite his queen...?" The low inertial penalty is probably the rare (actually statistically, as opposed to "rare") quality of that particular item -- and it would still come with some other form of penalty. (Like a really PITA set of compatibility requirements and high fragility.)

unless the tradeoff over using a "Snargglemoofian power generator" is that your ship can no longer turn left or something.

I hadn't thought of "your ship can't turn left." It might be a great tradeoff for something that would otherwise be an overpowered weapon, combined with another kind of movement penalty. I have thought of things like a shield upgrade that gives you really high resists across 120 degrees of arc, but which isn't configurable. "Your ship can't turn left" might be a really good penalty for a high resist/partial arc shield augment that mostly covers your right side.

EDIT: An even better idea: you get high resists over a 120 degree arc, but then you also get a susceptibility penalty over the rest!

With chess, on the other hand, the choice of 1. d4 vs 1. e4 is a huge one with TONS of implications, none of which are immediately obvious at a glance, but which are so rich and diverse that you have players literally identifying themselves as "d4 players" or "e4 players".

I hate to keep leaning on chess examples but they're the easiest since almost everybody knows about chess. I'd have slipped in a Battle Line example but almost nobody knows about that!

https://www.youtube.com/watch?v=lg8fVtKyYxY

TL;DW

"Calculations are decisions based solely on reason, with a clear correct answer." That'd be the decision to chose armour instead of cold resistance.

"Choice is overcoming internal conflict. Without conflict, there is no choice, only decisions." This actually is a good example for the "only turn left" gun, as there's a conflict between maneuverability vs firepower, which are rather incomparable.

Eve Online has emergent gameplay but most of that is space politics and metagaming - almost despite the game itself rather than because of it.

Heck, vanilla minecraft has incredibly complex outcomes from basic rules - vis a vis redstone and automation and so on.

I've played hella grindy Korean MMOs, they were just a case of spend x time get y thing. No real challenge, just a willingness to keep trying until complete. I'd strongly suggest highly complex systems restrict player innovation and emergence, in a way simpler rulesets do not.

One ethos of my game is going to to be "work smarter, not harder." The kind of player who feels entitled to succeed just because they've spent enough time mindlessly grinding resources, so feels entitled to have awesome stuff dropped -- I hope those people spend their time elsewhere.

The player will be able to find very pointed capabilities that come with big disadvantages. The point will be to improvise around those weaknesses while exploiting contextual advantages. Others may choose to exploit in-game scripting and manufacturing capabilities to automate the search for certain technology combinations, but this will entail maintaining installations and the combat force to defend them.

A lot of games basically have useless 2%-5% modifiers. Nobody cares about the difference between 0.025 and 0.027 inertial penalty. It just wastes the time of the player checking their loot. In the real world a weapon or armor is either effective or useless. Nobody takes down tanks with a glock.

I would recommend you to have several types of items even if that means the items have fixed statistics instead of having one item type with flexible statistics.

I was thinking more along the lines of the difference between 0.025 and 2.5. There's also stacking.

I would recommend you to have several types of items even if that means the items have fixed statistics instead of having one item type with flexible statistics.

Darn. I was going to have just one type of item, called "Object." Everything would be a variation on that, and inherit behavior from it.

But seriously, I am going to have very specific functions for a set catalogue of items. The procedural generation is all about their potential for interaction when incorporated into a crafted item.

If you ware a primitive man from long ago when those different kinds of trees were unique resources to craft the specific things that your existence depends on then you'd notice the difference between them and you'd care.

All those components you mentioned could appear right near the users spawn point, or they could all be impossibly hard to gather, due to procedural randomness.

There are geometrical properties that let me tune how hard certain combinations will be to find, statistically.

EDIT: Also, almost all benefits will come with some kind of penalty or incompatibility. It will be impossible to build a perfect ship that does everything well. Instead, you will be able to easily build a ship that does one very narrow thing rather well, one thing badly, but generally sucks otherwise. Also, you should be able to make something that does 2 things above average, one thing non-sucky, but otherwise sucks.

But you can also pre-empt a lot of problems by designing the system around physical limitations. Many games have done that for a long time. E.g. I believe Terminus included things like mass for components, so adding all kinds of extras had a cost in fuel usage and maneuverability. So if you did build a ship loaded with the most powerful weapons, you could, but it'd also be a slow, hard to control, big target.

Mass, volume, energy expenditure, waste heat - there are lots of factors you can add to make it hard to exploit. Of course, you need to tune those factors, but it makes it less likely for really extreme effects.

I also think you should rely on player feedback and community to spot this kind of things, but that could become time consuming if you're a lone developer.

[0] http://lbrandy.com/blog/2010/11/using-genetic-algorithms-to-...

If you have three attack upgrades you are very powerful but only have one live. If you die one of your upgrades will be replaced with a health upgrade ruining your build. Therefore if you want a three attack upgrade build you need to make sure that you don't die. The only reliable way is to just have two range upgrades and a bounce upgrade. Most enemies can't get into your range but it's still possible to get hit by being overwhelmed from too many enemies. If you die you get a health upgrade which also happens to solve this weakness of the build. It turns out if you want to get good at the game this is the only viable build despite there being thousands of possible upgrade combinations.

I can see how you could experience remix boredom in Cloudberry Kingdom. However, every so often it produces novel gameplay that actually feels new. And it's so good at tuning the difficulty to gradually escalate that it manages to achieve flow quite effectively.

Unfortunately, it's fairly rare for people to beat that game. The difficulty becomes basically absurd right up to level 320. At that point you essentially have to turn on all the powerups because there's no way you can get through without them.

One review damned NMS for lack of player-significant effects, but appreciated the prettiness of some of the results.

There's a property I enjoy, of a kind of global dependence (though mediated locally), instead of isolated randomness. e.g. instead of trees appearing randomly, they are dependent on rain, sunlight, latitude, altitude, soil coarseness and nutrients. And they are dependent on other trees.

This is surely includes under "emergent", but that term seems unnecessarily broad to me.

Rainfall in turn depends on local and wider topography (mountains, evaporation water sources), and wind patterns... which in turn depend on local topography and latitude etc.

Even a river's path is affected by its watershed (and rainfull etc), and all the preceding terrain, especially steepness (higher velocity carries more sediment, which abrasively erodes even faster) and soil finer-grained erodes more than coarser). River change course from time to time due to erosion.

It seems iteration is the only way to capture these dependent effects, but its computationally very expensive. NMS already has very long planet-generation times ("travelling"), so it's probably not feasible for that style of game.

Earth is a computer after all.

Elite is really primitive compared to today's games, but it had a huge galaxy to explore (even if all the systems were essentially the same 1-star-and-planet), then eventually you find out there are 8 such galaxies. It was fun to find good trade routes between the worlds, risk going to a slightly more lawless planet to beef up your credits or ranking. The emergence here would be the fact that the economic type of a planet was dependent on its seed value, and together with other nearby generated planets created "trade routes". These routes were not coded into the game, they emerge as a property of the way the procedural generation works out.

I think the problem with making so much procedural is that it misses the point that the game should be fun to play. What's the game-play difference in having random trees or dependent on sunlight and rain? In the end, they are just a bunch of trees :-P

Because when things "make sense," players pick up on it and use it to their advantage (and feel very clever). Given a procgen survival game where you are in a desert, trees might only grow near water, so if you are thirsty, you might look for vegetation.

Coming from a non-game developer this may be completely out of reason, but it occurs to me, what if you could determine the fit of creatures and evolve them in accordance with their environment? Perhaps not a lot of generations would be required to get a plausible, not completely random-looking scenario. Granted, we might still be talking about thousands of iterations, and so this would be too computationally demanding for a game design such as No Man’s Sky. But perhaps for a pre-computed (vast) world it would be viable.

NMS, otoh forces you to go from planet to nearly identical planet.

Players are already constructing crazy structures in the game. Why not implement that in the game for everyone?

Minecraft has a very young demographic, and griefing is a common pastime among bored kids hungry for attention and relevance.

Everything offensive can be flagged, and if it's a legit flag, then that item or location will become "infected" by one of the most hated, but most profitable to kill, enemies in the game. But my plan is to rig the spawning of player installations, such that players will only be able to do this by their own creations. So young people making penises in my game? Inevitable and co-opted to be a mechanic!

…which is a large logistical challenge that most game devs can't fit into their game or don't want to spend resources dealing with. Specifically "if it's a legit flag" is a requirement that implies a large team of people working around the clock.

But I completely agree with you - figuring out a way of working with the grain would be so much better. I would love to see more attempts toward it.

aka no man's sky.

Surely AI could solve that problem...oh wait, there is no such thing yet.