pick race based on birth location

Comments

• jjdale

  March 2022

  I'm not sure how finely you are actually splitting up your regions if you are talking about sub-sub-sub-locations, but in principle I would use a prompt to pick which table to reference, and you could then have other tables that handle larger blocks if you want shared data (just think about the weighting carefully in that case).

  So for example without any data...

  Prompt: Birthplace {North|South|East|West} West
  
  Table: RaceGenerator
  [@Birthplace{prompt1}]
  
  Table: BirthplaceNorth
  A
  [@BirthplaceNorthEast]
  [@BirthplaceAnywhere]
  
  Table: BirthplaceSouth
  D
  E
  [@BirthplaceAnywhere]
  
  Table: BirthplaceEast
  G
  [@BirthplaceNorthEast]
  [@BirthplaceAnywhere]
  
  Table: BirthplaceWest
  J
  K
  [@BirthplaceAnywhere]
  
  Table: BirthplaceAnywhere
  X
  Y
  Z
  
  Table: BirthplaceNorthEast
  T
  U
  

  That's not the only way to do it, just the first thing that comes to mind for me.
• OOldeMusicke

  March 2022

  I'm not sure whether your generator is choosing a random birth location given the race, or choosing a random race given the birth location, or choosing both randomly.

  You could add percentages to weight the results. The weights could be percentages if that's what you have, but they don't have to be percentages in general. For example (swiping from jdale):

  Table: BirthplaceAnywhere
  80:X
  15:Y
  5:Z
  

  If you're randomizing both, the main table could be something like:

  Table: RaceGenerator
  10:[@BirthplaceNorth]
  2:[@BirthplaceSouth]
  //etc.
  

  That achieves the effect of a sparse array: one table per birthplace, and then within each table, one entry per race that can have that birthplace. Or you could do it the other way round if that works better for your combinations: one table per race, and then within each table, one entry per birthplace for that race. It's sparse because you don't need to include the combinations that have zero chance of occurring.
• codevark

  March 2022

  I'd like to pick race based on location. But, there are a lot of locations. Re: sub-locations, you could have something like this:

  Maragaram (the world)
  The Archipelago (a continent)
  Mahar-Tlimë (an island-group)
  Tlimë (an island)
  Gedayenya (a city)

  or

  Maragaram (the world)
  Noom (a continent)
  Yammoe (an island)
  (some small town on Yammoe)

  And some of those most granular locations have race percentages which vary somewhat based on where in the super-location they are. And large cities tend to be more heterogenous - traders from somewhere else may have decided to settle there and raise a family. So, Gedayenya, where a large percentage of the population are Celoth, might have some Stepkin from Steppingstone, Kin from a number of areas, Ymxaphilam from Slade-Isle, a Puncu or five from Rock Isle, maybe Ags from Ag or Imlorr, or Mung from Belll or Irhiq, etc. (Just The Archipelago has about about 20 sub-regions, which have sub-sub-regions, cities, towns, etc. And there's about 12 continents/island groups to consider.)

  But Noom has human-oids (like the Kin) and maybe a couple of other groups which do not inhabit The Archipelago at all. Note I'm not even attempting to think about cultures or religions at the moment.

  I guess it depends on how "picky" I want to get, pun intended

  Maybe it would be easier to base location on race, though the number of possible locations varies a lot by race. The Kin are all over the place, but the Kordn and associated variations are 99% likely to be born on one of the islands of Kordûn, the other 1% possibly somewhere along the southern coast of Morrieol. So they would be fairly easy.

  Maybe I'll just do this whole thing in Delphi or something. But IPP is pretty cool
• codevark

  March 2022

  I guess if I did each continent separately, it would make things easier ha
• OOldeMusicke

  March 2022 edited March 2022

  Another way to go would be to not pin down every percentage of every relevant race in every subsubsubsublocation of the world in advance. Let a table create the percentages for you as you go, and not until you need them. In other words, this table would create a d100 table for later use, not an instantaneous result for a single character.

  The table's parameters could break things down a bit if you want, such as one parameter to pick the continent and another to pick the terrain, and then you'd create a table for each combination of parameters. Each combo has its own menu of possibilities (kobolds only on the western continent, pirates only in coastal areas, etc.). You don't have to plan in advance that the waterfront district of Lower Slobovia is 37% Green Elves whereas the nearby ritzy neighborhood is only 12% Green Elves. Let IPP make it up when you need it.

  Another approach: You can also fudge a sparse array with a table naming pattern. You might have tables named Home Northern Inland, Home Northern Coastal, Home Southern Inland, and so on. You'd invoke each table something like this:
  [@Home {continent} {terrain}]
  You'd need a separate table for every possible combination.
• codevark

  March 2022

  Could I associate a string with each "birth" location that would be a delimited list of appropriate race/%age pairs, which would get returned to the caller and then split apart into a new on-the-fly table for determining race? Don't even know whether that's doable.
• jjdale

  March 2022

  A "delimited list of appropriate race/%age pairs" is a weighted table. Why do you need to return it, isn't the intention just to pick something?

  A percentage is a weight that is constrained to being out of 100. That constraint will complicate things unnecessarily, so think about weights and not percentages. Weights are much more flexible than that. Are you trying to get that list so you can correct the percentages? If so, you are making it harder than it needs to be.
• codevark

  March 2022

  I sense that a lot of what I'm trying to do with IPP falls into that category ha
• OOldeMusicke

  April 2022

  If an "on-the-fly table" means you have one table create another table that you can call during the same run: nope, IPP doesn't do that.

  If you want one table to create material you'll use in the future, you could have it create syntactically correct IPP, and then copy & paste that to create a new table. It's just text output, in that case. That's doable, but it would probably also over-complicate things. That kind of code gets hard to look at and edit pretty quickly.

  I suspect that the simplest way out of this would be to drop the model that has you commit to lots and lots of percentages before you do anything. You might, for example, create a table for every location of interest, and then add "65:Humans" to every table where humans might appear, "20:Elves" to every table where elves could appear, and so on. If you have 8000 locations of interest, however, I think I'd start aggregating instead of giving them each a unique table.