Creating new planet types

[gaerzi]

I'd like to make myself a mod with more planet types for variety's sake. Here are my notes so far, feel free to point out if I'm overlooking anything.

• Drawers/Planets/ dir with planet type
  • Lua file with same name as directory contains rules for rendering the world type
  • Source images: height map + layers, including at a minimum a color map
  • City lights are handled with layers too, up to three levels of land use, and two shallow + one deep layer for oceanic uses for water worlds
  • Clouds usually point to the Garden world, so it's possible to refer to another planet type instead of duplicating, at least for clouds
  • Smoke and smog effects are also applied with layers
  • Ice caps are usually applied as layers too, allowing worlds to be rendered with or without
  • Desert and Steppes are just variants of Arid
• Encounters/planet_event_helpers.lua: supergrain resource candidates (by default: 'Coral','Island','Paradise','Garden')
• Galaxy/planet_types.lua: planet descriptions, habitats, and habitability per race
• Galaxy/~habitat_info.lua: habitat descriptions
• GUI/~GalaxyMap/@PlanetPane.lua: planet overlays, some planet art substitution hacks to work around missing art (e.g. Paradise worlds all use Gaia's look)
• Orders/colonization.lua: list of "easy" and "harder" planets
• Orders/farming.lua: planet fertility rules
• Orders/terraforming.lua: terraformation rules
• Setup/epic_systems.lua: hardcoded special systems (Tyl, Ephelos)
• Setup/forced_planets_fun.lua: semi-hardcoded special planets (minor native races)
• Setup/home_systems.lua: hardcoded planets for each empire's starting system (can be useful for quick tests)
• Setup/init_star.lua: assigns planet types to randomly-generated star systems (meanwhile, init_planets.lua is all about star types, irradiance, and goldilocks zones)
• Setup/pirate_systems.lua: planet types for pirates and marauders
• Setup/planet_decks.lua: puts planet types in decks (common, rare, epic, exotic), hints about temperature ranges, rules for special resources
• Setup/special_decks.lua: planet-based chances of special things (derelicts, abandoned colonies, refugees, monsters)

[sven]

[*]Galaxy/planet_types.lua: planet descriptions, habitats, and habitability per race
[*]Galaxy/~habitat_info.lua: habitat descriptions

~habitat_info.lua also includes utility scripts for checking the equivalence classes implied by each planet type's habitats definitions. As explained in the long comment at the top of pop_growth.lua, if you create a new planet type (or new race) that groups the games races into more than 7 equivalence classes, you're creating an exotic bug; so fiddling with the habitat_info.lua scripts to make sure you're not doing that is an important part of the planet/race design process.

Of the various planet drawer definitions, Garden.lua is traditionally the best documented.

A planet drawer's get_layers function is a very powerful and generic tool for creating planet art that varies depending on various properties of the planet -- it can be as simple as just returning a single array like:

Code: Select all

return {  colors='base_colors' }


Which will just use a canned texture based on whatever's in 'layers/base_colors.png'. Or it can get far more complex, as one gets into city light patterns that vary with population density and so on. Confusingly, each planet drawer's get_layer's function is responsible for defining its own special rules for how to build up things like city light patterns and smog overlays and so on. And there's not really any clear standard here -- older assets like Garden.lua work quite differently than more "modern" drawers like PhidiHome.lua.

The main thing worth knowing about city lights assets is that different assets use different downsampling rules -- from experience, we've discovered that you generally want sparse city light images to be downsampled differently than dense city lights. Thus, there are actually 3 different supported city lights layer types, each of which are handled differently by the downsampling logic in @PlanetImages.lua. (For the gory details, look at the mipmaps table definition in @PlanetImages.lua.)

[gaerzi]

~habitat_info.lua also includes utility scripts for checking the equivalence classes implied by each planet type's habitats definitions. As explained in the long comment at the top of pop_growth.lua, if you create a new planet type (or new race) that groups the games races into more than 7 equivalence classes, you're creating an exotic bug; so fiddling with the habitat_info.lua scripts to make sure you're not doing that is an important part of the planet/race design process.

Okay, so is this the explanation for this bit?

Code: Select all

planet_type 'Garden' {
 
  --reef = 1, ocean=2.5,  forest = 1.28, arid = .5, ice=.5, vents=.5,

  reef = 1, ocean= 2.3, vents=.5, forest = 2,


removing arid and ice from the Garden world, even if they made sense (one can see deserts and ice caps) gets the number of affinity combos down. I wondered if it was a game balance decision but the combinatorial explosion issue makes more sense.

I fired up Excel, filled some values in a spreadsheet, and came up with a quick and dirty way to get the number of unique affinity combos when all the game's races are present on a world. (Basically: for each race get a single number created with airless affinity + 6 times inferno affinity + 36 times vents affinity + 216 times ice affinity, etc. Then count the number of unique values with sumproduct(1/countif(cells;cells)). It's slightly more involved than that since I can toggle each habitat on and off, by setting a habitat factor cell to 0 or 1, but that's the gist of it.) I went with powers of six as it was, for values within the [0.8, 4.0] range, the smallest integer that made sure each possible value was non-ambiguous, e.g. with powers of 5 then the value 4 can be either 5*0.8 or 1*4.

Barring any logic error on my part, putting all the game's existing race on the current 4-biome garden planet results in 5 unique combinations, while on the commented-out 6-biome version we get 8 different combos. Adding back either ice or arid would be fine (6 or 7 combos, respectively), but not both.

Anyways, since I was planning on having new habitats on these planets, and eventually on adding new races, that'll give me one thing to watch out for.

[sven]

removing arid and ice from the Garden world, even if they made sense (one can see deserts and ice caps) gets the number of affinity combos down. I wondered if it was a game balance decision but the combinatorial explosion issue makes more sense.

Again, as explained in the long comment at the top of pop_growth.lua, the choice to leave out both Arid and Ice bioms on Garden worlds is really about both the combinatorial and game balance implications. Weird stuff starts to happen gameplay wise when you have small bioms that can imply very slight advantages for bringing in new species -- for example, humans are a little better than Ashdar at tolerating Ice boims, so if we have a small ice biom on a Garden world then there's a small but noticeable incentive for an Ashdar player to import humans onto all of their Garden worlds, which feels kinda excessively fiddly. Including Ice bioms on any planet also boosts the Yoral's pop caps on those worlds, and I felt like the Yoral already had more than enough habitat perks, without making them even stronger on Garden worlds. But also, yes, as you noticed, the commented out Garden definition would imply 8 equivalence classes, which could break the game if you somehow got the wrong 8 races cohabiting a garden world.

I fired up Excel, filled some values in a spreadsheet, and came up with a quick and dirty way to get the number of unique affinity combos when all the game's races are present on a world. (Basically: for each race get a single number created with airless affinity + 6 times inferno affinity + 36 times vents affinity + 216 times ice affinity, etc. Then count the number of unique values with sumproduct(1/countif(cells;cells)). It's slightly more involved than that since I can toggle each habitat on and off, by setting a habitat factor cell to 0 or 1, but that's the gist of it.) I went with powers of six as it was, for values within the [0.8, 4.0] range, the smallest integer that made sure each possible value was non-ambiguous, e.g. with powers of 5 then the value 4 can be either 5*0.8 or 1*4.

If you change the 'false' on line 174 of ~habit_info.lua to a true, and save the file while the game is running, the live-coding features will cause the F1-console to get some spam that does these sorts of calculations using the game's own equivalence class calculation logic -- outputting groupings for all the planet types currently defined in game.

Barring any logic error on my part, putting all the game's existing race on the current 4-biome garden planet results in 5 unique combinations, while on the commented-out 6-biome version we get 8 different combos. Adding back either ice or arid would be fine (6 or 7 combos, respectively), but not both.

Hmm... There may be a bug in your excel sheet (or you may be missing a race or two). By my calculations, there are 6 distinct equivalence classes implied by the current 4-biom Garden definition. Specifically, if you have a Garden world with Yoral, Gremak, Phidi, Humans, Orthin, and Tinkers, they'll all have different implied population growth behaviors. (Any of the other races will behave like one of those 6 on a Garden world though.) (You're right that the commented out code does imply 8 different groupings, which is indeed one reason why I never shipped it.)

[gaerzi]

You're right, one of the factors was wrong.

[gaerzi]

A file I had missed:

• Orders/coin_production.lua: "hostile environment" costs

[gaerzi]

Another art question: what's the projection on the planets? The problem I have is that my planet textures look very Mercatory (huge icecaps) while the vanilla SIS planet textures look more like equirectangular, so my new planets in-game look really weird with squished tropics.

[sven]

Another art question: what's the projection on the planets? The problem I have is that my planet textures look very Mercatory (huge icecaps) while the vanilla SIS planet textures look more like equirectangular, so my new planets in-game look really weird with squished tropics.

If memory serves, it's equirectangular. (Mostly because it makes the math simple -- I don't have strong opinions on map projections.) Um, I'd imagine it's possible to find tools for converting from one to the other.