Open World FPS AI

[Guest]

TL;DR

This is basically a Psuedo code thread for an AI I'm planning for an idea. THAT'S IT. 

Elaboration:
I'm planning an AI & having trouble getting started so I'm making a little log that people can keep up with or look at to develop their own AI for their own games. There will likely be little in terms of code so the chances of you copy/pasta code to "steal" my work is poor. Am I worried about you stealing my work? Not really. I'm going to post some sources for what's helping me make my choices so it's in a way, a Thesis paper like US students do in 12th grade, or for their final in 1st year college English. Plus, you lack me. I'm the person behind my work, so all you can do is poorly emulate my creation. As Facepunch's Rust was an attempt to clone DayZ, they realized they couldn't clone a game better & ended up having to go a different direction. Also this is in a way a STALKER clone idea I'm working on; so I can only go so far as well until I have to split to a new path. Also, I'm making these notes based off the Unity 3D engine as that's what I have the most knowledge with. Yeah, Unreal is great but you know what else is? Cryengine, Source, Frostbite, Ogre & proprietary. 
If you have any ideas, input or alternatives, please share. Sorting algorithms & whatnot will be used in more advanced parts of the AI system, so if you have some higher knowledge, it can help when we get to those stages. 

 

Let's get started!
1. What is an AI? To me, Intelligence is anything that can make a choice based on circumstances. The Artificial part just means it's not something that's biologically alive makes the decision. 

2. What's this AI's goal? Large faction armies that will go out on patrols, & fight people that are in an enemy faction, or fight things in coordinated efforts where they are under attack. 

3. Main components of AI? Individual person, squad based movements, Squad's working together, faction based movements. 

4. Individuals? Can identify what's within their sensors, join a squad & take orders from a squad leader. 

5. Squads? A group of individuals that can operate together to perform organized movements & strategies. Main role will be going on patrols, attacking enemy held positions & holding valuable locations. 

6. Squads working together? Squads will hopefully (Stretch goal) be able to identify other squads & either merge if small enough (ei if squad max is 12 and 2 squads of 3 each will make a big squad to work together) or work together to attack a town where 1 squad may attack from the front & the other will flank around. 

7. Faction based movements? Factions will understand where patrols are being attacked in their territory & send reinforcements to assist this area. Understand which areas need to have patrols & what enemy held areas can/should be attacked. 

This is a bit ambitious but we're taking it a step at a time. Arma & its mods do it, why can't I?

Individual AI:
As any experienced self learner may know, trying to build the whole system at once is a bad idea. Coordinated groups of AI need to start from the bottom. We're going to make an individual soldier and work our way up. Following an old Intel (Yes Intel the CPU company) article, in part 3 where groups of AI are discussed, it starts with 

Quote

When last we left out heroes (intelligent agents, or IAs), they had just been given the ability to see what is around them and to figure out where they are going.

This means they started with individual AI. After all you can't orchestrate a symphony without each player having its sheet of music. (aside from like lead sheets, but who here has taken Music Theory & Music Composition?) https://software.intel.com/en-us/articles/designing-artificial-intelligence-for-games-part-3

 

My AI is going to have Sight & path-finding. I won't move onto any decision making till after I get this started. 

Identification

Sight is the main form of identification I will use. 
To hold back on the number of Raycasts (as I don't know how many important objects I'll use) I'll use a box collider as a trigger. This isn't very efficient, but works for the beginning. Because of this I already have some plans in Squad's detection. The box will be adjusted and moved so that way a corner of the box is pointed at the AI's face, and the rest of the box is out infront of the AI like so:

Spoiler

When the box is made larger, it will provide a large viewing area that isn't too wide, and gets wider as you get further. To a point. 

Spoiler

The AI script will then detect all objects inside the box collider. It will compare them to see if they are a friend or foe & if so, it will then draw a raycast from the AI to the detected Friend or Foe. If the Raycast hits it, then the AI successfully sees the target. 

 

However this doesn't give the AI enough knowledge about the battlefield. In addition, the AI will have a circle trigger collider that will be reserved for Scanning the battlefield. This will do nothing until a special function is called. 
This sphere will be large and when combat is initiated, it will detect all objects in the area & determine if they're useful. Some examples of useful information would be cover to hide behind, high ground to...

Spoiler

 

or perhaps a machinegun turret that could pin the enemy down. Presuming things like this get implemented. 

 

Basic tasks

