[AI Challenge] Capture the Flag

Been playing a bit with my own AI routine, just simple tweaks and the stack of one or Legion strategy is obvious.

This is really a bug that should be easy to fix e.g. an inner default collider could work.

Just Tested (PhysicsManager Matrix): The reason why soldiers don't collide is the navigation fails, with logjams.
Hint: Navmesh should really be used for this as it handles navigation smoother.

 

Does this mean its allowed now to use the NavMesh agent? Or can I use only the NavMesh?

Don't misunderstand me but this challenge starts to get mixed up like the last one. If you change to many of the rules people must change their strategy or have to rework the whole code.

 

OK I think we need to keep something in mind. Although it's fun and all to win through taking advantage of glitches and bugs, the whole point of this is to make us better at writing AI for games. That means that if at all possible, rules should be modified so that it encourages semi-realistic tactics. The end result should be something that looks like it belongs in a game, something where if you saw it as a player you would think "Damn, those enemies are going to be fun!"

Suggestions:

• Definitely enable friendly fire;

• Instead of making things complicated with collisions, why not just disable weapons for bots that are stacked in the same cell?

• Navmesh is unnecessary for this challenge and complicates things. I think it's perfectly possible to make something fun with this chessboard navigation system.

Let's keep this simple and solid. It should be something that can prototype core AI behaviours without getting into too many (or any) subtleties. The more complicated this gets, the more @Samuel411 has to work, and the less people are going to participate. This should be a very simple starter for more competitions of this type.

 

Keep an eye out for passing scope creep.

 

If we want this challenge not to fail, we have to take work off Samuel411's shoulders. So let's just keep this simple and straightforward.

Also, a well-built AI is one which takes advantage of a few states and weaves them into something beautiful. The idea that you have to be sporting 1001 conditional states to get anything interesting just shows a lack of understanding.

Let's think of this like chess. There are very few rules or subtleties in regards to individual states, but what makes it great is how a great player combines those simple states. The point of this competition should not be to make a sophisticated chess game, but a sophisticated chess player (AI).

 

You only need to click on the physics collision matrix to prevent user overlap.

A simple raycast to prevent moving into an occupied space or tweaks to the physics materials e.g. no friction.

Really it's simple and only needed for movement, the Grid system is still good for sensing the levels layout.

It would also allow basic topology providing the strategic/tactical height advantage.

 

See this is where it gets complicated. What about if two agents move into the same spot at the same time?

It's not needed for anything that has to do with making this challenge a fun and interesting one.

We definitely do not need a third dimension of complexity.

 

I vote for the NavMesh. This would be a good extension.

Also for the friendly fire and don't let be the bots on the same spot. You can easily achieve the last two points with the collision matrix as ArrowX mentioned.

 

I'm on the fence about navmesh. On the one hand the grid simplifies things and is more approachable in terms of designing the AI movements, but in navmesh's favour, it is kind of relevant to making AI in most games. Overall, I think for this competition we should simply have the grid system. There's no compelling reason why it would prevent interesting AI.

The problem with physics collisions is that it can result in a bunch of unhandled behaviour. What do you do with an AI that tries to walk into someone, slides around it and is jammed against the wall halfway between two cells? In a grid-based system this would be difficult to handle.

One thing I've noticed even in AAA games is how much stuff is animated rather than using physics. In Uncharted games for example, I read that a lot of AI vehicle behaviour is just animated along a spline path. This no doubt makes it very easy to prevent unhandled behaviour. Surely for us beggars, there's no reason to use something more complicated when it's not necessary? Just disable weapons for AI in the same spot as a penalty, and let people script-animate their AI to avoid collisions.

Don't forget, we have yet to have a competition like this succeed. Let's make this very simple and straightforward, and focus on getting participation and making it very approachable to everyone.

 

I'm thinking the movement with the NavMesh looks much better and we can use it out of the box for pathfinding. Otherwise you have to program your own pathfinding and I would prefer to concentrate on other parts of the AI. The already implemented A* pathfinding of the GridManager looks a little bit buggy if you check the results of the found paths.

