Persistence now works for the AI system.

It is now possible for the AI to dynamically generate a navgraph and resume autonomous actions when the player restarts the game.

The only remaining task is to make sure that the AI navgraph works over the network, but this shouldn’t be an issue, since the AI’s position updates will be sent in the same way whether the AI is following the player or acting autonomously.

The post P0-B5: Part 1265: Debugging, Improvements first appeared on Phoenix Game Development.

I have added some more actions to the AI system, as well as more testing and integration with the existing AI system.

I have also improved the AI logic so that the AI will not interact with objects that the player is already interacting with, etc.

There were also a few bugs with the pathfinding and navigation that I fixed as well.

I have also added a distance check to disable the dynamic graphs when the player gets far enough away. At this distance, the AI won’t be visible, and so it doesn’t need to move.

The next goal is to add persistence to the system, and test it over the network, and then do some final debugging.

The post P0-B5: Part 1264: Debugging, Improvements first appeared on Phoenix Game Development.

The new AI navigation code works well.

The actual graph generation was working fine, the problem was that the AI could not follow it properly using the localspace graph (I am using the A* pathfinding project).

I have now replaced some of the existing navigation code with some of my own code, and this allows the AI to follow the existing graph.

I have tested this reasonably well, and integrated it into my current system, and so far it works fine. I have also added some simple random actions that the AI can perform in the world, using the new graph system.

I now need to add the ability for these dynamic AI graphs to be created and destroyed correctly upon prompting by the player, as well as possibly add persistence, so that the AI can generate its own graphs when the game loads.

The post P0-B5: Part 1263: Debugging, Improvements first appeared on Phoenix Game Development.

I have managed to mostly solve the AI issue.

I was not able to create a generalised solution, but I was able to come up with a concept that allows the AI to properly follow navgraphs while exploring the world, which is the main goal that I wanted to achieve.

I was hoping that I could also use this solution to improve the existing navmesh generation for cities, etc, but this was not possible.

However the results that I achieve seem reliable, and work well. I still have quite a bit of testing to go though.

The post P0-B5: Part 1262: Debugging, Improvements first appeared on Phoenix Game Development.

I am still having major issues with the graph rotation.

I can’t seem to find a solution. The only option that I have that might work is to duplicate the collision geometry, rotate it, then generate the graph, but this is extremely messy, and would likely not work properly.

I will spend a few more days on this, that’s all. I may need to postpone it and look at it again in the future.

The post P0-B5: Part 1261: Debugging, Improvements first appeared on Phoenix Game Development.

I have added the support functions that add the AI to the dynamic nav graph, but there is an issue with rotation.

The AI does not seem to be able to properly navigate on a graph that is rotated.

With cities and other static objects, I was rotating the object to the origin first, then generating the graph, and then rotating it back.

However, with terrain, I can’t do this, because the terrain isn’t a single object that loads out of view of the player.

I may not be able to solve this at this point.

The post P0-B5: Part 1260: Debugging, Improvements first appeared on Phoenix Game Development.

I have fixed a complex bug with the multiplayer avatars where, in some cases, a duplicate avatar was appearing in the world.

I have also created a concept for the dynamic navmesh.

Creating an asychronous navmesh in the world, which is rotated to an arbitrary y-up, is not difficult, I have done this before in other parts of the project.

The graph is being generated correctly, and with some tweaking, I was able to produce a navigation graph that should work great for the AI, and generates quickly.

The main problem will be with adding the AI to the graph, and making them walk on a graph that is effectively rotated to a non-y-up angle.

The post P0-B5: Part 1259: Debugging, Improvements first appeared on Phoenix Game Development.

I have made some small improvements to the project, but the main goal for this week was to create a dynamic navigation system for AI characters.

Currently, NPC’s use navmeshes when they are created in static locations (Such as cities, etc), but they use much simpler navigation code when they moving through the world.

I want to add the ability for the AI to generate a navmesh dynamically in the world too. This would not be used for pathfinding over long distances, since this wouldn’t be practical, but it would be used for situations where an player and an AI companion was exploring a location, or engaging in combat.

In this situation, the AI could generate a small navgrid graph and use this graph for transitioning through this particular complex area, and then transition back to the much simpler navigation system when the player and the AI move on to other areas.

This will be quite a complex feature to add though, because the graph will need to support an arbitrary up axis, as well as asynchronous generation, etc.

The post P0-B5: Part 1258: Debugging, Improvements first appeared on Phoenix Game Development.

I have added support for rotation to the grass exclusions system.

This is a feature that I really wanted to add the last time I worked on this, but I didn’t have time.

The rotation math required for this feature to work was quite complex, but it is now possible to rotate the grass exclusion volume to match the local space rotation of the object.

This allows for not only circular and square exclusion volumes, but rectangular ones as well, which is required for objects that are substantially longer in one axis than another.

This is quite an important step forward.

The post P0-B5: Part 1257: Debugging, Improvements first appeared on Phoenix Game Development.

I have been working on improving persistence in the project. The damage to the players ship is now stored per-session, instead of being reset when the game ends.

I have also added a paging system for persistent objects on the server.

Most of the groundwork for this was already done, but it wasn’t fully implemented.

All persistent objects are now paged in and out based on their zone, and their distance to the user, this is a standard feature that is required now that the number of persistent objects is increasing.

I intend to continue working on debugging and testing for a few weeks, before moving on to other areasof the project.

The post P0-B5: Part 1256: Debugging, Improvements first appeared on Phoenix Game Development.