Now that the AI can detect friends & foes, there should be a few things the AI can do. 
First, if the target is an Enemy, it can shoot at it. 
Second, if the target is a friend, it could run up to it to talk to it. 

Third, if the enemy is deemed too powerful, the AI could run to take cover. 

Fourth, if the enemy is deemed way too powerful, the AI could run away to their home base. Maybe to call for reinforcements or warn that a large force is coming this way & defenses should be prepared. 

 

This is almost like Creating a FSM (Finite State Machine) where there are only so many states the AI can be in, & they choose 1 to be in based on the situation but we're just going to talk about the functions for now. 

1. Shoot function

draw raycast from AI to Target. If it can be drawn, follow the next step, or simply exit the action. 

Get a random number between 1 and 10. If the number is greater than 5, tell target to take a damage. 

This can be expanded to draw a raycast between multiple body points, understand distance & then figure out which bodyparts are visible & how easy it is to hit the target. 

2. Walk up to target

Set destination as target. If the distance between AI & target is less than 5 units, clear destination. 

Clearing the destination when withing 5~ units prevents the AI from trying to go inside the target. If the target has a collider, it could stop the AI from ever reaching its destination. 

3. Turn on Circle collider.

Determine which important gameobjects are cover. 

Set destination as closest cover gameobject detected. 

This action can be expanded in the future to determine which side of the cover to go to based on the position of the target & the position of the AI. 

4. Set destination to closest friendly base if one is known. 

 

If you don't know how to set destinations and use the pathfinding, don't worry. In Unity, just add the component Nav Mesh Agent under Navigation. Create a C# script and import UnityEngine.AI then create a variable accessing NavMeshAgent and access the function SetDestination with the argument of a Vector3 position in XYZ format. Then in the Scene view, have a flat piece of land like terrain or a plane, select it, go to windows, navigation, and select bake. Boom, your AI will navigate to the Vector 3 destination if it's within the bounds. 

Spoiler

Should look something like this:

//Script may look something like this:
using UnityEngine; //imports unity engine API for use
using UnityEngine.AI; //Imports the AI navmesh Unity Engine API for use

namespace AI : MonoBehaviour {

  class AI {
  
    NavMeshAgent nav; //Scriptwide variable that any function can access the navmesh agent
	Awake () {
      nav = GetComponent<NavMeshAgent>(); //finds and assigns the value of the agent to the variable
    }
    
    Start () {
      nav.SetDestination(FindGameObjectWithTag("Destination")); //sets the destination to a gameobject found with the tag "Destination." Unsure if case sensitive. I just type all my tags as 1 word starting capital letter anyway so I don't know. 
    }
  
  }

}

 

 

With actions number 3 & 4 you may be questioning, "How do I know what is cover & what is a base?" That's where node based AI comes into play. 

When you play a game where there are guns on the map, you typically start a game thinking "I want to go for the SMG because it does more damage than the starting pistol. It's over here by the green house." You have a waypoint of the SMG spawn point. You don't see the SMG, and sometimes the SMG might not have spawned yet but you know the spawn point of the SMG. The AI works in a similar fashion. Either hard code Vector 3 area points in the scripts, or create a gameobject and place it where you want the cover or base to be. I typically use "Empty Game Object" as waypoints because they only store their location in a scene in Unity. To tell the AI what exactly it is, you can use a variety of methods. I typically use Tags though if you want a gameobject to identify as multiple things, you can't use tags. You could attach a script and have the script be empty where you check if the game object has the script attached or not. Finally you could have an attribute's script where you request the values of variables in this attribute script and see if any variables have values your looking for. Hopefully this paragraph made sense as I used a metaphor & gave 3 examples of tagging. 

 

Finite State Machine & Decision Making

States. The way I'll be using states is by using Functions or variables & each will be a state. 

We will have the Attack State, moving state, and waiting state. 

I haven't decided if functions or variables is better as a state or not. 

 

Function states

The pros to a Function based state is that each function is completely separate from one another. 

The cons is that Functions can be executed really quickly so everything may be working fine, but your AI might be making thousands of decisions per second. 

 

Variable states

The Pros to variable states is that you can use 1 function & simply use an if statement to restrict or allow actions. 

The cons to variable states is that you may have some problems with accidentally having more states than 1 at the same time if unwanted or having complex codes for what states your in that you may not understand. Or you use extra memory for defining numbers as C# is the only language Unity uses & doesn't use #define like C does. It's negligible but still uses up memory. 

 

