One Knight Studio © 2019

Search
  • Yukkafuzz

Humans (well, astronomers, and by extension, humans) actually know a lot about space. As a developer of a space game, I feel a responsibility to learn enough about what we know so that when I portray a faraway solar system or another galaxy, it rings true within the player (who could be an astronomer). That does not mean that EXO targets realism, however - it still needs to be a game, and with what we know, actual space would make a terrible game! Most significantly, light-years of space separates interesting parts of a galaxy, and we know no way to move significant matter at speeds faster than light; no one wants to sit and wait years as they travel between systems. Real things are the inspiration for anything, and it would be foolish not to use our knowledge of space at least some, but when, and how much exactly, should realism be applied in EXO: Perl?


As much as possible while preserving the "game" moniker, I might say. Borrowing from astronomy is like free creativity. Nature contains so many cool surprises that we would not believe if they did not exist. People did not write science fiction about black holes until they were already theorized through science - perhaps no one thought of such an object, or they decided that it would be far too outlandish, even for science fiction (which would be saying something). For a game focused on exploration, the enormous variety of objects astronomers have discovered across the universe reduces the challenge of coming up with compelling, at least believable objects and sites to discover; most of these can be taken from, or at least based on, those we have found in nature.


On the flip side, knowing what astronomers do can pose its own challenges. I wrote last week about creating terrain that has variety but still feels plausible, and that's just one example. If we knew less about the mechanics of a solar system - like how gravity determines orbits, and how the star heats up the objects - creating a system would in some ways be easier. I've had to wrestle with preventing moons from orbiting far away enough from their planet that another planet's gravity would clearly influence them, and similarly stop planets from being put in orbits too close to one another - except when their gravitational dependence is accounted for with a binary planet. I also find myself repeatedly slightly changing the way planet temperatures are determined, which depends of course on the size and heat of their star as well as the planet's distance from it, to try to keep the temperatures reasonable most of the time.


Of course, sometimes I make the intentional choice to ignore what humans know. Just as in almost all science fiction, alien, intelligent life is commonplace in EXO. It's almost certain that alien intelligent life is extremely rare, just as it is almost certain that it exists in our galaxy - it's a numbers game. But one of the most intriguing parts of exploring space is meeting and interacting with the denizens of the galaxy, so they can't be made to be so rare you're not likely to find them. In a similar vein, astronomers estimate that 85% of all stars are red dwarfs (thanks, Wikipedia), which leaves only 15% for all the rest of the types of stars to be found. It would get pretty dull if 17 of every 20 systems you went to were red dwarfs. That said, red dwarfs will still be the most common type of star (at least, in a typical galaxy of an age similar to the Milky Way), but it might be more like 33% - 50% of them, rather than a full 85%.


With these adjustments, my main tenet is Things that are rare should stay rare. Now, that may be jumping from one in a million to one in a thousand, or from astronomically rare (or at least, unknown rarity) to happening once every twenty or thirty systems - huge boosts, many orders of magnitude more common than realism - but this way they preserve a sense of "whoa, I just discovered a cool thing!", something I think is lost in many space games. I won't call them out here, but games with multicellular life or even intelligent-life settlements on every single planet just destroy all the joy in discovering those features. After going to about three planets, you expect to find life, and it would actually be cool to find a totally barren planet. Desolate worlds are part of the fascination of space, and they play foil to the lush Eden planets that should be oh-so-rare.


-Yukkafuzz


P.S. I leave you with a picture - look carefully! There are 4 objects: a planet, one of its moons, and two of that moon's orbiters!


  • Yukkafuzz

Creating or generating terrain is one of the most common problems in game development. Whether the game is a 2D platformer like Mario, a massive 3D open world like The Witcher, or an infinite universe like EXO: Perl, the player needs a space to walk around in, and for that you need terrain. For many games, designers hand-create all of the spaces the player can explore; in a platformer, this level design makes or breaks the game, so that makes perfect sense. However, as games have gotten more ambitious with the size of the playable area, developers have looked to computer-run algorithms for help quickly creating large swaths of land (or even the insides of buildings and other inorganic spaces).


I would say two main goals exist for terrain generation: realism and variety. It's not too difficult to have a computer generate a fairly realistic infinite desert expanse, but anyone would be quickly bored of their surroundings. There need to be oases, massive dunes and maybe some pyramids to spice things up and keep it interesting. Even better, have the computer choose to end the desert and begin some mountains, and then an ocean after that. However, the fundamental problem is the true processes that govern the shape and appearance of terrain are horrendously complex. Tectonic plates here on Earth have created mountains, and wind and water erode them; the water comes from precipitation, which depends on sunlight evaporating water over the ocean, temperature currents carrying that water vapor over land and eventually accumulating enough to fall from the sky; but it could be snow, hail, or rain, depending on the temperature. All of these pieces, happening over eons, determine the shape of mountains. We can't reliably simulate the resultant shapes, despite all the knowledge we have about it. So how can we possibly create the terrain of other planets realistically?


Of course, we can't. But we can use controlled randomness to create reasonable approximations of the terrain we can find here on Earth, so there's no reason we can't do the same for the virtual exoplanets. That doesn't mean it's easy, though.

Gotta love testing.

