Some general thoughts:
Making generalized "A.I." is not a good idea. That's why "A.I." is done in most cases at the end of game production cycle. At least not before you know some specific things about your game world. You can't solve (compute) problem-situation if you don't know anything about it (no input). With all of your major game word elements known, you can make number of "hacks" - cheating to make enemies look intelligent - it doesn't matter if enemies are intelligent or not, as long as they look smart (that is player doesn't notice cheating) - in games it is all about surface (designers of A.I. for Halo noticed that during playtesting faze making enemies little bit harder -more hit points to kill them - cause playtesters to perceive them as smarter). There is lots of little cosmetic things that you can do to make enemies look more "intelligent" (provide the
player with some visual/auditory clues as to what the agent is ?thinking? about: different animation of enemies when player enter enemies' FOV and some audio information- "Aha!", "There you are" - when it exit - "Where is gone"...)
1) How would you move your enemies - platform movement can be done in many ways in C2( physic, platform, and custom behavior, or even via events). And how would enemy perceive game world (visual and/or audio).
2) Previous determines possible ways of how would you calculate desired trajectories to satisfy the
3) Goal - Search, Follow, Attack, Hide... Don't make enemies react instant on single parameter - if Value A then action A. Make group of conditions for single goal - Attack: is in FOV, is in Fire.Range, is Enemy.Energie greater... than on Goal.Atack: move, shoot...And this requires
4) Logic for switching from one state/goal to another.
oh... i carried away
For basic AI "vision senses" you need distance form player, angle(Player, Enemy),is in angle(Player,Enemy) range, and is line between player and enemy overlapping obstacle
Look at this examples:
Examples A will tell you if is player inside of enemies in line of sight, and example B will tell you how to make "realistic" cone of view. Try to understand them and combine them.
Suggestion: If player is in enemies FOV for short period and then exit it, you can create object LastPosition on that place and make enemy go to LastPosition (otherwise enemy would act as he dont care for Player unles Player is in FOV). You can make some private variables in Enemy - LastPositionX, LastPositionY (when Player leaves FOV set them to Player.X, Player.Y). You can even store Players VelocityX, VelocityY, and Speed at point of exiting enemies FOV and predict possible new position after second or so, and than spawn another object there and tell enemy to go and look is it player there or not. This is all pretty simple but you can get with it decent enemy behavior.
It is not clear to me what you exactly think. Do you think intstances of same type (Sprite) - instances dont react all at same time unless you tell them to do so. If you specify conditions for actions and include "for each", then only instance that satisfy those conditions would be picked and perform those actions.
Or you want to make Global.Enemy type object (one logic for all enemies) and then send to him specifics of each type ("different attack times, die, detect player"). For this you need families and families behaviors implemented. Wait and learn what is there.