When I started to work on Dragontorc's remake, I wanted to do just a remake. Make it small and quickly. After first milestone I was driven off by animation system but then I realised, that I can do something great in that field in my current work, so why not go back to work on Dragontorc? And why not to make it bigger? To allow people modifying, adding new content.
That's why during MS2 I decided to extend events and items. And while I had plan for whole game created and didn't want to change it (because it doesn't affect anything but me), I decided to extend other things. And to make systems that I could use for other kind of games. It might be even possible to adapt system for space simulator (it will require implementing different movement, etc. although it is possible to keep whole AI code the same! Although spaceships may behave inappropriate as instead of being on enemy's six, they would be circling around, getting closer to fire and move back, but for TTP action game it will be just fine). This is also reason why I wanted to keep things modular. In future it might be possible just to change renderer, animations and interface and turn Dragontorc into 3D FPP, TTP or isometric adventure game.
So here is the background and reason behind my choice to spend so much time working on AI. And now the details, what's inside and why.
As I already mentioned, AI is behaviour based system with messages. What does it mean?
AIs mind currently is tree composed of behaviours - every leaf is a behaviour. Whole thing is set up in such way, that any leaf can be replaced, so it is really easy to reuse behaviours for different characters.
Main node might be a behaviour that decides what AI wants to do. Currently all AI characters choose between three actions:
That's why during MS2 I decided to extend events and items. And while I had plan for whole game created and didn't want to change it (because it doesn't affect anything but me), I decided to extend other things. And to make systems that I could use for other kind of games. It might be even possible to adapt system for space simulator (it will require implementing different movement, etc. although it is possible to keep whole AI code the same! Although spaceships may behave inappropriate as instead of being on enemy's six, they would be circling around, getting closer to fire and move back, but for TTP action game it will be just fine). This is also reason why I wanted to keep things modular. In future it might be possible just to change renderer, animations and interface and turn Dragontorc into 3D FPP, TTP or isometric adventure game.
So here is the background and reason behind my choice to spend so much time working on AI. And now the details, what's inside and why.
As I already mentioned, AI is behaviour based system with messages. What does it mean?
AIs mind currently is tree composed of behaviours - every leaf is a behaviour. Whole thing is set up in such way, that any leaf can be replaced, so it is really easy to reuse behaviours for different characters.
Main node might be a behaviour that decides what AI wants to do. Currently all AI characters choose between three actions:
- Attack enemy (if there is enemy in current room)
- Go to door (enemy could leave room and we go after it)
- Idle (just wait patiently)
Main behaviour switches between children behaviours. If it notices an enemy, it chooses attack behaviour to be current one. It ends all other behaviours by doing so, but remains active (to notice if anything else happens).
And all children behaviours can be separate trees. For example Attack behaviour could have two children:
- Attack enemy
- Observe enemy
It may look at current situation or communicate with it's allies to decide wheter it should attack now or just observe and give way to anyone who would like to attack.
All behaviours may run in parallel. There can be even two (or more) instances of behaviour on same leaf node (although I would strongly advice against doing so).
Such behaviour system is quite modular and separating how creatures moves and attack from it, makes it even easier to have classes of characters. It might be even two basic ones: melee, ranged. Or it can have more variants - melee aggressive, defensive, cooperating, ranged that just shoots from time to time or tries to get to best location and shoot from there. But actual creatures may look very different, move different and have different attacks.
How? Well, behaviours just use references of different objects and those references are translated into proper objects using creatures look-up/translator/dictionary/library. At the moment wisp moves in zig-zags and appears to be floating, velocity changes over time, while skeleton seems to stand strongly on ground, velocity changes quicker. There might be an orc that moves slower than skeleton, has more powerful attack, but may decide on actions to make in the same way as skeleton (although it is tempting to make it possible for orc to disrupt skeletons' attacks with loud roar and charge into enemy instead of behaving just like skeleton, but with such system, it is easy).
What are other things that I gained by implementing such system? I don't need to recompile whole thing. I plan to make it possible to reload things while game is running to make it even quicker and easier to test. And of course people may alter behaviours and add new ones quite easily.
What are the problems? It is slower than AI driven purely by code and it took some time to create it.
I've seen quite few implementations of AI in my life and when I compare mine approach to others I have to say that while it isn't the most robust, it is probably the easiest to extend and few other approaches may be implemented with it (if not with behaviours, then with just AI BASIC code that is inside of them). One thing that is not possible for sure is stack of behaviours. I could do it and it could run in parallel and maybe, if I will have a need for that, I will do so, but from my experience, I know that this may end up with AI that constantly changes its mind or AI code is just huge mess of conditions, checks, etc. It is much easier to have separate layers representing different needs and switching between their children believing that each one of them will do their own role properly.
No comments:
Post a Comment