My World, Part 2

The first part in the series can be found here. I'll assume throughout that you've read it, but please ask if anything is unclear -- it's easy for me to forget whether or not I've talked about this or that part of the whole system.

Today I'll finish talking about roads, then give a brief overview of the environmental data I'm using in my world, and how it's generated.

So: roads. As I said before, I leave the calculation of the specific hexes in each road up to the shortest-path program I wrote. But there's no reason I couldn't manually specify some or all elements of this process. I could manually determine each hex in each road, or manually determine some of them and then leave the rest to the computer. Furthermore, I have a way to calculate distance based on number of hexes traveled and elevation differences between each pair of hexes, but if I didn't have that, I could certainly manually specify a road's distance as well. One day, when I've got Earth data in an appropriate format for plugging into this system as a replacement for Town Info and part of World Generator, I'll be forced to start manually specifying roads if I want to maintain a minimum level of correspondence with reality.

Now: I've mentioned World Generator a few times. This program's name stems from my original efforts to generate a world with regions, resources, city placement, etc. all specified semi-randomly on top of a Perlin noise elevation-generation system. Obviously I am doing manual city and resource placement at this time; however, I have retained, for the time being, the noise-generated elevation, as well as accompanying code which specifies the following:

• the elevation cutoff which determines whether a hex is land or water
• spreading of moisture inland from bodies of water
• temperature (roughly speaking: very cold at the pole, very hot at the equator, with intermediate values representing areas with season-dependent or otherwise variable temperature ranges)
• climate (based on a slight simplification of the Koppen classification, currently taking moisture and temperature into account, but not elevation -- which could always be added in, in order to properly capture e.g. the boreal forest climate type)

Thus, an approximation of one hemisphere of a planet is laid out in the large, with bodies of water, rainforests, tundra, savannah, desert, steppes, and so on. The area map I showed in the previous part of this series is located near the bottom-right corner of the hemisphere. Since we're looking at the hemisphere from above, "west" and "east" can only be defined relative to some point on the map. "North" means toward the center of the hemisphere, and "south" means toward the edge, the equator.

(To avoid using "north" to mean "up" (toward the physical top of the map), and so on, in my code I use the abbreviations UL/UP/UR and DL/DN/DR to refer to directions relative to the physical map instead of the above gameworld-internal concepts of "north," etc. These abbreviations mean up-left, up ("top"), up-right, down-left, down ("bottom"), and down-right: the six hexagonal directions.)

OK, that's roads and an overview of the relevant portions of the World Generator. The plan for next time is to talk about resource imports and pricing, and then I'll dig into the final stack of fiddly bits, which is the construction of recipes: the formulas which determine just what each object is made of. Placement of resources and services is important, but in my mind, the recipes are the goal of this system. The trade table(s) is the end product, the final result of my hard work.

And by the way: I'm at 93 recipes now, up from 74 in my first post a few days ago. I'll refrain from posting a new version for a bit. Maybe at 100 or 110 or 125 I'll post it again.

If you have any questions or comments, please post away! It's so encouraging to see people respond to what I've done, even if you're just giving a heads up that you're reading.