Ok, time to finally show a couple of the more visible changes I’ve made: Variable terrain cost and spline smoothed movement. Here is a quick vid:
https://.com/watch?v=KY6IBNQX6rY
The tiles in this video have twice the movement cost of regular tiles, which in this case makes moving around them a more efficient path. This video doesn’t demonstrate it too well, as the same path would in this case be generated even if the brown tiles had a much higher cost. Costs can be freely changed to be as high as one desires, and can even be made lower than regular tiles. As mentioned I’ve also made movement a lot smoother, by having the pawn follow a spline through the path. I’ve also added the option of displaying the path spline as an alternative to arrows or highlighted tiles for showing the path, though this isn’t shown in the video. Under the hood, I’ve made numerous improvements, and the system is now more efficient than ever before.
[=;184563]
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.
[/]
I’ve checked the fps of my own project now. A 100100 grid was much more than 120 fps. 200200 dropped it to around 90, and 400*400 to around 60. But I just realized that I am spawning a separate tile volume actor for each tile instance, which I can probably find a way around, and which will probably make things a lot quicker. Showing fps is as simple as clicking the downward facing arrow in the top left of the viewport and selecting “show FPS” by the way.
[=;184563]
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.
[/]
Ok. I don’t use any offsets at the moment, so I don’t have your exact problem. I did notice some slowdowns when using huge grids which might be explained by what your friend is suggesting. Starting the Dijkstra and a* algorithm froze the game for a noticeable amount of time when playing on a 400*400 grid, even though the path finding array shouldn’t really be any bigger. There might be several explanations for this, though, and I’ll try to figure it out.
[=;184563]
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.
[/]
That’s a really good solution, actually. If I ever experience any problems with slowdown when creating AI, I’ll definitely try something like this.