To check if the bot runs into another one is one of the challenges the AI must solve. Therefore, you can check if the next cell of the grid is available. Of course, this check has to include the bots now, too.

But I have to agree that the solution with deactivating the weapons has its own charm. You have to check also if you run into someone else. Otherwise it could happen that all bots are on the same spot and are totally helpless

 

The basic GridManager and soldiers Rigibodies can handle maps with Basic Topology. The above map has 2.5 dimensions with raised and lowered sections. The ground mesh just needs a Mesh collider. Exactly the same setup as the current example map. Although best to make the obstacles in a modelling package to match the topology (separate mesh).

It would just need a check before you move to next grid square.

Note: Obstacles and meshes still need to fit the grid based movement system.

The Soldier.EyeSight() would need changing over to a Sensor Trigger or Cast of a 3D Mesh/Sphere to cope with the ups and downs (but as I said previously it should be faster than 60 raycasts a soldier). Aiming might need a tweak to align correctly to targets above or below the centre line.

Also used soldier collisions, can I just say when they don't lock each other up it looks great.

Unless the rules of chess have changed you can't stack up pieces on the same square in the same 3d space.

 

Tell me one reason why adding topology would enable people to produce more interesting AI without adding complexity? Obviously a gentle slope as in your example would be an unnecessary addition, since it wouldn't change anything about the AI movements except for making raycasting for enemies way more complicated. And having ledges and walkways is well, just way too complicated for this competition.

One of the main reasons I think we should not have physics collisions is that one unforeseen state of affairs can jam the entire AI team for good. By allowing AI to move through eachother for a penalty, you make it undesirable to collide, but it won't prevent your AI team from continuing and showing off whatever other interesting stuff you've got to show.

Even if I was making AI in a game, I would actually not have physics collisions anyway if I could help it, because it's more important for the show to go on than it is to prevent some rare wierdness where one AI goes through the other (not that capsule colliders bouncing off eachother looks any more realistic anyway).

 

You should not be raycasting for enemies directly you should sphere/mesh/box checking (or better still using a trigger sensor and OnTriggerEnter/Exit()) for enemies then raycasting or spherecasting to check to see if they are visible.

Spotting, Sniping, Chokepoints, Attack Routes, Defensive Points.

For instance a fast route to the enemy flag could be a low route that climbs towards the flag point, easily defensible and ideally the climb would slow down the enemy making them easier to take out.

And another route could be slower but go higher making it harder for the enemy to spot you and with a downward path to their flag giving you an visual and speed advantage.

Detecting the strategic advantage/disadvantages of key areas of the map is fundamental to a good tactical AI.

Without topology we can only have choke points/funnels or open areas we will not have viewpoint advantages of high points or the defensive advantage of hills that slow down advances.

 

It looks like the SoldierWrapper.LookAt() function has a bug as soldiers open up at perpendicular angles from their assailants (eulerAngles wrapping calculation bug).

I think this fixes the bug...

Code (CSharp):

1. public bool LookAt(Vector3 position)
2.     {
3.         bool lookingAt = false;
4.  
5.         if (_soldier.IsDead())
6.             return false;
7.  
8.         Vector3 lastRotation = transform.eulerAngles;
9.  
10.         transform.LookAt(position); // + (transform.right * -0.5f));
11.         Vector3 lookAt = transform.forward;
12.  
13.         Vector3 newRotation = transform.eulerAngles;
14.         transform.eulerAngles = lastRotation;
15.         transform.rotation = Quaternion.RotateTowards(transform.rotation, Quaternion.Euler(newRotation), _soldier.rotationSpeed * Time.deltaTime);
16.  
17.         //lookingAt = (Mathf.Abs(transform.eulerAngles.y - newRotation.y)) < 0.5f;
18.  
19.         lookingAt = Vector3.Angle(transform.forward, lookAt) < 0.5f;
20.  
21.         return lookingAt;
22.     }

 

