- Home /
How to structure the code for your AI enemy system?
Hello,
I have been trying to figure out how to approach in creating an entire AI system for my game from the pathfinding, to combat, to thinking when to 'this' over 'that', when to run/hide/take cover. Somewhere along the lines.
I am curious as to how one would structure all these lines of code. I have a naive and simple idea on how to get the desired AI instructions to work, but should all of this be separate scripts to control the enemy, like AI_Path, AI_Combat, AI_Brain, etc or have them all in a huge script, which I think is unwise and just gets messy.
Another concern is I have read that FSM are quite helpful in the creation of AI, sometimes constricting, but for simple purposes they are useful. Is this simply achieved with naive switch statements or is there a more efficient way in handling all of the actions I would want to happen for the AI to take action.
If anyone could point me in the right direction for AI structuring or organization, of just overall tips to include when developing a system for the AI to obey.
One other side question, is Unity's Navmesh "good" enough to use for complex pathfinding or is it worth building a pathfinding system from scratch, being the only way I would know how to do is using raycast to help move the character along. As for complex, that I am not sure of. For the most part the terrain will be wholesome, meaning no gaps.
Any info would be helpful.
Thanks in advance.
Answer by CodeAssembler · Aug 19, 2013 at 05:07 AM
I have tried this one and I found it somehow easy to implement following their video instructions:
http://arongranberg.com/astar/download#
As for the rest I guess its really more of personal taste than anything else. Unity is build modular and every GameOject its supposed to know 'how to live' on the game world and how to react to its environment. That's the philosophy I try to stick with myself. I don't really care that much about how the code is gonna end up looking or organized. I just follow this concept of Unity and I usually (most of the time) I end up happy with the results.
I will say, what I tend to watch is if the script is way bit and has to has references to a lot of gameobjects at the scene 'probably' I'm not doing things the best way and get away from the code and think about things the 'Unity way' to see if I can find a better approach. Buts this is really all about personal point of views more than anything else I guess...
Ah yes I have heard of that plugin before, just was never really sure about it, but I will give it a try. I do try my own way, but sometimes it has its good and bad. With each approach comes a good advantage structurally and logic syncing together.