[=;184313]
Ok, that seems promising. Did you check fps, or did it just feel slower at higher altitudes?
[/]
Just overall response of starting movement and also my line trace which currently hides my colored volumes seemed to react slower. I didn’t check FPS. I probably need to delve into the performance monitoring tools, but I haven’t really had the need to yet. When things are slow or choppy I already know why so I haven’t had much need.
[=;184313]
Hmm, ok. I’m having a hard time seeing how I would implement this in my blueprint. Perhaps it is because we do things differently. Everything in my blueprint is based on arrays. Could you quickly try to describe the three steps of math you mention? Do you get the numbers from the actual coordinates of the tile meshes?
[/]
I pretty much use all arrays as well, but I do a lot of work using the index for the current and surrounding tiles.
The math in my case revolved around checking what offset I am on. Right now, I take current index and get the offset from an array. That is one area where I could instead take current index, and based on it’s value figure out which offset I am on with 3 steps of math, and he was saying it would be faster. Probably right if Get with Index plows through the whole array, but he might still have a point as well even if it doesn’t just for memory issues. But it might be moot either way. It is something I will test out when I have time or when I am doing a big optimization push.
[=;184313]
Yeah, spreading the loops out between ticks is certainly possible, and I’ve done it my blueprint. I don’t feel the need at the moment, but when I start creating AI that will have to consider multiple paths before deciding, it might become necessary. Worst case I’ll have them have a question mark above their heads while they decide, like in the old Worms games. I doubt it will run that slow, though.
[/]
Yeah I think it depends on how many actors need to decide paths at one time, and what kind of time frame they have to decide in. I think ideally, you want the AI to do as much work as possible simultaneously while the player is deciding their moves. Any work left to be done when the player hits end turn will just have to be performed then.
I have been pondering ways to handle turn based movement and turn sequencing to take into account pathfinding times among other things. If you have ever played a Civ game you know how pathfinding really bogs even the best computers down in the endgame, especially on larger maps. A large part of this is all the workers roaming around, which is one reason why the tile improvement system won’t be based on units. But generally I think a lot of the calculation is performed at the end of the turn anyway which sets you up for a wait.
One way to improve end of turn time would be to handle movement so that it all happens at the end of the turn. That way the the pathfinding could bake while the player makes their moves, and any player movement wouldn’t necessarily spoil pathfinding work that has already been performed. Then, when end of turn happens and the movement phase commences the pre-calculated pathfinding starts moving pieces including the player units. This would have units moving into a tile simultaneously, starting battles. Players would have to be a little more careful when racing off into the darkness. Comes with the trade off of players losing a bit of control and predictability though, so that has to be gauged.
There are probably other problems that aren’t immediately apparent as well. Pathfinding and turn sequence go hand in hand and the rest of the game depends on it, so I will be spending a lot of time working those details out before moving on to other systems.