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 34 X 56 7 8and 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".

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:

1

Image[] images = newImage[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.

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 2 3

....#....

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

1 2 3

#...#....

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

1 2 3

.#..#....

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

1 2 3

##..#....

4 is top right:

1 2 3

..#.#....

5 is 1 + 4:

1 2 3

#.#.#....

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.

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.

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:

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org