Just on Earth, the number of materials you can find yourself walking on is astounding: all the different types of minerals, rocks, clays, grasses, not to mention the human-made ones. But when roaming an exoplanet, there's some expectation to be able to find something totally new, not seen anywhere on Earth. At the same time, it should feel within the realm of possibility somehow. The picture above was just me testing, but it illustrates a point. We, as humans, do not know that there's no planet with vibrant stripes in the terrain, but we immediately discard it as "unrealistic" anyway. Now, I might accept some red/purple terrain like that on the left if it existed on one planet I ever found, because that could be the cool, unusual thing about that planet. But as soon as it appeared again, even one other place, it would almost ruin the fantasy of finding unique places across space. Furthermore, even a planet with that left stripe lime/yellow color combination in some of its terrain would lessen the novelty of the original red/purple planet. However, the terrain on the right I would not say is notable, probably because of the much more muted colors; though, if that exact green/gray appearance was everywhere, it would get dull. This poses a quandary for the developer: provide the possibility of "cool" terrain types, and hopefully with large variety (change something other than color to make it "cool"), but don't have them too often, or it will appear unrealistic. Oh, and don't use the same "not-that-cool" terrain either, because that will seem boring (and unrealistic again, since different planets should have different types of terrain).


A couple of approaches exist here: design all of the material types by hand, and only let the algorithm choose between them. This guarantees that the materials that can be found will be realistic (at least as much as I, as the developer, would like), and that different materials will look significantly different. However, some potential for "unique" is lost, as I would be working with a finite set of materials, so I could not easily guarantee that one be used only on one planet. Instead, an algorithm can generate appearance of the materials, but the designer loses some control over the results. It takes a lot of careful tuning of parameters to get the algorithm to produce mostly reasonable textures, and even more to avoid each one feeling too generic, despite technically being unique.

You can barely distinguish these three algorithm-generated textures.


These three are an extreme example - I've kept a lot of control over the results, to get a mossy appearance - but it's so much that I might as well have just hand-designed one of them. Nothing was gained by using an algorithm.

Changing a couple of settings, random textures from the same algorithm can look quite different.


The color scheme change for these three might be too extreme, but at the same time, the character of the small features is quite similar between all of the them. That character can be changed using a different type of noise algorithm, like below:

Notice the cell-like character of the details, contrasting the previous set.


We can combine these two types in varying amounts, which can change the fundamental character of the texture from one to the next (as below). However, this increases the performance cost of generation, and, perhaps more importantly, it's another place you cede control to the algorithm. I wouldn't want a cell-like texture like the middle one above as grass or moss. But at the same time, perhaps I should not limit the algorithm to producing textures mimicking materials we know about. It might be cool to find this strange, organic-looking terrain.

Combining types of noise algorithms can produce variation in "character" of textures.


The texture/color of the terrain is only one piece, of course. These principles also apply to the larger shape of terrain. Mountains, craters, caves, plateaus, flats and more all could exist on exoplanets, and so could some strange land features we have never seen.

Chaotic terrain like this needs to be limited.

Since I make use of noise in the same way for land shape as I do for texturing that land, you can imagine the many possibilities and the time it takes to consistently produce realistic but variable landscapes as well.


-Yukkafuzz

  • Yukkafuzz

Last week I wrote about how liquids caused me to decide to swap to a spherical coordinate system. In that post, I sort of snuck that in there like it was a small little change - at the time, I knew it was more significant than I made it sound, but as it turns out, it was even bigger than I expected in terms of work to put in. This week has been filled with cleaning up all the details involved with the swap.


Rather than go into the gory details, which involves a lot of math going between spherical coordinates and Cartesian and discussing meshes, vertex density, and stitching, I take a step back to look at the decision as a whole. Way back when I began developing terrain generation, I remember carefully considering my options:


1. A surface that stretches infinitely in two dimensions with height and depth modulation

  • quick to implement

  • can take advantage of Unity-run gravity, skyboxes, and more

  • can never walk all the way around a planet

2. A surface that stretches in two dimensions, but loops back to simulate a planet surface

  • a little more realistic than the previous option

  • can take advantage of Unity-run gravity, skyboxes, and more

  • more or less impossible to make the looping act as a sphere - a cylinder is the best you can do

3. A sphere constructed with a Cartesian grid (the system I had chosen)

  • quick to implement

  • terrain divisions are the same size everywhere

  • areas of the planet that should be flat will appear to have bumps

4. A sphere constructed with a spherical coordinate grid (the system I have now)

  • more complex with coordinate system conversions

  • terrain divisions will get smaller as you go toward the core and the poles

  • flat surfaces will appear flat


I eventually discarded the first two options because they could not be made to properly simulate a sphere, which I decided was critical to the space exploration experience - planets are going to be far smaller than a realistic size to allow actually walking fully around them. Between the other two options, I chose 3. because I couldn't think up a clean way to avoid the terrain splits ("blocks" of sorts) from getting extremely small at the poles and core, and I thought it would be cool if players could truly go everywhere on the planet.


So what changed? Well, I underestimated how awkward it would be having non-flat surfaces where they should be flat. I mentioned last week that it looks okay (but not amazing) for solid terrain, but really just looks wrong for liquids, and I really want liquids to be part of the terrain generation, not added on afterward. I also did not consider the number of potential solutions to the problem with the spherical system, where I am now using a sort of hybrid grid at the poles to mitigate the extremely small terrain that would occur otherwise.


Making a switch like this - a pretty large system fairly late into its development - can be pretty frustrating, especially with how much thought I put into the initial decision. It's important not to fall into the sunk cost fallacy, though; "never sacrifice design" has been a principal principle (I couldn't help myself) I've gone by. As that design changes, or as the design priorities reveal themselves, it's important to be willing to axe large bodies of previous work to accommodate the change. In the terrain case, most of the work I had done could actually be reused thanks to careful code implementation the first time, but what felt really bad was needing to totally redo a liquids system I had pretty much just completed. Again, never sacrifice design even when it makes it feel like you wasted a few days. The work put in to creating these new features is what clarifies the design, and so it is not truly a waste.


-Yukkafuzz