Way too complicated for this competition. The idea is to attract people who probably don't have a lot of time to spend on it. I'm starting to think we should have started with a pac-man level.

In the meantime, the current layout seems quite good, and any non-interesting opportunities for taking advantage, such as stacking players in the same square, should be handled in a 'prototype' style manner, such as simply switching off weapons or incurring a points penalty. Let's keep it bare bones, there's a lot of opportunity here for interesting stuff.

 

Since everyone is voicing their input, here is mine:

@Samuel411, you should create a document and dump all of the suggestions there. If/when you decide to host another AI Challenge you can take those suggestions into account (even if the challenge isn't the same game).

The only changes that should be made to the current challenge are bug fixes and handicapping an obviously broken strategy.

My vote for fixing stacking units is to disable weapons.

Are you going to post leaderboards every once in awhile (once you get entries of course)? That was my favorite part of the first challenge.

I do plan to participate as long as unnecessary changes don't continue to be made.

 

Another very minor suggestion to help prevent potentially broken strategy:
- limit ammo to 100 per guy, this is more than enough for anyone who isn't trying to be cheesy (or higher if needed - just make sure you can't just always be shooting)

I might recommend giving points out for simply touching the flag (maybe extra amounts if you do it quickly). I have a feeling that as it stands, nobody will actually ever touch the enemy flag much less bring it back home.

 

Why though? If someone wants to spray the whole place, chances are they won't hit anything worthwhile.

 

if there isn't an ammo cap, you should constantly shoot at a corner/edge. period.

this might even not be 'gamey' - like in a real firefight - if you had limitless ammo, this is exactly what soldiers would do. never stop shooting.

 

Yeah but a) chances of hitting anything are very low and b) there are multiple routes to any place on the map, so it would be easy to avoid that area if e.g. one of your teammates just died there. It's basically an example of an AI that wouldn't get very far imo. And I think it's an example of a strategy that pushes the other teams adaptability in the right direction.

 

No NavMesh agents are not allowed you can however use the NavMesh.CalculatePath method to get a path as seen in the NavAgentExample class. The entire project is the same with the exception of the PathGenerated list being a list of Vector3s rather than Cells.

Like I said before, I'm not going to change anything if I can help it and if I do I'll make it as seamless as possible.

 

Not to worry Daniel, Like stated before if anything changes it'll be seamless as seen with my NavMesh switch. I'll post a Post mortem once the challenge ends, I've got a few things to note. And for the leaderboard I'm planning on adding making videos every week or so as soon as code comes in the door and posting the results.


[Edit] As for the stacking units this can be countered by approaching enemies at varying directions allowing you to take them out since the look rotation speed is slow. I'm not sure how to otherwise fix this issue. I'll have to try to figure something out without affecting the challenge, the weapon disabling is interesting, I'll need to play around though.

 

Good catch thank you. I pushed the new change to the repo

As for your other suggestions, I appreciate the enthusiasm, however at this point too many change might discourage others from joining in and seeming too convoluted. We can look at the results of this challenge and learn from it and prepare for the next ones

 

Easiest way to deal with cheesy/degenerate strategies is just to disqualify them.

Make it clear that this is a subjective judgement call and that you'll try to be fair but that your judgement call is final.

There's a bunch of borderline degenerate things that might be a tough call, but at least you can deal with the worst offenders w/o making a ton of extra rules or complications.

 

Are there any prizes for this?

Basically the way I see it, it is few days worth of work, assuming that the idea was to make an AI for independent agents that are supposed to act as a group despite having no "master controller" for them.

 

Probably just fame and adoration.

 

Id like to get some prizes in other than fame
In the post I'm asking for any gracious asset developers to donate some stuff. I have a few assets myself so those will be guranteed rewards and if i cant find any developers by the end date Ill chip in and buy the winner or top two an ai related asset.

My asset store publisher profile: https://www.assetstore.unity3d.com/en/#!/search/page=1/sortby=popularity/query=publisher:12076

 

