making ai is no different from making making regular code just apply the same concepts but in reverse

In general, game AI needs to have an understanding of geometry, both for "can I see this" detection queries, and "can I move there" physical queries.

A lot of this understanding of geometry is usually created in advance, using some kind of pre-process (such as generating a navigation mesh, or "navmesh" for short). Other things can be solved by re-using your physics system; for example, if you want to detect something that's up to 4 units ahead of you, you cast a ray that's 4 units long, forward from the entity, each frame.

what are meshs?

i have heard of them on topics about 3D but i don't code 3D stuff yet, i perfer 2D games

i have made very retarded enemy AI that would do fine in a 360 degree topdown shooter as long as the eneies don't get too close before dying

also sorry i disappeared after getting my answers, i was busy and forgot

Quote: Coding my own A* algorithm was probably the most fun I've ever had with programming

Yea lol A* is funny, especially when its not coded properly, i made a simple version in VB usin my own tile system and the GDI, in the end i gave up because arnold schwarzenegger kept walkin in circles. I found out it was a wrong variable name :s How embarrasing lol

Quote: Original post by Link1426
what are meshs?

i have heard of them on topics about 3D but i don't code 3D stuff yet, i perfer 2D games

i have made very retarded enemy AI that would do fine in a 360 degree topdown shooter as long as the eneies don't get too close before dying

also sorry i disappeared after getting my answers, i was busy and forgot

Like most questions in life, the answer to this one can be found in wikipedia:
(last year it was google)

http://en.wikipedia.org/wiki/Polygon_mesh

At its simplest, a mesh is a graph which nodes are labeled with spatial information.

thanks for that bit of info

i am going with a structured grid since my game is a tile based topdown game and i don't know anything about mesalso i can use the grid to make collision detection along with AI

You might also want to look into LOS (line of sight) techniques to see if there might be ways less CPU intensive than the ones you are already using.

To make the NPCs less 'stupid' you will want them to attempt to acquire a new target as they are moving back to their 'home' location or back to the nearest patrol path point. That means it would constantly be doing its sensor sweeps.
(likewise a 'smart' NPC might look for a 'opportunity' target closer than its current target as it is moving towards it, it maught also be more cautious
if as it moves towards the target is no longer visible -- head to the last seen position or keep distance and search around to try to reacquire it...)

A old technique is called a 'lazy evaluation' where a simpler 'rough' check is done first to do the detection and then a more costly check afterwards that would be more accurate (but wouldn't have to be done on the majority of the potential targets). You can use 'box' checks which in 2D is comparing differences between the hunter and the prey(target) coordinates X Y seperaately. If the target is outside of the max range box it can be discarded. If a target passes that test
then a more accurate sqrt(dx^2+dy^2) range test or more costly line of sight checks (ray casting) can be made to identify a 'seen' target.


loop all possible targets.....

dx = targx - eyex
if (abs(dx) .gt. maxrange) then goto skip_target
// do x first if fails y doesnt matter

dy = targy - eyey
if (abs(dy) .gt. maxrange) then goto skip_target

// do more exact (expensive) tests here.....

Oh, and you might want to look into FSM (finite state machines) which is a methodology of controlling objects 'state' or 'modes' and transitionong between the states. Its one of the fundamentals of behavioral programming.


A mode for patroling or sitting at a home

A mode for moving towards an acquired target

A mode for returning home.

A mode for looking for a target that went out of visibility.

etc...

well i have made a simple way to see if a wall is on a side of a NPC

for each tile i assign a 1, 2, or 3. the data is held in an array

1 = unpassable, 2 = passable, 3 = passable but slower movement

i set a range and then it will see if any tile in the path and to the side of the NPC is unpassable

Quote: Original post by Link1426
well i have made a simple way to see if a wall is on a side of a NPC

for each tile i assign a 1, 2, or 3. the data is held in an array

1 = unpassable, 2 = passable, 3 = passable but slower movement

i set a range and then it will see if any tile in the path and to the side of the NPC is unpassable

Thats just a start. That is an abstract model/representation of your map that the
program will use to navigate. GOOGLE/YAHOO A* (Astar) , 'pathfinding', 'demo'
,source code' to get a demo of how A* works.

Testing adjacent tiles works for a simple system, but if you want to do tests reacting to tiles further away then the simple if-then method is insufficient.