pick race based on birth location

Sooo.. I have an entire world with small continents/archipelagos. I have a generator for birthplace (which really should be modified by the specific campaign I intend to run, and which works, but is missing some sub-locations at the moment). I also have a Races generator which at the moment only includes races from one island group. I'm trying to figure out how to rewrite the Races generator to account for birth location. I'm guessing I would need to pass the name of the "region" (continent/archipelago) in question. It's complicated by the fact that within a region different races are more likely in some sub-regions than in others, and that some races inhabit one region but not another. (For example, the highly intelligent ursoid astronomers of Khastins in The Archipelago only apply to game settings in The Archipelago, and the reptilian T'soorn are only found in a completely different region, and are unlikely to ever encounter the aforementioned ursoids.) Maybe within the Races generator have a separate table for each region (passed in the call)? But then how to handle race distribution within a region? I could have a separate table for every sub-sub-sub-location, but that would be painful. Or, is there a way to modify the Locations generator to somehow return a set of appropriate races and %ages for the picked region, and use that info to control the Races pick? It almost begs for some sort of sparse array of Locations x Races...

BTW, I am a software developer. A little out of practice, and still wrapping my brain around how IPP works. :)

Comments

  • 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.

  • 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.

  • 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 :)

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

  • edited March 25

    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.

  • 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.

  • 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.

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

  • 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. :smile:

Leave a Comment