Monday, July 4, 2016

My World, Part 1

I hope one day to run a world based on the Earth, but I'm not rushing to get there, just building one piece of the game rules (and tools for running it) at a time. In the meantime, I have a small fantasy world that I've put together as a place holder, which I can certainly use with no problems. Here is a picture of a small chunk of it. The scale is 20 miles (face to face) per hex. The text may be a little hard to read due to the conversion program: sorry about that.



Let me walk you through what these tools I keep talking about look like, and how my world works at this time. In this series I'll take you through all the pieces of the system that culminate in the price table you saw in this post. You'll learn how the systems that I have made currently function. Once again, I'll stress that the price table, and this infrastructure which builds it, is all inspired by Alexis over at the Tao of D&D. The map tool, which I'll get to in due time, is all me. It was originally the idea of a system which would be able to output data for both a map tool and a trade table which inspired me to begin work. I think it has been a fruitful journey so far.

Here's a diagram giving an overview of all the main chunks of the system. We flow from data about towns and resource production into calculations that give prices for each resource, at each town, and then calculate the cost of goods based on those resources and on the availability of services. This much I touched on in the pricing post, linked above.


Today I'll introduce you to Town Info. This file (which is written in Python but acts more like a database than a standalone program) contains data on each of the towns in my little fantasy environment: namely, the raw materials which are produced there, and the artisan industries which that town is known for. I usually call the former "resources" or "materials," and the latter "services." If you've read Alexis's description on his system, take note that at this time, all my towns are considered "markets;" thus, the players can buy the full selection of goods at each place. This is simply because my world is not as detailed as I'd like it to be -- but I consider D&D to be a lifelong project, so I am not worried about this or that area not having enough detail. One day I will get to everything.



So what are these numbers next to each resource and service? Those are the count (in abstract units called "references") of how much each thing is produced or otherwise available for use at that town. We'll return to these later. For now, let's talk about the end section of Town Info, which looks like this:



addConnection is a helper function that simply records the fact that a road links the two cities in question. You can check for yourself against the map above, and confirm that all the mentioned roads exist.

What is notably absent from this section is the question of which hexes a road passes through. This is especially important because passing between hexes with significantly different elevation requires extra travel time. Here's how I do it: within the World Generator stage listed above, I've programmed the computer to find road details for me. Given a connection between two towns (as recorded by addConnection), the program in question will find the shortest path between them, while taking the travel increase for elevation into account. Then it records the hexes of that path into the road's data. This is why not all roads are straight lines: for example, going around a hex with much higher elevation might only cost 2 or 3 hexes of movement, but going through it might cost 6: 3 to move in and 3 to move out.

If I chose to, I could change the program so that the exact hexes a road passes through could be manually specified. Or I could choose to change what the cutoffs are for differences in elevation between two hexes which increase travel time.

That's all I'll get to today, as it is the 4th of July.

4 comments:

  1. That's a remarkable tool. I'm rather jealous. And grouping the trade information in a database rather than Excel would make a lot of the formatting nonsense I'm working through trivial. Nice work.

    ReplyDelete
    Replies
    1. Thank you very much, Dani. I'm glad to be able to share my work with you. If you enjoyed this then I'll hope you'll stick around for further entries.

      Delete
  2. I want...

    Seriously, have you made further progress with this tool? Are you willing to share it?

    ReplyDelete
    Replies
    1. I am willing to share it, but it's not currently in much of a state to be used by anybody else unless they are also a programmer and can take what they need out of it. I have it in a GitHub Git repository but it's not up to date and won't be for a while, as I am currently gutting a lot of old code and tidying things up as I transition to running Earth as my game world.

      Click here to browse the repository and feel free to ask questions here on the blog. I'll be doing a post on the Recipe system soon -- working on code that will allow me to give some neat visuals which I think will help readers understand the logic more easily. If you go browse it now, I recommend reading RecipeDefinitions.py; it's the most approachable portion among those on which I have not yet blogged, but as I said I'll be writing about that soon.

      Glad to see you working through the old posts, Ozy.

      Delete