These community competitions are neat, I like the idea of them and I think regular community engagement like this is awesome. While this can easily be too complicated and deter entries (AI theme probably too much imo) I still want to support them so that they might grow into something consistent in the future.

So, I'm happy to offer an asset store voucher for Deftly to the prize pool.

 

I would be incredibility honored and grateful to be able to offer your asset as a prize

I agree that these things can very easily become convoluted, I'm trying my best to refrain from trying to add more features. I hope to write up a post mortem after so others may learn more about hosting something like this and things to look out for.

Once again, I appreciate the offer and I'm sure other will as well

 

...I think I'll probably pass.

Just can't get excited about the idea.

 

Come on, you know you want to! Besides, it's the most productive thing to come out of the forums in a long time.

 

I'd just mention that prizes may also intensify the competitive side, which may encourage more min/maxer style approaches that are really focused on purely winning and less on the spirit of exploring AI. I am definitely not the only person on these boards who just immediately thought about stuff like stacking or sitting in a corner not moving. I'm just the only one who posted it instead of sitting there cackling to themselves waiting to demolish people using more fun techniques.

 

I agree. Something that would fix that is to judge based on criteria which may include creativity. I don't know if a change like that would be well received at this point to be honest. Like you also said before extra points for touching the flag is a good idea as well. The plan was to make it a tournament style of mash up where everyone's AI goes against each other and eventually we'll end up with a victor, however having points might spice things up.

 

We could always wait to see if anyone uses a degenerate strategy before we try and nerf it. No point borrowing tomorrow's work.

 

One question I don't see answered here: how many soldiers per team?

When I first cloned the project I believe it was 6v6. With the latest pull it is 2v2.

 

iirc - on git - 3 separate things - 1v1 2v2 4v4

 

I'd suggest having an 8v8, makes it possible to run some more interesting and complex teamwork.

 

With the current system there is little to no need for AI or strategy in < 4v4.

If you look at Counter Strike:GO tournaments they are 5v5 but your looking at least Human Level AI (for the players).

5v5 or high opens the door for tactical decisions, sub-groups of soldiers, 2-3+ man teams.

You could set up separate routes/defenders and attackers and you could do it with minor changes to the basic example soldier.

@Samuel411 The Solider index field would be ideal for grouping soldiers if it was populated?

What about 8v8, 16v16 and 32v32?

In theory based on the example level you could have 80v80 (9x9 start zone, -1 for flag).

 

@Samuel411 are there any guidelines for levels as I'm tempted to try my hand at a level design (artistic).

Would level designers need an additional layer for the level art other than the obstacle layer. Then the levels could have buildings, bridges and 3d structures without affecting the grid obstacle layers.

 

I definitely think @Samuel411 should reconsider. Can't see a reason to restrict this, or why adding more would make things more difficult or less fun.

9v9 is a comfortable number for tactical decisions given the map size. I'd want to put at least 2 and preferably 3 on a strategic point so that if 1 dies then there's at least one backup, and so there's at least 1 covering while the other is moving in any subgroup. I'd want at least the option for 3 subgroups.

4v4 is very restrictive, it basically rules out tactical repositioning and a lot of other things that might look really cool and fun such as specialties. I was looking forward to working with the 9 or whatever that came with the original project I downloaded.

 

I think this Challenge really needs a TeamAIManager class, relying on a SoldierWrapper makes adding any Team based AI clunky at best. A TeamAIManager would simply need to keep a reference to all soldiers so it could send them basic orders e.g. MoveTo/Attack/Defend similar to an RTS game.

It would also make it easier for your AI to know the status of your team, soldiers left.

For this to work well I think a level Map is needed, the GridManager is close to what you need but it seams very clunky and inefficient with it's Dictinoary<Vector2,Cell> when an array of Cells or even Enums would do for a basic map.

It would also provide a simpler AI API for people to work to...

So shall I write a basic TeamAIManager class?

Proposed TeamAIManager

