Timesink, part 8: Automating city placement with python (and some Excel help)

People actually read this? Well gosh....


It has been a while, and before I start talking about how I largely automated city placement, let me offer an explanation as to why it's been quiet.

To avoid a tl;dr version: the computer hosting the minecraft server had several drive die one after the other. One of the drives had the running server. Another had the backup.

Dust in the wind.

Couple that with the release of Minecraft 1.2.3 (and now 1.2.4) and the lag between Minecraft updates and plugin updates, and things have been really dead.

Things are officially back up, though. A brand new world for people to explore.

But in the last post I said I would talk about the tools I'm using to automatically place cities, so let's get to that. Warning: this is a pretty boring post.

If I just wanted clusters of buildings to appear on the minecraft landscape, I could probably do that with just the Terrain Control plugin and the BOB files. What I'm trying to accomplish is complicated by the fact that

1. There is a mathematical pattern to where each city is
2. There are five distinct architectural styles
3. Each of the architectural styles appears in specific biome types, but are not strictly limited to a certain biome. It makes no sense for a civilization from a forest biome to refuse to build anything in a plains biome just to the west, for example.
4. If you are placing more than 20 cities, the process of teleporting to a set of coordinates and waiting 10 minutes for all the buildings to render (sometimes it can take longer depending on the buildings being placed) is tedious and should be automated.

To address the first point, I made myself an excel worksheet (which I'm happy to make available if people are interested).

The user enters two values--# of cities wanted and a scale multiplier (see post "Timesink, part 3" for details)--and then places a * next to the in-game spawn location, and the sheet does the rest...with the exception of the biome type. I'll get to that in a bit.

As a guide to understand the excel sheet, things which are underlined are things which the user must input. Anything in italics represents something which has been automatically calculated. Bold things are just headers. It's a convention I worked out for myself many years ago to quickly allow me to look at an excel sheet I made (maybe years ago) and understand what are the inputs and outputs.

The excel sheet assumes that at the center of my spiral is some sort of main complex. The Capital or Holy City...something. Of course, if you have a Holy City, you probably think of it as being the center of your world; your 0,0 starting point. In the story I'm working on for the server, the main city and the new player spawn point(set to in-game's 0, 64, 0) are different. This is why the excel sheet calculates a city's coordinates from the Holy City's perspective and from the in-game spawn point's perspective.

In the example excel image I posed city #3 is centered at in-game coordinates -203,595. That same city, if one assumed the Holy City was 0,0 is at -75, 164. This allows me to use the in-game coordinates(-203,595) to go to that location, but use the story related coordinates(-75,164) to provide a gate address to reach the city(see post "Timesink, part 4").

What my sheet can't do is tell me what biomes are at those coordinates. For that, I used screen and python.

If you are not familiar with screen, you can think of it as a command-line way to keep a "window" open, even if you are not actually connected to a computer. In practical terms, it means one can log into a computer, make a screen session, close your connection, and the computer you had logged into continues to behave as though you are still logged in. It lets one start and keep a minecraft server up and running even when one is not logged into the host computer, for example.

You can name your screen sessions, which then allow you pipe commands into the session. For example

screen -S minescreen

will start a new screen session named "minescreen". And we can send it commands from a python script.

To determine what biomes are present at various coordinates, I wrote a quick little python script that tells the cratbukkit server running in the "minescreen" screen to force a player (me) to teleport to a location and then force the player to query what biome they are in. Wait five minutes and repeat. The five minutes is because, just because you happen to land in an Ocean biome doesn't mean that's the biome you should use. If gives the user some time to look around and make a judgement about what the biome should be.

Write down the biome or notes in the Biome column, and you're ready for step two: splitting things up by biome.

I have split each of my architecture types up by biome and named the files and folders accordingly. The folders and files have common prefixes--"_swamp", for example.

This allows me to use command line tools to move files found.

Now, I admit that this isn't the exact script I used; I cleaned it up for posting so it might not actually work lol. When I was using it, I would do a single biome type since that means 10 or more cities were placed, and it often took a few tests to get the right settings for the BOB files to make sure there were a decent number of buildings, but not too many, and not too much overlap as buildings were rendered on top of or into other structures.

So I think that's it. As of today, the server is back up, all the cities are placed and I'm starting to place the Gate rings. There's still a lot of testing that needs to be done to makes sure all the plugins are working as they should.

Left to do:

• Place all the Gates and test them
• Start writing the messages from the enigmatic "H" who acts as the players absent guide and breadcrumb leaver.