Combining Functions & Variable states

To me the best option is to take the best of both worlds, though it may seem like the worst of both worlds at first. 

In the Update function, it executes once every single frame. That's a lot of actions. 

What one can do is have every single function called in the Update function. To restrict every state from being called, we'll use a variable to test which state we're in. We can use an if statement or Switch statement. 

To simplify things, in another script, we'll have definitions of each state. 

const shoot = 1
const moving = 2
const waiting = 3

then in our switch statement we should be able to do something like this:

switch(state)
	case shoot:
		ShootState()
		break;
	case moving:
		MovingState()
		break
	case waiting:
		WaitState()

Then by using a timer we can restrict the repetition of actions. Typically done to allow automatic weapons in games without having absurd ROF, people use timers that count up based on change in time. I'll show what I might end up doing for the ShootState:
 

Spoiler

float stateTimer, shootTimer = 0.0f; //creates timer and sets it to zero. 
const float SHOOTINTERVAL = 1/2; //Allows ROF to be 2 for every 1 second. It's ratio of seconds to shots fired. Constants are in all caps so you know they can't be changed. 
const float SHOOTSTATETIMER = 2; //Shooting state will last for 2 seconds before allowing the AI to make a new decision. 
byte state; //1 byte sized whole number variable. Allows whole numbers up to 256 or so. We won't go past 20 and that's REALLY pushing it. No need for 2 bytes on the integer type. 

Start () {
state = SHOOTSTATE; // Just to skip the "How did the AI get into the shoot state, I set it so in the start function. 
}

Update () {
	timer += Time.DeltaTime;
	switch (state){
  		case SHOOTSTATE:
    		ShootState();
      	default:
        	DecisionMakingFunctionToDetermineNextState(); //Not typed out, just as example. 
	}
}

ShootState(){ //State behaviour function. 
  shootTimer += Time.DeltaTime; //Increases shoot timer to allow it to shoot. 
	if (shootTimer > SHOOTINTERVAL) { // Determines if enough time has passed to allow the AI to shoot
		shootTimer = 0; //Resets shoot timer. 
      	ShootFunction(); //Described earlier. Will determine if hits & does damage or not. 
    }
  	if (stateTimer > SHOOTSTATETIMER) { //Determines if the AI was in the state for long enough to now see if it can do something else, or skips if it can keep doing this state. 
      	stateTimer = 0; //Resets state timer
    	state = null; //Sets state to nothing so the AI can go to the "Figure out what state to do next" function is called. 
    }
}

 

This is in my opinion a great start. 
I will get to work on actually creating the parts from this post. Next I will draw up the values and what makes an individual choose what state to go into. That is more design than simple prototyping but will be designed to be modular for ease of adjusting designs later. 

 

If you're designing an AI, already designed AI or if I had inspired you, let me know & tell me about your design process & results. 

 

In case I forget, some future techniques I may use will be flocking, formations, random number generated decisions, and token based attacks. 

[Judd]

I know very little about A.I., but if I was trying to make an AI army like what it seems like you are doing, I would first do it 2 dimensionally. Create the 2D battle ground and add just 1 AI soldier. Next, make you a soldier of your own that you can move it around but not shoot. Could be just a block.

 

Next, make the AI soldier have a field of view of 90 ish degrees taking into account a helmet and peripheral vision.

Then, give this soldier a simple projectile that travels instantly, no delay.

In the code the AI soldiers could all have an const char * indicating they are on the AI team. The another const char* saying if they are a squad leader or a simple soldier. The soldier you control would have a different const char* saying they are an enemy to the AI.

 

Now, you get the AI to run a constant sweep in its field of view (you may want to put in a distance restraint), if it sees a character with the wrong const char* number, then it will get its coordinates and it will aim at it.

 

Once it can do this successfully, then make it learn what cover is and how to hide and peek behind it.

 

Also, like you said if the enemy will over power the AI, well we humans can physically see if it is a different character or if we are taking a ton of damage from it. So the first, you could simply give every character its own const char* for the AI to know how powerful it is, or say if( x damage is taken) hide behind cover.

 

Once it can distinguish between good and bad character, hide behind cover, and aim accurately, then add the squad concept. I do not know how you specifically want this implemented so I will leave it up to you.

 

