I am making a 2d top-down game.
Suppose some of my entities have sprites that have 4 directions (and are animated), and some of my sprites have an additional 4 animations depending on whether there are more of the same entity type adjacent to them (so 8 in total).
What would be a good way to handle this?
Currently, I use a struct for the animation indices of 4 directions and change them based on the rotation state.
#Animating sprites depending on direction and neighbours
thick bear
But this does not handle the conditional animations based on neighbours.
Something similar to this is the desired result:
gentle token
I don't know if there actually is anything on this, but since you give Factorio picture, you should check out the Factorio dev blog, there is often some pretty helpful stuff around there.
How are you handling the grid? Is it some kind of array structure or you are just having grid aligned components? If just grid-aligned components, maybe you could store some info on the types of neighboring tiles and use that to choose the right sprite.
thick bear
All my belt sprites have a Position {x: i32, y: i32} component. To rotate I get the mouse position on click then convert to a position and then check every entity to see whether it is in that position and then rotate if it is. Obviously this will be slow for large amounts of entities but I am planning on also adding a Chunk component to prune most of the searching.
Is this reasonable?
The Factorio blog has lots about optimisations but I'll leave that for much later.
I was mainly wondering if there were any code patterns know for this sort of thing.
gentle token
Probably? I don't think you can really do much better without sorting the tiles first (by chunk or however else). And honestly just searching the query for neighbors for each tile is probably fine for you already if you're early on in the project. It's straightforward and you can optimize later if you need more performance.
Ha, so my only answer is "probably fine". Maybe there's better ways but I would just go with what's easiest until you think that you're missing something.
thick bear
Ok, thanks. My current plan is to have a BeltRotateEvent when a belt is clicked on, a do_rotates system that rotates for each BeltRotateEvent, a BeltModifiedEvent, and a check_neighbours system that listens for modifications ad then rechecks the neighbours of the modified belt to see if any of them need to be corners and update the sprites accordingly.