In this example there is a controller component which will determine what state to be in and then run the state.
Regarding Unity performance, would it be better to have these as seperate scripts (i.e. attack.js, idle.js etc.) that reference each other or all of it contained in one large script?
I’d like to have varied bot types and levels, so the seperate component setup seems more efficient in the long run, but is there anything more experienced coders are aware of that would lead to problems and/or performance issues with this approach?
I saw a series of articles on codeproject.com about a state machine toolkit written in C#. It seems pretty flexible. That way you would spend most time implementing the states and transitions of the ai instead of creating yet another state machine.
… and btw. I recommend using separate classes and files for your behaviours, as that would make your code much more readable than throwing all in one bin. One should always aim for maintainable code first and think of optimisations later.
Separate files definitly seemed the way to go for practical use reuse, i just wasn’t sure if there was anything Unity specific that might be a performance issue or something.
The link you posted is very interesting, although i am a novice in javascript know nothing regarding C#, i think i can still understand in basic what is going on by looking over the code, hopefully that will help out.
It seems any info on AI in general is lacking from the unity documentation/wiki/forums. Not neccessarily what FSM or A* actually do (or anything else that can be found easily elsewhere), but how best to implement them in unity. The car tutorial is a start, and its what i’ve been working off of to learn, but it is a very limited example. Especially since online networking is not an automatic option in Unity yet, AI is incredibly important for anything other than rolling ball / mainipulate object type games.
I doubt there will ever be any AI documentation in Unity aside from demos other users make, simply because AI is very game-specific. With Unity you have the full scripting languages to implement almost any (in not any) AI code you want. It is basically a matter of changing the code to C# or JS and interfacing it with your Unity game. Just about any samples you find will work in Unity with a little modification.
I wrote an FSM in Unity, and I agree with freyr about using multiple files. I found some code for a C# version of the AIDepot method, and screwed around with it to make it work in Unity. This way I can have a states script that just holds states and state transitions. While a couple other scripts handle the logic and state management. It works really well.
I have no clue how OOP and classes work in JS, but I really like C# for this kind of thing.
true, but it still seems to me like its such a fundamental component of game production that even if there isn’t a built in unity state machine or pathfinding solution, there should be at least some mention of how best to interface one with unity.
anyway, i’m off to continue reading. thank you both for the answer regarding multiple files ; )
I disagree. The code you use will still depend on what you are doing, and there is no work involved interfacing a state machine into unity. The state machine is pure code and technically has nothing to do with Unity. There is nothing to inteface with Unity to make and use a state machine. What you do inside the state machine is what is interfacing to unity, and that is 100% game specific.