• Get a simple map array of cells from GridManager.
• Get list of all team soldiers.
• Provide a Grouping Mechanism e.g. a List of groups (List) of Solders.
• Methods to move groups to locations.
• Method to receive enemy contact reports from soldiers.
• Method to receive KIA reports and to update groups.
• Methods to receive Flag Captures/Flag losses.

This approach would allow for low level Tactical Soldier AI and higher level Strategic AI at the Team/Sub Group level.

Is there anything else it would need?

Also it would not change the basic system as it would be an addition to it.

 

You just need to designate a team leader, and hand it off to someone else if they are killed. This is sort of what happens in real life anyway. The communication is up to you. It's not necessary or even in any way realistic to have some kind of omnipotent AI manager.

I'd rather that the project was handed over in as minimal a state as possible, I don't want someone else's implementation of a manager if I can help it. Basically I just want a simple map and a bunch of soldiers with a clear way to move around and shoot, it's all I need to make something fun.

 

Like Billy said, that can all be done in the soldier classes. There's nothing that restricts you from having one soldier handle everything.

As for the team size I think 8v8 might be a good alternative?

 

That's enough for me.

 

I think I have a fix for the collision and overlapping soldiers (feature/bug)...

• Enable SoldierA/B collision in Physics.
• Reduce Radius to 0.25
• Update SoldierWrapper.MoveTowards() to the following...

Code (CSharp):

1.  
2. public void MoveTowards(Vector3 position)
3.     {
4.         Vector3 pos = transform.position;
5.         Vector3 direction = position - pos;
6.         direction.Normalize();
7.         Vector3 d = direction * 0.3f;
8.         if (!Physics.Raycast(pos + d, direction, 3f, 1 << gameObject.layer))
9.         {
10.             //Debug.DrawLine(pos + d, pos + direction, Color.green, 3f);
11.             Move(direction);
12.         }
13.         else
14.         {
15.             //Debug.DrawLine(pos + d, pos + direction, Color.red, 3f);
16.             Move(transform.right);
17.         }
18.     }
19.  

• Also needs this little fix in NavExample when players move off the path...

Code (CSharp):

1. void CheckTarget()
2.     {
3.         if (!moveToTarget)
4.             return;
5.  
6.         if (pathGenerated.Count <= 0 || pathGenerated[0] == null)
7.             return;
8.  
9.         if ((transform.position - pathGenerated[0]).magnitude <= distanceNeeded)
10.         {
11.  
12.             if (pathGenerated.Count > 0) distanceToNext = (transform.position - pathGenerated[0]).magnitude;
13.  
14.             pathGenerated.RemoveAt(0);
15.          
16.             return;
17.         }
18.  
19.         // recalculate path if knocked off course
20.         if ((transform.position - currentCell.GetPosition()).magnitude > 1.75f)
21.         {          
22.             GeneratePath(_targetCell);
23.         }      
24.      
25.     }

It's not perfect as troops still get a little tied up but no lockups so far.

 

Has anyone else noticed the inaccuracy of the weapons?

There is a minor bug in the Bullet damage system, when a bullet hit's something it passes the current position of it's firer. Now as the bullets are moving physical colliders (speed 70 units a second) that position is the current position of the enemy not it's firing position.

 

@Samuel411 How will the tournaments be done with the multiple team sizes? Is the same AI going to be placed into each tournament and the results added up?

My suggestions for future AI challenges:

• Only have 1 tournament
• Have no map data available to the user. You need to generate the map yourself by exploring.

Yep, adds a layer of strategy to it. Getting in close will give you a better chance at hitting your target.

 

The bullets were giving a current position of the shooter instead of the position of the shooter when the bullet was created. I updated the Bullet class. Also bullets have random rotations with a range of -0.2 to 0.2. Not the most amount of inaccuracy.

 

I updated the judging section it'll be 1 tournament rather than 3 and just a 8v8. I apologize for the sudden change but hadn't realized that 3 tournaments would be impractical.

No map data would be neat, something I'd like to explore in future challenges.

 

How many rounds a match?