Timesink, part 7: Schematics to bobs to oh god snore

There have been a few people that have asked how I'm getting buildings and such into the minecraft world. I can assure you that I am not lovingly hand crafting them. Today, I'll talk a bit about how I am doing it. It'll be a pretty boring post for anyone that doesn't run a minecraft server though.

First, let's start with schematic files. I'm not going to go into detail about what a schematic file is exactly. If you are really interested, you can visit other sites. Suffice it to say that schematic files are the way some applications and bukkit plugins allow server admins to save things made in game to a file and/or import objects into a server. There's a whole community out there where people make and share various schematic files. These files can range from trees to entire cities. The down side is that schematic files are not human readable.

There is a (somewhat) competing format variously called bo2, bbob, and bob. These files are meant to be used with the TerrainControl plugin. In addition to allowing admins to create some pretty amazing looking worlds, TerrainControl also allows for the placement of things like custom-made trees as the world is being made. What this means for an admin is that the world can be populated with ruins, giant trees, unusual looking cactus, etc, and it all gets added as a player explores the world, based on frequency rules and spawning locations defined in the bo2 files.

For example, one could have an igloo object and have it only appear in cold, snow filled biomes. One can also define whether the landscape is covered with igloos, or whether igloos appear in clusters. One really nice thing about bo2 files is that they are human-readable, basically defining an x,y,z:block type. There are downsides, but this isn't a review.

Now, there are tools out there that allow one to batch convert schematic files into bo2 files, so here's what I did:

1.) I decided on five different environments a player sees in a minecraft game--snowy, desert, plains, forest and swamp--and I started looking on http://www.mcschematics.com/ for building types that would fit the environments. For example, the desert environments have lots of sand and not so much wood, so I chose building types with lots of sand, sandstone and stone. In general, things worked out like this:
     Desert- Ancient Egyptian/Sumerian/Babylonian/Arabian styles
     Snowy- Chinese/Japanese styles
     Forest- European Medieval styles
     Plains- Ancient Greek/Roman/Byzantine styles
     Swamp- Mayan/Aztec/Khmer styles

2.) After I had accumulated enough municipal buildings, temples, towers, monuments, houses and shops for a given style, I would convert the schematics to bo2 files.

3.) I batch replaced certain block types to make the styles look more uniform. For example, I decided the Swamp architecture should not have any wood and should mainly use cobblestone. By replacing more exotic materials (like a diamond step pyramid) with materials more in line with the rest of the buildings, it makes sure everything seems consistent.

4.) Dialing in the details about how often buildings appear was the hardest part. Partly based on the area of the building, partly based on the type of building (municipal buildings, temples, towers, monuments, houses and shops), I would experiment with settings and then see how things looked.

So there you have it. The details are far more boring than this boring-filled post could take. At this point I have all my architecture types sorted and am pretty happy with the resulting cities. Next post I'll talk about how I'm using a python script to help me place the cities.

Timesink, part 6: Home, home on the range

I think I've finished the architecture types for the culture that will appear in the more grassy areas of the game:

I still need to monkey with the frequency at which things appear, but I'm nearly ready to start really putting the things onto the server.

Next time, where are these buildings coming from and how am I getting them to appear in the game.

Timesink, part 5: Woodland architecture

I think the building types destined for wooded areas are finished:

I think the only environment I have left are the more grassy plains.

Timesink, part 4: A way to get around

YEAH. THERE ARE SPOILERS HERE.

While I've been planning the placement of cities and their architectural styles, I had a vague idea of how I'd like to see players get from one city to another, but there really wasn't an existing mechanism in place.

I guess I should explain a bit about multiplayer Minecraft for those that don't know anything about it.

Mojang, the company that makes and sells Minecraft provides a server people can use to set up multiplayer games. But the truth is that it isn't very good. There's a server made by a group of enthusiasts named Bukkit. The appeal of Bukkit is that anyone can make plugins to extend the server, and the range of plugins is quite extensive at this point. There are plugins which allow admins to protect their worlds from goons, provide new ways for players to craft items, and even change the basic game mechanisms.