Finally, the hardest part, I would turn this into a 3D simulation. Starting back to one AI soldier and one soldier you control. The only problem I foresee with this model is if the other player is hiding behind cover how does the AI know if it is hiding or not? Well, you could say "oh well we fired the first shot and missed so something is blocking it", but then you don't know where the AI should go to get a better angle. So there may have to be a visual array that the AI has where it takes its own coordinates, the enemies coordinates, and it says "if there is anything within the coordinates 1, 2 and 1, 3 then I cannot see him because I am located at 1, 1 and he is at 1, 4". Then you may have to run this many more times to determine an angle to go to to see him.

 

This is just my take on it and you are welcomed to say this idea is terrible and it will never work. This is simply what I would do.

 

One example that is worth a look at is Call Of Duty: Black Ops 3 has some of the best bots I have ever seen. However I believe they work by running until they see you and firing. If they don't see you just keep running. This makes them not know what cover is. They will not hide themselves but if you are hiding they will run to your last known location. This is just something to think about.

[Guest]

Before I start, you don't have bad suggestions. 

17 hours ago, Judd said:

I know very little about A.I., but if I was trying to make an AI army like what it seems like you are doing,

I have no idea what I'm doing haha. I read a few textbooks & looked into it a bit. I'm just winging it. From what I've learned is you don't know until you try & no matter how horribly it runs, if it does, you DID create something. 

17 hours ago, Judd said:

I would first do it 2 dimensionally. Create the 2D battle ground and add just 1 AI soldier.

That's not a bad idea. A lot of people do do this. However I believe it can cause problems. The Baseball game is covered first in this video it shows what may go wrong. Because I'm not working in a proprietary engine, I likely won't have these:

Spoiler

 

Also I don't really know the 2D API for Unity. The 2D element is mostly tacked onto Unity 3D though it's very capable. 

17 hours ago, Judd said:

Next, make the AI soldier have a field of view of 90 ish degrees taking into account a helmet and peripheral vision.

I was considering something like this because of this guide here:

Spoiler

 

The reason I didn't go with this is because I plan on having a lot of AI per scene. I may go back to this & instead of having the box & sphere collider, I may just use the sphere collider and then draw raycasts & determine if they can be seen then if they are within FOV angle. 

17 hours ago, Judd said:

Then, give this soldier a simple projectile that travels instantly, no delay.

This is essentially what a raycast is. Not sure if you know. It's like a laser beam that goes on forever until it hits something. 

17 hours ago, Judd said:

In the code the AI soldiers could all have an const char * indicating they are on the AI team. The another const char* saying if they are a squad leader or a simple soldier. The soldier you control would have a different const char* saying they are an enemy to the AI.

Unfortunately C# doesn't have Pointer capabilities. The teams will actually be more than AI & player. The AI will be designed to have to fight itself. The player won't be there for every battle. 

17 hours ago, Judd said:

Now, you get the AI to run a constant sweep in its field of view (you may want to put in a distance restraint), if it sees a character with the wrong const char* number, then it will get its coordinates and it will aim at it.

This isn't a bad idea as one thought I had was "What if the AI had several raycasts pointing outwards?" But I thought that it might be too easy for the player to accidentally fit between Raycasts. 

17 hours ago, Judd said:

Also, like you said if the enemy will over power the AI, well we humans can physically see if it is a different character or if we are taking a ton of damage from it. So the first, you could simply give every character its own const char* for the AI to know how powerful it is, or say if( x damage is taken) hide behind cover.

Of course! This isn't a bad suggestion. I kept the idea broad & when I get to decision making I'll define some characteristics of "What counts as being too overpowering?" 

17 hours ago, Judd said:

Once it can distinguish between good and bad character, hide behind cover, and aim accurately, then add the squad concept. I do not know how you specifically want this implemented so I will leave it up to you.

This is the plan!  I have been reading some textbooks I will mention & I also have the article I linked above. I was considering trying to get a type of "flocking" to work. I'll post more details in what I'll actually do when I get to it. 

17 hours ago, Judd said:

Finally, the hardest part, I would turn this into a 3D simulation. Starting back to one AI soldier and one soldier you control. The only problem I foresee with this model is if the other player is hiding behind cover how does the AI know if it is hiding or not?

That's the fun part! I couldn't find where you mentioned it but some games like splinter cell remember a last known location. I've considered a lot of things youtuber 3KlicksPhilip has done in this video:

Spoiler

 

Iv'e seen his whole series a few times. They're quite entertaining and show quite a few methods to problems he's faced. 

17 hours ago, Judd said:

