koobas.hobune.stream
How to calculate which tiles to affect in tile based game?
Hi all, sorry if this is fairly simple, but I've been working on it for a week or so now and can't seem to find a solution based on my limited programming skills.
So in the game, a bunch of tiles are instantiated in grid formation, labeled with their x and y location, added to an array, and then player can move from tile to tile one at a time.
Once you reach an edge tile, the game should calculate which overall section/collection of tiles from the first edge tile you left to the final edge tile you landed on, has the smaller number of tiles (or other similar queries). It should then change these tiles to whatever you'd like (for example, if all the tiles represent dirt, the new smaller section will change to grass tiles). So it isn't just the ones you've collided with, but each tile you've collided with closest edge neighbor and all the tiles in between.
It's a little hard to explain so I made an example gif here of the process, I hope it makes sense.
My problem is I'm struggling to find a way for the game to understand which tiles to affect. I've tried recording each tile you land on, then having all those tiles calculate which edge is closer, collect those tiles, and affect the tiles based on that. But the problem is if you walk in an irregular path, or occasionally close to one edge, it will affect tiles outside of the collective area, instead of keeping it all inside.
I'm kind of losing my mind and I'm sure there's a simple way to do this that I just can't get to. I'd love any / all suggestions on how to possible accomplish this? Thank you all so much in advance for giving this question a look. I'm using C#.
Use a an array int[,] map to flag the walked tiles with 1 and 0 the rest. After you finish the walk by reaching an edge you can run a flood algorithm to figure your regions, save em on an array and compare the Counts. After that you can select the one you want and do whatever to it. For flood algorthm check the Procedural Cave Generator Tutorial (GetRegion()). The hard part on that is how you gonna know from where to start the algorithm run an ,kinda, efficient way would be to start with the (0,0) tile get the region it produce. Then get the next edge tile check if it is contained in the region you already have, if not run the algorithm with that tile as starting point, now you have a second region, note that region would be different type from your first one (if first one is 0 as unwalked this one will be type 1, your path). At that point you have the one unwalked region and the walked one. Continue with the next edge tile. Check again if it is contained by the other two regions if not run again the algorithm. As soon you have 3 regions you are done. Compare the 2 unwalked ones figure which one you want to change. For a small map you shouldn't have any proble with performance, although for a large map it will be a bit slow and require more memory. Hope that helps. (Note: There are probably more efficient ways to solve this.)
Thanks so much for the reply PizzaPie, it's definitely given me some new avenues to explore in how to solve this problem. The tutorial you referred to seems to be dealing with exactly what I need, so now I just need to figure out a way to really parse the info presented and apply it to my project, as he seems to be using more advanced techniques all the way through (for example, I'm, I realize stupidly, holding all tiles as GameObjects in a list from 1 - 16000 in consecutive order ins$$anonymous$$d of as X, Y co-ordinates, which would help a great deal).
So for clarification, the steps seem to be:
Create an int array of tile references, and shift them 1 by 1 as the player walks through to create a map during calculation.
Once the player completes a path, run a flood algorithm on the int array to get total tile counts (should return 3 separate batches of tiles). I suppose you could start this at the players last known position, since you'd have a walked tile and then either side of it would be a different region.
Once you have tilecounts of all three regions, grab that range of tiles from initial storage (in my case a list with 16,000 gameobjects) with whatever specs you'd like (smallest) and have them each change tiletype (grass tile) based on that information.
It seems like that would lead to the intended behavior, but I may need to rewrite my initial design. Nevertheless, this seems to be a great way to deal with the problem presented so thank you. If you have any other tips I'd love to hear them, since this is pretty new to me.
Happy to help. Yeah you got it right. Small tip try to use a single mesh ins$$anonymous$$d of 16k gameObjects would be better for perforance reasons but a bit harder to implement, there are several tutorials for tile map texture generators look around.