One of those mechanisms are "nether portals". These portals are meant to allow players to move to a different world which is sort of a hell-world. Lot's of fire and lava. For a long time, though, portals did not work on multiplayer servers and plugin designers seized upon the fact. Pretty quickly plugins emerged that allowed players to use portals to teleport from place to place on servers. Eventually portals worked as designed, but the teleportation-style plugins stuck around, most of them having a Stargate theme to them.

None of them allowed one to enter an address of the destination gate, which is really what I had in mind. I'm not a Stargate fanboy, but what I really wanted was a way players could somehow enter coordinates into a teleportation device. Just a few days ago, I discovered a plugin that fit what I was looking for. Appropriately named "Gates".

An example of a Stargate-inspired teleportation device on a Minecraft server.

Gates allows one to make gates and set how to dial them by placing items into a chest. In Stargate parlance, the chest then serves as a "dial home device" (dhd). After setting the items necessary to each gate A, one can teleport from gate B to gate A by placing the correct items, in the correct order, into the chest in front of gate B.

To translate x,y coordinates on the server into items in a chest, I came up with this realationship: the first row of the chest is what's used to place items, and there are 9 potential spots. Therefor, the first 4 spots would be for x, the middle spot left blank, and the last four spots for y. Specifically, the first 3 spots would be for x, the fourth spot would be a multiplier for x, fifth blank, spots six to eight(inclusive) for y, and the 9th spot the multiplier for y.

Perfect. To tone down the Stargate theme a bit, I thought I'd go for a more alchemical feel when it came to the items used to dial locations. Here's what I'm going to try:


Air (blank spot)=0
Earth (a dirt block)=1
Water (a bucket of water)=2
Fire (a bucket of lava)=3
Clay (water+air)=4
Brick (earth+fire)=5
Snow(water+air)=6
Cobblestone (water+fire)=7
Animal (an egg)=8
Plant (a sapling)=9

Ten items to be used in entering teleportation coordinates.

With these items, I have the digits 0 to 9, and can define numbers. For example, 102 would be a dirt block, a empty space and a water bucket. To get values greater than 999, then multiplier space would be used. I haven't decided what the x10, x100 and x1000 items will be though.

Another thing I want to include is a musical element. Minecraft allows one to make note blocks. These blocks can be activated in game by pressing buttons, so my hope is that I can set things up so that when a player presses a gate's button, it makes some hidden note blocks play. The notes played would correspond to the coordinates of the gate the player was at. So, by pressing the button and hearing the notes, the player could figure out the items needed to teleport _to_ the gate they are at. It'd also give them the x,y coordinates for their current location (see the previous post).

To help the player figure all this out, imagine that each city the player could find had a park or museum in it. There, the player could see small pillars that had items displayed above them.

An example of how items could appear.

Maybe there are even signs helping the player understand what number the object represents. And if the objects are placed in a circle, hidden note blocks could be chiming from under each item in a sequence.

Next post, hopefully more architecture shots.

Timesink, part 3: Did someone say loops?

SPOILER ALERT: Those interested in playing on the server and taking part in the story I am planning should probably NOT read the following. It won't reveal any specifics, but it will disclose technique.

I'm still working on the next architecture type that will be destined for more woody biomes, so I thought I would take some time to describe how I plan in placing cities in the Minecraft world in an automated, systematic way which will appear random at first, but will eventually allow players to figure out where other cities are.

As a plant biologist that models hoe plants grow, I'm interested in the Fibonacci numbers (http://en.wikipedia.org/wiki/Fibonacci_number). This sequence of numbers (1,1,2,3,5,8,13,21,34,55,89,144...) is cool for a number of reasons I won't go into here, an will only point the enterprising reader to Schimper (1836), Braun (1831) and Niklas (1992) for some thoughts on the relationship between the sequence and plant biology.

One can predict the next number in the sequence for values greater than 1 using the equation:

Ni=ROUND(Ni-1*phi)

where phi can be approximated as 1.618.

Given this, one can make some interesting visuals, such as spirals. If you were to decide you wanted to make a plot where the Fibonacci numbers are both the radius and arc length, and if you multiply the resulting x and y coordinates by the sequence number of the Fibonacci sequence, than you end up with a spiral like this:

Throw in a consistent multiplier to make those x,y coordinates be really big, and you can see how you can easily determine city locations that would be separated by so much space that it would be hard for a player to accidentally find a lot of them.

