Tiles - Joining them

Game Play & Game Design
#1

So I am in the process of designing a game but have stumbled across something that I am not quite sure on how to do.

So far I have designed this game with my own limits in mind, it is a very simple game and really the only difficult part is the small amount of networking involved.

Say I have a level that consists of a 32x32 Tile-Grid; 1024 tiles in total. This will be randomly generated and shall have varying types of “terrain” or type of tile.

Now a few types to note would be things such as Grass, Gravel and Rock. Now I want to have a varied amount of these on a single map, however my concern is this:

How would I go about joining these together to look nice? I want some sort of border between say Grass and Rock, but between Grass and Gravel I would just want a small fade. Now the most immediately obvious way is to make variations of each tile.

The problem…

This means each tile would have 9 different sprites. x1 without a border, x4 with a border going along each edge and x4 with a corner that matches. Surely there is another way of doing this?

What techniques can I use to achieve this? I imagine Rayvolution will be able to help me here as Retro Pixel castles draw tiles with the visual aspect I am wanting.

#2

Edge based wang tiles. EDIT: I intended to say corner based.

#3

That is a standard way of doing it. See e.g. http://opengameart.org/content/land-tiles-v2 or http://opengameart.org/content/grass-and-water-tiles

#4

There are various methods to join the tiles, I posted this in Ray’s thread actually: http://www.angryfishstudios.com/2011/04/adventures-in-bitmasking/

#5

I have one grass tile and, 192 variations with water at different intervals. At the same time, I also have 192 variations of the grass tile with lava. Im starting to think of changing the map perspective, So I can just design the map one tile at a time. Which wouldn’t need tile variations at all. Though it would drastically limit the view point of the player.

#6

You could probably also simply have a mask texture of the different shapes/border styles and use a technique like this: https://github.com/mattdesl/lwjgl-basics/wiki/ShaderLesson4

#7

The benefit to drawing the variations of each tile, Is that players can personalize their game experience. Much like Minecraft, Your players could modify the tiles. If, You do opt for tile joining, The ease of customization for players goes out the window. Which may or, may not be of interest to you. But, In my opinion would offer a more enjoyable game for modders atleast.

#8

Actually, if you want automatic transitions like RPC’s, you’ll need 16 version of each tile. (well technically more, but I cheated and managed to skip a few oddball ones). :confused:

Here’s a cutout of one of my terrains. I have random variations too, so really all that matters is the top row.

http://sixtygig.com/junk/terrainTransitionExample2.png

What I did in RPC is made the transitions not transition into any one specific tile, but into transparency. Then, I split up the terrain into multiple layers. When a player creates a map he selects the master “base” layer that will always be whatever terrain you selected, then you can draw terrain on the second layer over it (giving you the illusion of the tiles transitioning into each other). The downside though is you can’t combine transitions. Like if your base layer is sand, and you draw dirt on top that’s fine. But, if you then draw grass over the dirt, you’ll end up just erasing the dirt and replacing it with the grass. They will not transition into each other. You are only allowed to “draw over” the base terrain, whatever it is set to.

There are some ways I could of done to make it work, like having 5-6 terrain layers and the user making a map selects what layer he wants to draw on. That way he could “stack” terrains, in fact, that’s how the original version of the map editor was setup. But I removed the feature because it was tedious to use, and really ruins the experience for the mapper. The new way is very fluid and streamlined. :smiley:

But anyway, if you want true, quality transitions you’ll probably have to draw all the transitions. All the other methods I tried to procedurally generate them just looked awful and unnatural. (Well in pixel art anyway, maybe they’ll look better in something more modern). There’s probably some really complicated ways I could of worked out making the transitions automatic and know what layer to stick everything on to work out a system where everything could transition to everything else. But I didn’t want to over-complicate the process since the game mode itself has a lot of map manipulation going on as well. That and visualizing what the code would look like in my head doesn’t feel like something that could be done “live” and on the fly at a reasonably speed. :confused:

(Side note: It should also be noted I have rocks/trees/etc on it’s own unique layer, that can be drawn over any terrain. Further facilitating the illusion.)

#9

…that is nice.

Thanks for the replies. @Ray lol, 16 different tiles…It took me 15 minutes to draw a 16x16 pixel art stone tile. So yeah, I suck :smiley:

#10

15 minutes to hammer out a base design for one tile is normal. Sounds like you’re actually on the right track. :smiley:

People greatly underestimate how long it takes to draw good pixel art. Some of my tile sets for RPC took up to 2-3 hours. :o Good thing though is once you get one good tile done, replicating the design over and over to make the transitions and the variations is actually a lot easier, although a bit time consuming.

#11

I feel better now :p.

My tile does look kinda crap but only first draft, I am sort of making these to mainly practice. As my game idea needs graphics, may as well practice making my own while I use place holders :smiley:

#12

I’m trying to do the same thing, here’s the thread I started: http://www.java-gaming.org/topics/connected-textures/34406/view.html You may find some useful resources there. I haven’t managed to get it working completely, you might have better luck than me.