Well, you could say "oh well we fired the first shot and missed so something is blocking it", but then you don't know where the AI should go to get a better angle. So there may have to be a visual array that the AI has where it takes its own coordinates, the enemies coordinates, and it says "if there is anything within the coordinates 1, 2 and 1, 3 then I cannot see him because I am located at 1, 1 and he is at 1, 4". Then you may have to run this many more times to determine an angle to go to to see him.

Aye. Some important locations like cover may explicitly tell the occupant information. I haven't gotten that far yet.

17 hours ago, Judd said:

This is just my take on it and you are welcomed to say this idea is terrible and it will never work. This is simply what I would do.

this idea is terrible and it will never work. Just kidding lol. They're not bad ideas. 

17 hours ago, Judd said:

One example that is worth a look at is Call Of Duty: Black Ops 3 has some of the best bots I have ever seen. However I believe they work by running until they see you and firing. If they don't see you just keep running. This makes them not know what cover is. They will not hide themselves but if you are hiding they will run to your last known location. This is just something to think about.

I was going to make an AI for a 90s style frag game. Like Unreal tornament, this game has waypoints. If you recall my explanation about the SMG spawn point, when I played Unreal Tornament 2004, I noticed AI would sometimes run past you even after you started fighting just because they run to the different gun spawn points. I think Black Ops does the same thing & they have some invisible waypoints around the map they go towards & when they reach them, they get another one to go to. It's a simple FSM. Their simplicity makes them look better than they may be complex. 

Thanks for the input! 

[Guest]

Sorry for the delay, I've been working on this for quite a while & had several personal matters conflicting and taking priority. 

 

Update in developing the basic sensors & actions:
Before I begin, I'm curious if this is a good method on findings & developing. I remember many forum members saying "It's good to keep a good documentation when creating software." I'm just practicing & keeping this as a resume piece that I may put onto my personal website. (Or condense into a short video to put onto a resume YouTube channel.) 

Secondly I'm not sure if this is even fit for the programming section as it's less of a discussion & more of a lengthy status update/blog. 

Starting with vision:
I decided to change from having 2 colliders to 1. The Box collider cannot be rotated. I could have simply created a child GameObject with a box collider & rotated that however I decided to keep the Sphere collider as the only one. 
Note that if you are having problems getting the collider to detect things in the OnTriggerStay, you must ensure that Trigger is ticked & the part that messed me up-The other gameobject MUST have a Rigidbody component attached to it. Here's the documentation on how to use that specific Function:
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnTriggerStay.html

 

Using this, I decided to go with the technique that Unity uses in their video:

Spoiler

6:17 paused has the code

 

In the video, they have an equation that finds the direction based off the location of the detected object subtracted by the location of the AI. An angle function from the API determines the angle. 

I now have it so it shoots a raycast at the object to see if the AI can see the object. The problem I have now (Major setback) is that either the raycast won't update every physics step or the raycast will just shoot right through walls rendering this step moot.

I had attempted to try and get a line renderer working from the Survival Shooter Harming Enemies video though it wasn't working out either. That or it was working and I just didn't see a shining blue laser on top of the white background.  

Spoiler

The way that RaycastHit works is that it SHOULD stop the Raycast as soon as it makes contact with ANY collider object. I tried doubling down to see * if a Rigidbody would stop the Raycast hitting. 
At the * object in the last sentence I just remembered Raycasts return true IF it hits ANY collider. I have to create an additional check to see if the object hit was infact the detected object. (Sometimes a day of work can be boiled down to "Oh yeah, I forgot I have to do this thing too." Probably why Python caught on as you don't need semi colons. They're technical minded not English Syntax Minded.) 

 

I will skip the cover identification as I want to keep things generally simple for now as until I plan out how later structures of the game will be created. For now if something can be interacted with by AI, there is a tag called Important & this is noticed by all AI, whether or not it's seen is another issue. I'm thinking of doing something like the following to figure things out between enemies & interact able:
 

Spoiler

OnTriggerStay (Collider other) { //Function that detects if things are within the seeing range of the AI
	if (other.attribute == cover) //May find another word like Interactable for environment pieces AI use. 
      ListOfCover.Add(other); //I'll double check but there should be an add that won't duplicate entries
  	else 
      //Do eye sight comparison. 
}
OnTriggerExit (Collider other) {
  if (ListOfCover.Contains (other))
    ListOfCover.Remove(other);
}

This skips a ton of calculations onto all the potential hiding places for cover. 

