Hellow, i’m new to scripting an AI. I chose javascript for the language because i’ve already some experience with it.
How do i start with it?
i’m planning to script an enemy AI.
greetz
Lordfoemp2
The only hard part is pathfinding. If you have only little experience with programming AI, I would start with creating a simple project in which you spawn a cube from code that the player can control. Next, you spawn another cube that follows the player around. That should take care of 4 and 5.
Once you have that set up, you can let the enemy attack once he gets in a certain range, which you can determine with Vector3.Distance.
I’m making an AI for my thesis to get my degree in IT. This AI is going to be used in a game that i’m making with a couple of friends.
I already managed to let my enemy follow me through the map. (also through the walls :s)
But when he gets at a certain distance he starts to bug around my FPcontroller.
=> how can i control that bug?
You will need to be more specific and paste some code.
I understand what Fluzing is getting at. But, although pathfinding can be a little complicated when you’re new to AI, it’s largely a solved and standardized problem: use A* or waypoints with some basic steering behavior. The only thing that varies game-to-game is world-specific information (How do I recognize obstacles? Do I use stairs? Are there any doors or elevators? etc.)
Make sure you’ve set up your Physics collision layers correctly so that NPCs can’t pass through walls. Then, if the AI can’t find a good path, it will stop at the wall instead of passing through.
Waypoints are a very easy way to implement pathfinding, since you can specify at design-time how to move between areas of the map. The AI computation is much simpler than A* and often more reliable than writing your own A* from scratch if don’t have a lot of time to fine-tune it. (Technically they’re both graph analysis problems, but basic waypoints use simpler algorithms and data structures.)
If pathfinding determines where to go, steering controls how the NPC gets there. It handles acceleration and deceleration, smooths out the path, and avoids dynamic obstacles. You can use the same steering behavior to maintain a minimum distance from your FPcontroller, which should control the bug you described.
Google “steering behavior” and either “waypoints” or “A* pathfinding”.
The topics of perception and decision-making are much more at the forefront of modern AI. (What targets are here? Which one should I attack? What kind of attack should I use?) There are many approaches, but the old standby for decision-making is the finite state machine (FSM). Unity Gems has a tutorial here: http://unitygems.com/fsm1/
For perception, you can leverage the Physics engine. If you have CPU to spare, just call Physics.OverlapSphere() every Update() and see what’s in range. A more efficient option (perhaps as an enhancement once you get it working with OverlapSphere) would be to add a trigger collider to the NPC. Then use OnTriggerEnter and OnTriggerExit to record whenever something enters or exits the NPC’s perception range.
If you make everything modular, then you can swap out waypoints for A* pathfinding, or behavior trees for FSMs, without affecting anything else. Many people who are starting out couple their AI algorithms too tightly to the game they’re writing. Then, when they determine they need to use a different steering behavior, for example, they can’t do it without breaking everything. My #1 tip is to google “loose coupling”. In the big picture, this will probably save you more time than anything else, which will leave you more time to write an interesting AI! 
Physics.OverlapSphere()
Didn’t even know that existed. I just instantiated a prefab with a collider attached to it if I need to see what was in range.
In the code below my enemy can follow me. But every time it starts following me it is getting altitude …
Yes i defined colour so i can see what my enemy is going to do.
var distance;
var target : Transform;
var lookAtDistance = 15.0;
var attackRangeFar = 8.0;
var attackRangeClose = 2.0;
var moveSpeed = 3.0;
var damping = 6.0;
private var isItAttacking = false;
function Update ()
{
distance = Vector3.Distance(target.position, transform.position);
if(distance > lookAtDistance) // distance > 15.0 = just stand dont react
{
renderer.material.color = Color.green;
}
if(distance < lookAtDistance) // distance < 15.0 = just watch and follow at a distance
{
isItAttacking = false;
renderer.material.color = Color.yellow;
lookAt();
}
if(distance < attackRangeFar distance > attackRangeClose)
{
moveAttack();
}
if(isItAttacking)
{
renderer.material.color = Color.red;
}
}
/* Functions */
function lookAt()
{
var rotation = Quaternion.LookRotation(target.position - transform.position);
transform.rotation = Quaternion.Slerp(transform.rotation, rotation, Time.deltaTime * damping);
}
function moveAttack()
{
isItAttacking = true;
renderer.material.color = Color.red;
transform.Translate(Vector3.forward * moveSpeed * Time.deltaTime);
}
function attack()
{
renderer.material.color = Color.blue;
}
(Side note: If you wrap your code excerpts in “[ code ]” and “[ /code ]” tags (without the blank spaces), the forum will format them properly.)
Is lookAt() rotating it on the Y axis (i.e., pointing it slightly up)?
If a physics component is attached to the enemy, is it “stepping up” onto an unseen collider? It could even be another collider in the enemy’s hierarchy.
Decide on your avatar system before writing the AI. By that, I mean the model, animation, and physics. For example, you might choose to use Mecanim humanoids with CharacterControllers. Or a Legacy animation character with rigidbodies. Or a floating particle system with a trigger collider. This decision fundamentally affects how you write the AI’s “motor” – that is, how you control it, how it moves within the world, and how it interacts with other objects.
Getting back to loose coupling, implement the motor as a separate module from the higher level AI. This way, if you change your avatar system, you only need to update the motor module. The higher level AI module(s) won’t be affected. Right now, everything is intertwined.
If you’re really interessted in learning AI for games I suggest to look also a little behind the scenes and learn also the theory of it. A really good book about it is Programming Game AI by Example from Mat Buckland. Its one of the best books for beginners I read. Its some years old but most of it is still up to date. Maybe its a problem that the source code is in C++. But otherwise I can only advertise it. Also for looking up.