But, let's assume the player _did_ find some. In fact, let's assume that the player started in one of the defined locations. How could one encode information that would allow them to find other locations?

Well, assuming the player knows their x,y, they would need to know:

1) That the cities are placed in a spiral.
2) What the multiplier used is

The first can be hinted at by placing spiral motifs all over the place for the player to find. One could even find ways to visually show the first few numbers in the Fibonacci sequence; maybe as pillars which appear in a sequence of 1, 1, 2, 3, 5, 8, and 13 blocks high.

The multiplier could be encoded into an important, central part of each city. Suppose the multiplier were 400. One could place those Fibonacci pillars on a very plain box that is 5x5x16 blocks. One could even encode which Fibonacci number the city represented by having a circular plaza where the radius of the plaza was the number.

Let's do an example for clarification, and you can check my math. The player finds themselves in the center of a circular plaza which has a radius of 10 blocks. The circular plaza has a conspicuous spiral pattern in the blocks used, and along the outside of the plaza are small towers which are 1, 1, 2, 3, 5, 8, and 13 blocks in height. "A-ha!," says our hypothetical player. "I recognize that pattern of numbers!" A quick check on the internet and they can either calculate or look up the sequence of Fibonacci numbers.

In creating the spiral as I have described, one of the cool things is that the angle in radians for each successive Fibonacci number in the sequence is it's order in the sequence. For example, the first value of one, with an arc length of one and radius of one, would be 57.32 degrees or one radian. The second value of one and radius one would be 57.32 degrees+57.32 degrees(114.65 degrees), or two radians. The tenth number of the Fibonacci sequence, 55, would mean n arc length of 55 and a radius of 55, which would be 573.24 degrees or ten radians.

If our enterprising player has figured things out, then hopefully they will know that a radius of ten in the plaza would mean they are at a point that corresponds with the tenth location on the Fibonacci spiral (Of course, there is room for confusion since the ten blocks of the radius might be thought to be a part of the arc length/radius relationship. Any suggestions on a way to clear up confusion?).

So in theory our player knows _where_ in the spiral they are, but not where other cities are. If they assumed there was another location with a plaza with a radius of nine (i.e. the ninth city in the sequence), they wouldn't even need to know their x,y coordinates to find the coordinates of he next city.

X=N*cos(radians)
Y=N*sin(radians)

where N and radians are the same value. In this case:

X=9*cos(9)
Y=9*sin(9)

or x=-8.200172357 and y=3.709066367

And here's where our multiplier comes in. If the plaza the player is in faces our 5*5*16 monstrosity, and they multiply the x and y by 400, they get:

x=-3280.068943
y=1483.626547

Throw in some clever means whereby the player can enter coordinates into a teleportation device (think Stargate), and the player can find other cities to explore.

What bothers me is that the player would (rightly) assume that the center of the spiral would contain something interesting. I'd rather if they didn't just jump straight to the first point in the spiral, but haven't thought through how to prevent this.

So, thoughts? Is my math wonky? Too confusing?

Timesink, part 2

Just tested the architecture I had in mind for swampy, wet areas.

Some work still needs to be done to make sure the materials used in the buildings are consistant, but I'm really pleased with the test. Look at those temples embedded into the hills. <swoon>

Timesink, part 1

Just a edit test

I recently helped a friend set up a Minecraft server. I had set one up nearly a year ago, and had _some_ experience. Since the server became impossible to admin because of the frequent Minecraft updates (which would break the server), the Bukkit project has matured and become a really nice, solid server with lots of fun plugins.

While looking at plugins, I started to come up with a storyline that people could dive into on the server. Lost cities? Mathematical clues to finding them? A mysterious catastrophe? Yes, please, with a Coke.

For the past few weeks I have been working out ways to auto-generate cities; I'm willing to be Dungeon Master for the server, but I don't want to spend my life building pretend cities one block at a time.

Here are some of the first tests. A desert-type architecture (I know it's in a swamp)

and a colder, architecture

I still need to work on getting the building types for swamps, plains and forests, but these first two have shown me the steps I need to take.

Soon, I'll talk a bit about the mathematical puzzle about where to find the cities.