Now that vision is complete, I can move on; but before I do so, I must say that for better Seeing detection, I would add several points to look at. 
For instance, in Counter-Strike Global Offensive, if you hide behind a waist high wall, the bots don't see you anymore as detailed in this video:

Spoiler

Important segment is at 2:17 though I find his commentary very enticing so the video starts at 0:00 for you to enjoy the lecture:

 

Hearing
Just to make things simple, I'm not going to add ears. Instead I'll add speakers more or less. 
When things make noise, they'll have their own sphere collider or something & then they'll pass the variable of their location to all AI that can hear (Incase there are some deaf or I add a feature where AI can go deaf-ie flashbangs/perminant deafening) and the AI will have an array (to limit) of the number of sounds they heard, with timers so they forget sounds they heard. (They shouldn't remember 1 sniper shot after getting shot at by like a squad of 50 guys.) 

 

Basic Actions

Spoiler

 

Getting the basis of a FSM, we have to make the basic actions one could do. 

With the removal of action #3, I only have 3 actions. 

Go To Point

Shoot
Wait

I'm thinking I should simply create a new class just to store the functions so things don't become too cluttered. For instance, make all the functions public & require the object to pass itself as a variable & whatnot. 

Perhaps at a later date. 

 

I added 3 functions for basic actions:

Spoiler

    void ShootCalculation() {
        int hit = Random.Range(1, 10);
        print("Shot");
        if (hit >= 5) print("hit");
    }

    void GoToPoint(Vector3 destination) {
        nav.SetDestination(destination);
    }

    void Idle() {
        nav.SetDestination (gameObject.transform.position);
    }

The shoot function is just a simple yes no hit based off a basic dice roll. 

I'm considering modelling it after Tabletop Wargames like Warhammer 40,000 and Flames of War. 

Roll to hit, roll to deal damage. 
Later I will work with the Line Renderer again as player feedback & shoot raycasts to near misses and direct hits. 

Those should cover the majority of actions. 

 

Finite State Machine

Now that we have the basic senses in the OnTriggerStay and the basic actions in their own functions, we can start to think about the Finite amount of States. I decided to use the Enumeration user data type of byte. This allows up to 256 different states and lets states be used in place of integers. 

Spoiler

enum FiniteStates : byte {
	idle, shooting, advancing, retreating
}

Using 4 states I can cycle through them with a switch statement in the Update function.

Starting with Idle, I'll have it be blank. 
Shooting will have a static variable as a timer to prevent shooting the entire duration, it sees the player. 
Advancing will have a set position with an exit condition of when it comes withing a set distance of its destination. 
Retreat will occur when the health is set at or below a certain value to start. I'll set a specific way-point but later I may figure out how to find a point that is beyond the AI in a direction further from the player. 

Spoiler

    private void Update()
    {
        switch (currentState) {
            case FiniteStates.idle: {
                    print("Idle");
                    break;
                }
            case FiniteStates.shooting: {
                    print("shooting");
                    break;
                }
            case FiniteStates.advancing: {
                    print("Advancing");
                    break;
                }
            case FiniteStates.retreating: {
                    print("Retreating");
                    break;
                }
            default: {
                    currentState = FiniteStates.idle;
                    break;
                }

        }
    }

 

I'm going to write out all the logic & decision making without posting how I'm doing it but basically in each state's function I'll have control variables like above. 

My main concern is whether or not this thread is constructive to the forum or if it's better suited as a personal or professional blog/paper than a forum thread. 

[wasab]

Will your AI be able to talk and chat with me?

[Guest]

28 minutes ago, wasab said:

Will your AI be able to talk and chat with me?

Not planned unless you mean something like it being a friendly and saying “hey, I need your help.” 

[wasab]

5 minutes ago, fpo said:

Not planned unless you mean something like it being a friendly and saying “hey, I need your help.” 

How bout making an aimibot for CSGO? I can use some good cheat tools. Have the AI display the position of the enemies as well. I've seen this guy on YouTube done it but I can never figure out how to make my own. (Don't know anything about C#)

 

 

[Guest]

4 minutes ago, wasab said:

Snip

 

A bit off topic but if you’re serious, if you PM me with a price offer you’d be willing to pay in advance for me to spend the time on this, I might consider it. However for the time being this thread is more aimed at AI to be used in standalone games. 

The game I’m trying to make has heavy design ideologies around the AI that inhabit the world & their interactions with it.