setting images depending on surrounding

Newbie & Debugging Questions
#1

I am writing a small game to learn path finding(which was quite easy by the way!:D). It is kind of a tower defense game where you get to build the walls yourself, and I’ve run into problems.

I first implemented walls as multiple different classes, each with different images and I then allowed the user to chose what his wall should look like by picking different classes.

Some image examples to make things clearer:

Now my problem is that I instead want to use only one class - Wall. And I want the class constructor to calculate what image is the correct image. I have tried some different solutions but they all come down to me realizing that they will probably work but they will take a week to write and a year to debug because they will be so long and so messy.

Basically what I have had in mind is, when a wall is created it will look around its 8 neighbours: (X beeing the wall itself)
1 2 3
4 X 5
6 7 8
and check which are walls, then select image using a bazillion of if-phrases and then notifying all the walls nearby that “I am new, check your surroundings again and update your images accordingly”.

My problem is that to do this, my only idea is to go like:

if (map[tileY-1][tileX-1] instanceof Wall && map[tileY-1][tileX] instanceof Wall .... && map[tileY+1][tileX+1] instanceof Wall) {
	setImage();
} else if (!map[tileY-1][tileX-1] instanceof Wall && map[tileY-1][tileX] instanceof Wall .... && map[tileY+1][tileX+1] instanceof Wall) {
setImage();
} ... {
}

But this would just be so insanely long and complicated to read through it just don’t seem like a very good idea. I mean it would be like 2^8 if statements?:confused:

So I decided to ask you guys! How can I solve this?

#2

There was a technique that was usable for this. I faced the same problem with tile transitions recently, and I found a really good article here on JGO about it. I can’t for the love of god find it right now, but someone should remember it!
You basically need to generate a unique tile for each combination of neighbors, meaning you’ll need 2^8 different images (you’re aware of this, right?). Let’s say you have these images loaded in an array:

Image[] images = new Image[256]

Now for each combination of neighbors you need a unique index in this array. You can easily get this, but you still need eight if-statements. The idea is to use a byte’s bits as neighbor flags.


int tile = 0; //The tile index.
int i = 0; //Current bit to modify.
for(int y = -1; y < 2; y++){
    for(int x = -1; x < 2; x++){
        if(x == 0 && y == 0){
            continue; //Skip self
        }
        if(map[tileY + y][tileX + x] instanceof Wall){
            tile += 1 << i; //Set the bit on the i'th place to 1.
        }
        i++;
    }
}
setImage(tile);

Really bad code, but it should work (barring any spelling errors, programming in post FTW) right away, if you have all the 256 images ready. The tricky part is getting the images in the right order. In this case index 0 would be a lone wall with no neighbors:

...
.#.
...

1 would be a wall with the top left neighbor also being a wall:

#..
.#.
...

2 would be a wall with the top neighbor also being a wall:

.#.
.#.
...

3 is 1 plus 2, so it is both top left and top:

##.
.#.
...

4 is top right:

..#
.#.
...

5 is 1 + 4:

#.#
.#.
...

E.t.c…
I hope you get it. xD Some more examples:
2+4+32=38 is the 5th image of your example images.
1+2+4+8+16+32+64+128=255 is the 4th (all gray) image of your example images.

#3

Yeah, thanks I got some help over at slick forums and I am on my way to solving this completely, just takes ALOT of time to make all the images required since there’s 255 neighbourcombinations!:stuck_out_tongue:

Here’s the post on slick forums if anyone has a similiar problem some time and finds this thread:
http://slick.javaunlimited.net/viewtopic.php?t=3692

#4

Sounds like you are already well on your way to a solution. But I thought I’d share something I came up with using a Hex tile grid. http://www.Hexara.com/gameNS.htm in it, various searches of neighboring hexes need to be done to update the status as to whether a “scroll” chain is present or not.

To do this, I maintain a tree representation of the grid, separate from the grid itself, optimized for recursive searches. For example, each “searchHex” has a LinkedHashSet of all neighboring searchHexes, and an array of booleans to mark whether a searchHex has already been touched or not, as well as the appropriate state values needed.

Separating the structure used for the searches from the representation used for display makes a certain sense. You will probably find performance pickups by making the structure one of aggregation that is as immutable as possible, allowing for concurrency optimizations by the JVM.

#5

[quote]I use the following values:
1 2 4
8 X 16
32 64 128
[/quote]
My first code example generated these exact values…
Tips: By only using the direct neighbors (not the diagonal ones), you only need 2^4=16 tiles. It’s also possible to divide the tile into 4 smaller tiles, and then you only have to check 3 neighbors per tile, resulting in only 5 different subtiles. The tiles images are 1/4 times as large, and you only need 5 of them to represent all 256 tiles you need. The only problem is more repetitive patterns of your tile, but this can be solved by having multiple (say 5 or so) slightly different tiles for each compination:

My/your solution: 256 images, tileSize^2 * 4 * 256 = tileSize^2 * 1024 bytes.
My proposed solution: 5 images, (tileSize/2)^2 * 4 * 5 = tileSize^2 * 5 bytes.

Even if you multiply my proposed solution with 5, it’s still way lower than 256 images.