Quote: "Im just planning for 2D side scrolling. my stages is almost done. i have no any idea in the codes for AI. can you give me some example pls?"
It's difficult to do so, as without having your code and understanding your specific design, we have no idea how the World/[level] of your game is designed. What I gather from reading some of your other posts outside this thread...
Your level is
not broken down into tiles, but rather it "seems" you are scrolling large bitmaps that represent the level. While feasable, it's outside the norm of how the genre of game you described is generally done. As I stated, it's normally a tile-based system which helps to define the "broad location" of your player in the level, as well as the "local location" within the level. Collisions in general, beit with platforms, enemies etc... are also usually built into the tile data/tile world system. Then perhaps bitmaps scrolling in the background and possibly foreground are used to a accomplish a parralax scrolling engine effect.
Defining Enemy States [Finite State Machine], VERY GENERAL!!!
But getting back to your question in general. Regardless of how exactly you implemented all the details. You need to setup what is referred to as a
"Finite State Machine" (for all characters enemies & the player, or any other behavioral object within the game). All that means is that your enemies/player have a determined number of states. for example, a stationary state, a patrolling state, an attacking state, a dieing state etc... these behavioral states would be a defined as a constant integer that coincide with an enemy(x).state in your enemies udt. eg.
rem possible enemy states
#Constant STATIONARY = 1
#Constant PATROLLING = 2
#Constant CHASING = 3
#Constant EVADING = 4
#Constant ATTACK1 = 5
#Constant ATTACK2 = 6
#Constant DIEING = 7
Obviously,, in a mario-esque game,, most generic enemies don't really have that many "broad" states. Basically most have just a SPAWNING, PATROLLING, ATTACK (which could just be a jump when near player, & DIEING state; but they may have even more "acute" states, ie. isjumping, isfalling, isdieing etc....
Now you would have to code how to handle the states. This can vary greatly depending on how you want the AI to behave. A generic patrolling enemy in a mario-esques type game would just have the enemy move left. If it hits an collides with the world (example a pipe) it turnsaround and moves right. Some enemies may jump if near player. You have to decide what patterns behaviors each enemy type exhibits. Some enemies may stay in place (Stationary) until player is near, and then they go into an single or multiple attacking pattern (jump, throw-hammer, move away, move closer, <if player is on otherside turn around<, repeat.
Where is the player, where is the enemy, where in the world
The other things you need to consider is how your world is defined. For example, you need some way to have a global level coordinate system, and a local level coordinate system. In a tiled world, this is physically built into how the world is setup. If you are not using a tile system you need someway of determiningg where the player is in association with the level. You need a way to determine where enemies will be positioned (spawn from) with regard to the level. You need to know how much of the level is currently being displayed and which area of the level is near being displayed. The reason for this, is so you don't need to run through checks, draw, perform AI and collision for every Alive enemy on the entire level every loop. There is no point for instance in animating an enemy that is at the end of level, when the player is starting the level. You need a method to spawn enemies at will, dependent on where the player is in the broad level. Then you would perform AI on these nearby enemies. You also need a way to KILL off enemies, either by action of the player or just the fact that they are not relatively near the player at the current time.
In conclusion
I hope that what I am trying to convey comes through. For all the things and more that need to be handled for enemy AI... that is the reason behind drawing your world from tiles and having a grid system. Tiled worlds are not just about saving on the need for large graphical images, but rather it's a structure that inherrently describes the world, breaks it down into locations, and allows the programer to easily decide where the player is at any given moment, and where to place enemies, what the player is colliding with etc....
If you are using large bitmaps that are scrolling instead, that is fine. But you still need to incorparate a grid like system, even if only in the logical sense, to determine these things.
******
Scripting
As if the above wasn't a vast enough topic for discussion, the fact of how to code the A.I dwarfs that in comparison. While it's feasable to code all of these behavicrs directly via select-case statements and functions, and running through these case statements for x number of enemies. It gets messy and difficult to handle it all even for what may be considered simple AI. For this reason, you will find that coding the AI states/behaviours is generally handled using a scripting language. Implementing this alone would be a large turorial or book all in itself. But I just wanted to make you aware that hard-coding the AI directly into the game code itself is just as daunting of a task, but for the most simplistic Finite State Machine. Eventually you may want to begin researching scripting.
Your signature has been erased by a mod please reduce it to 600 x 120.
