(Solved) Could I get some guidance on enemy AI?

stratoavis

  • Posts: 14
Hello everyone!

I currently have a project I'm working on and I was wondering if I could get some suggestions as to how to approach this so I'll try to keep this brief and to the point :)

Basically, I'm trying to create an enemy AI similar to the Worker AI in the game Sinistar. Essentially, a Worker has three goals in life: follow the player and wait til there is a crystal to steal, hang around the other enemy type (Warrior) for a free crystal, and look around for any floating or free crystals. Once the Worker has a crystal(s), its main priority is to return them back to the boss to "build" it offscreen. So it hunts for crystals and returns them to a point of origin and gets a task reassigned.

So to my understanding, its just a matter of assigning a task upon creation and then switch to its prime directive once it has accomplished that goal and back again randomly. However, as far as structuring it I could use some suggestions or ideas. I have some in mind but if I could get some suggestions I would greatly appreciate it. :)




« Last Edit: May 31, 2013, 08:11:43 pm by stratoavis »

Tuo

  • *
  • Posts: 2469
You are going to need a lot of "if" and "otherwise if" conditions with either some custom events or a block of code that will be well over a page long.
Don't look to me but rather to the One who is the reason for what I do. :)

If you need help, send me a PM. Even if I haven't been on in the forums in ages, I still receive those messages via email notifications. You can also reply to any of my forum posts, regardless of the age (especially if I created it), and I will likely reply.

If you want to see the programming behind certain types of games, feel free to check out my "Demo-" games on StencylForge (http://community.stencyl.com/index.php/topic,16160.0.html)

stratoavis

  • Posts: 14
Yeah I figured as much when I was trying to think about how to approach it since it would require ALOT of conditionals and the like. Unlike in the game where it can reassign it on the fly, I was thinking about just simply having each member assigned to its task and when completed reassign it randomly.

I knew it was not going to be easy by any means but thought I'd get some ideas at least on an approach. Nothing a few RNG's and trigger calls can't create!  :D By the way Tuo thanks for all the Demo's you've done on the forge! :) Amazing stuff and I learned a lot from them so thank you!

twotimingpete

  • *
  • Posts: 1667
enemy/npc behavior is definitely a huge challenge. I think of it in modes, determine what the unit will be doing in each mode and how to make it do it (patrol, chase, attack, whatever) and then figure out how to control those modes, how they connect together, how they are triggered, etc. It's like a chain of logic and you have to connect it into a circle so an outcome is planned for every possible thing that could happen.

doing any complicated AI will be a highly iterative, layered process, where you just have to start at the beginning and build outward, layer by layer, until it works. once the whole thing works right it's really satisfying though.

as far as structuring the code, tons of booleans, and custom events. so if this happens, trigger this, then that custom event you triggered starts another chain of logic.

Photon

  • Posts: 2691
One recommendation I can make is compartmentalizing those three tasks, perhaps into different behaviors or function calls. Then a "main control" behavior can look at what going on around it, decide which task to do, and do something like disable/enable the proper behaviors. One of the benefits of this as well is that it can keep code organized and easier to handle/troubleshoot.
Do NOT PM me your questions, because I likely will not respond. If I have replied to your question on the forum, keep using that topic. Thanks!

twotimingpete

  • *
  • Posts: 1667
One recommendation I can make is compartmentalizing those three tasks, perhaps into different behaviors or function calls. Then a "main control" behavior can look at what going on around it, decide which task to do, and do something like disable/enable the proper behaviors. One of the benefits of this as well is that it can keep code organized and easier to handle/troubleshoot.

Seperate behaviors for different activities may be a nice way to organize things, I remember a while ago, though, having difficulty when attempting to make behaviors activate/deactivate on the fly. I even forget what specifically the trouble is. Do you do this?

Photon

  • Posts: 2691
I have done some activation/deactivation before, but not like this. I can't say its caused me too many problems before though. The bottom line is he should try to some extent to keep different tasks and functionalities separated in some way so he can manage it both from a code processing perspective and organizational perspective.
Do NOT PM me your questions, because I likely will not respond. If I have replied to your question on the forum, keep using that topic. Thanks!

stratoavis

  • Posts: 14
I haven't really thought too much about the active/non-active behavior method there so that is something I could look into. Otherwise, what I was thinking was creating custom events as "states" for each process in a behavior. So each event could be called Search, Gather, Attack, Return to Target, etc... And definitely keeping everything together to make it cohesive is important to prevent hiccups and making my brain itch more than it has to  :P

For the X/Y of the asteroids, I was thinking that upon creation, store its X/Y in a 2D list (which I still haven't figured out effectively :/) or array that the workers can access based on the index. For simplicity, once an asteroid is created it's staying put :P

For the Search, randomly choose one of the indices in that list/array that has the coordinates and have it move/collide with it to spawn a marker upon destruction of the asteroid.

For the Gather, if a marker is within range (to prevent a massive swarm closing in on one marker) get the X/Y of the marker and collide with it. Hardest part of this is I'm not sure about getting the newly spawned marker's X/Y. Same with the "within range" aspect...maybe a large dummy sprite?

And the Return to Target, once it has a marker on hand, return to a specified actor or target and upon collision with it, reassign its task (rather than once marker inventory is 0, reassign).

This is simplified of course but this is how I see it...or at least one way I suppose since the same could apply to the behavior method as well using a "brain" behavior like Photon said.

Thanks guys for taking the time to give your opinions and ideas on this. I greatly appreciate it :) twotimingpete is right with AI, definitely a challenging process but highly rewarding when it comes together, and even though its just three tasks it still takes a lot for it to work!

stratoavis

  • Posts: 14
Ok, I believe I found a good way to sort and structure my logic. I've already started prototyping some aspects of it and its coming slowly but those questions will be in other posts :P For now, what I've done is a goal oriented approach (looked it up in one of my AI books) that I outlined in notepad for the three main goals of the enemy with subgoals that can be added in.

I'll have more questions later on but for now I have a good idea where to start. Thanks again guys!