[AI Challenge] Capture the Flag

6 rounds

 

//opinion

Look, if I decide to give it a try, I'll probably end up scrapping the whole framework and doing it my way even if it doesn't qualify for the competition.

There are WAAAAY too many technical details being discussed in this thread, and usually when people get distracted with minor technical details, it indicates a big problem with rules/restrictions, after which the whole thing goes to hell.

Consider Ludum Dare : "Theme : One Room". That's it. (Also all assets must be done from scratch, you can use existing code base, but will upload them to public)

Then look at multi-tier bullet point list at the first page of this thread.

This would be a much more interesting:

"Create an AI capture the flag game where each soldier acts as an independent agent that relies on sensory input for making decisions".

Automatically addresses half of the concerns and at the same time is not too rigid.

No offense and nothing personal.

 

Well, basically things started off simple, there was then a lot of canweaddthisandthisandthis and in the end it's pretty much the same as the beginning (thankfully!).

I agree with you about not having many rules, I'm not really interested in winning as such compared to simply making something really good. Anyway, I think it's a good enough platform for some serious fun.

 

Things are pretty much as they are when it started with the exception of a Raycast method, method that retrieves all other team agents, and navmesh. Some bugs have been found and fixed and that's where we are currently. How can I improve the rules? I think it covers from having people "cheat" the challenge.

 

OK regarding the Shooting bug you can see it in action in these images.





Soldier A is shooting at Soldier B, note the laser pointer (hint: particle shader looks like laser) is missing the target yet on both occasions the Soldiers Shoot!

My suggestion is that Shoot should have a raycast test, it's like the soldier will only take the shot when there is a target in their sights.

Also if you add a raycast Shoot test, you could check for friendlies and only fire when you won't shoot a soldier on your side.

I will work on a fix... up to you if you add it in.

[Idea] A top down view option would be really cool, and a map (very easy to add top down camera, map layer wall obstacle sprites and player sprites on map layer to render texture!)

Finally got Soldiers that can beat the example ones!

Trying my hand at a Sci-Fi level 32 x 32 so small and quick notice the crates, half height boilers and 'windows' which all work (block paths allow shooting over).


Note the curved corners still have a box collider so give no advantage/disadvantage over basic cubes.

 

SoldierWrapper.Raycast has a raycast test method and only allowing shooting if a target is in that raycast's path would be unfair for users who implement some kind of movement prediction to shoot in the path of the enemy, etc.

The look at method will return true if the angle difference is within 0.5 degrees, it might be causing the small difference. I am going to try lowering it :/

Cool map!

 

I would like to have an extension for the IAgent class. It would be good to have getters for the view angle and the view distance of the soldier.

Now, you just report the positions of the enemies in the list soldiersInSight but I have no possibility to check if they are still there after some time. The Raycast method just delivers an empty RaycastHit object if it hits nothing. But I cannot verify if the check fails because there is nothing or my bot is still too far away.

 

Cheers, Great Challenge.

Map Layout's OK but maybe with bump mapping and texture work it could look half decent.

I don't think the 0.5 degrees off is the issue.

Your soldiers have a 15m viewing distance and a 2m/s speed, your default collider radius is 0.5 and bullet speed is 70m/s so there is no need for aiming off.

Even your 'painfully' slow (haven't you seen John Wick (Movie)) 65 degrees/s turning arc is more than fast enough to track any enemy over about 2m away.

If you had the 'double range sniper when still and not shooting last frame mode' I mentioned then aiming off at >14m would be an issue.

Got it you have a bug in your SoldierExample.Update()

Code (CSharp):

1. // Any enemy soldiers in sight?
2.             if (targetSoldier != null)
3.             {
4.                 // Look at them, if we are, shoot.
5.                 if (LookAt(targetSoldier.GetLocation())) // bug was soldiersInSight[0].GetLocation()
6.                 {
7.                     // pew pew
8.                     Shoot();
9.                 }
10.             }

Makes for a lot more carnage. Great looking blood particle fx, can actually see them now!

 

My sci-fi level was really dragging down the framerate on my aging PC but when I looked into performance the Soldier.EyeSight() method was the main hog...



So I tried to optimize it every which way but to no avail so wrote EyeSight2 based on a SphereOverlapNonAlloc().



Can you see the difference (pun not intended).

The main difference is one SphereOverlap then linecasts to all soldiers in Viewing Distance.

Code (CSharp):

1. public LayerMask viewScanMask;
2.     public LayerMask obstacleMask;
3.  
4.     public static Collider[] enemyColliders = new Collider[32];
5.  
6.     public float viewDistanceSq;
7.  
8.     void EyeSight2()
9.     {
10.         flagsInSight.Clear();
11.         soldiersInSight.Clear();
12.  
13.         // detect enemy and flags
14.         Vector3 pos = transform.position + up;
15.         Vector3 point = pos + transform.forward * (viewDistance - 2f) + up;
16.         int hits = Physics.OverlapSphereNonAlloc(point, viewDistance, enemyColliders, viewScanMask);
17.  
18.         // test for visibility
19.  
20.         Vector3 colPoint;
21.         Collider collider;
22.         Transform colliderTrans;
23.  
24.         Soldier newSoldier;
25.         Flag newFlag;
26.  
27.         for (int i = 0; i < hits; i++)
28.         {
29.             collider = enemyColliders[i];
30.             colPoint = collider.transform.position;
31.  
32.             if ((colPoint - pos).sqrMagnitude <= viewDistanceSq)
33.             {
34.                 if (!Physics.Linecast(pos, colPoint, obstacleMask))
35.                 {
36.                     colliderTrans = collider.transform;
37.  
38.                     //Debug.DrawLine(pos, colPoint, Color.green, 0.1f);
39.  
40.                     if (colliderTrans.CompareTag("soldier"))
41.                     {
42.                         newSoldier = colliderTrans.GetComponent<Soldier>();
43.  
44.                         if (!soldiersInSight.Contains(newSoldier))
45.                             soldiersInSight.Add(newSoldier);
46.                     }
47.  
48.                     if (colliderTrans.CompareTag("flag"))
49.                     {
50.                         newFlag = colliderTrans.GetComponent<Flag>();
51.  
52.                         if (!flagsInSight.Contains(newFlag))
53.                             flagsInSight.Add(newFlag);
54.                     }
55.                 }
56.                 /*
57.                 else
58.                 {
59.                     Debug.DrawLine(pos, colPoint, Color.red, 0.1f);
60.                 }
61.                 */
62.             }
63.         }
64.     }

It's also way less complex!

And you could put in the sniper mode with a simple Boolean check that skips the distance check, Snipers would get the full sphere view an advantage but still limited at range (and need to lead a moving target) e.g.

Code (CSharp):

1. if (inSniperMode ||  ((colPoint - pos).sqrMagnitude <= viewDistanceSq)) //line 32

PS it will also cope with rolling terrain.

 

My WIP AI!

Or why a top down camera view is a good idea.

 

Are the game rules correct?

As soon as one side takes the enemy flag to their spawn zone it's a win.

I thought capture the flag was only won when you take the enemy flag back to your base but keep your own flag, or take out the enemy team?

If you lose your flag you then have to recover it to win or you need both flags to win?

 

Yay found and fixed that accuracy bug, Red have the upgraded accuracy, Blue Have Standard Aiming!

It's that old chestnut offset aiming, because the gun/muzzle is offset from the centre it will not line up with the target the soldier is looking at.

The above adds an AimAt function to the SoldierWrapper that offsets for the gun and does a raycast to check for obstacles (it's needed I've seen lots of wall shooting).

Another option would be to just do a LookAt rotation on the gun or muzzle or tweak the gun in a bit.

 

One question to the level. Do we play the tournament in the current level or do you plan to use a new one?

 

The current level is the level I have planned to use.

 

This is a special kind of capture the flag its a feature I promise :x

I realized this as soon as I posted the competition but felt that requiring flags be at your base as well would be a little more complicated so I left it.

 

Nice finds. Is it consistent with the max range and max view distance?

Also no on that sniper mode, it will complicate this further than necessary.

 

Apex has been kind enough to offer a voucher code for their Apex Path ($95 value). I've added it for first place. Good luck

 

Well your FOV is a 120 degree arc with 15m radius, the current setup for my approach is a 15m radius sphere in front of the soldier 13m forward.

Wasn't Sure how it would compare so...


Soldier Selected, Blue Lines Show Range of FOV, where red/blue spheres intersect is EyeSight2, it's surprisingly very close to Eyesight's FOV with more peripheral view and a tiny bit of behind you sensing.

 

Here is my code for AimAt a SoldierWrapper update that aims the gun at a position but also does a spherecast to check that the bullet will not be blocked by an Obstacle/Wall.

Code (CSharp):

1. public bool AimAt(Vector3 position, out bool LOSblocked)
2.     {    
3.         bool lookingAt = false;
4.  
5.         LOSblocked = false;
6.  
7.         if (_soldier.IsDead())
8.             return false;
9.  
10.         // calculate gun offset needed to aim gun at target postion
11.  
12.         Vector3 lastRotation = transform.eulerAngles;
13.  
14.         Transform gun = _soldier.currentWeapon.GetMuzzle();
15.  
16.         Vector3 gunOffset = gun.localPosition;
17.  
18.         Vector3 toTarget = position - transform.position;
19.  
20.         float offsetAngle;    
21.  
22.         float distance = toTarget.magnitude;
23.  
24.         offsetAngle = Mathf.Atan(-gunOffset.x / distance) * Mathf.Rad2Deg; // x offset to angle offset
25.  
26.         //Debug.Log("offsetAngle" + offsetAngle);
27.  
28.         transform.rotation = Quaternion.LookRotation(toTarget, transform.up) * Quaternion.AngleAxis(-offsetAngle, Vector3.up);                  
29.    
30.         Vector3 lookAt = transform.forward;
31.  
32.         Vector3 newRotation = transform.eulerAngles;
33.         transform.eulerAngles = lastRotation;
34.         transform.rotation = Quaternion.RotateTowards(transform.rotation, Quaternion.Euler(newRotation), _soldier.rotationSpeed * Time.deltaTime);    
35.  
36.         lookingAt = Vector3.Angle(transform.forward, lookAt) < 1f; // 1 degree should be good at these ranges < 15m
37.  
38.         Vector3 gunPos = gun.position;
39.  
40.         //Vector3 g1 = gun.forward * distance * 0.25f;
41.         //Vector3 g2 = gun.forward * distance * 0.5f;
42.  
43.         if (lookingAt)
44.         {
45.             //Debug.DrawRay(gunPos, g1, Color.yellow, 0.1f);
46.             Ray ray = new Ray(gunPos, gun.forward);
47.  
48.             // a sphere cast to check that the bullet which is fat (not a dot) will not be blocked
49.             lookingAt = !Physics.SphereCast(ray, 0.1f, distance, _soldier.obstacleMask);
50.  
51.             LOSblocked = !lookingAt;
52.         }
53.    
54.         /** Debug
55.         if (lookingAt)
56.         {
57.             Debug.DrawRay(gunPos + g1, g2, Color.green, 0.1f);
58.         }
59.         else
60.         {
61.             Debug.DrawRay(gunPos + g1, g2, Color.red, 0.1f);
62.         }
63.         */
64.  
65.         return lookingAt;
66.     }

Will add video below (same post) to show the difference between LookAt and AimAt bots.

Oops I've added collision to my version of the project and still finding some soldiers just don't want to fight then just cuddle together sometimes in groups of 3...? I'll be back... once I sort out me privates troops!

As you can see they even 'Stack Up' (it's just a collision avoidance tweak). And you should be able to see the difference the AimAt function makes from the AimAt teams performance. The AimAt soldiers use the Example soldier code but use AimAt instead of LookAt!

 

I'm a little bit confused about the last code examples of ArrowX.

In the rules you wrote its only allowed to use the Move and MoveTowards methods of the SoldierWrapper class to move the bot. I thought that would include also the rotation of the bot (only by using the LookAt method). Is it allowed to move or rotate the bot without this methods? Can I use my own methods?

One rule also says that it is only allowed to use the Raycast methods of the SoldierWrapper class. I thought this means that it is not allowed to use methods of the Physics class. Is this correct or can I use methods of that class e.g. Physics.OverlapSphere?

 

Arowx is attempting to fix a few bugs and performance issues in the framework.

Speaking of which, for an eight v eight battle, the most efficient way to find soldiers in sight would probably be to distance and angle check every soldier, then Raycast against the ones in sight.

Sometimes a simple approach wins.

 

Yes, but this doesn't answer the question. Is it allowed now or not? Or do you use his code now in your framework?

 

It depends @Samuel411 is the owner, I'm putting forward suggestions and improvements to the challenges framework. If you need features or changes you will have to ask him.

All entries have to obey the rules of the compo or face rejection.

 

You know apart from a few soldier tweaks to the ExampleSoldier Code and the idea of a TeamAIManager I have no idea where to start with a good AI for this game/challenge?

Just talking the talk here so don't expect me to be able to make an amazing killer AI (LOL this is the guy who goes on and on about Deep Learning AI after all).

Here's my thoughts on making an AI for this challenge:

• The soldiers...
  • turn slowly so this is a weakness and can be taken advantage of (although I don't think there is a direction vector provided for sighted enemies. You could maybe work this out from movement?).
  • have limited visual range and FOV, would this allow for ambushes, or moving multiple troops as one 360 sensor.
• The level is...
  • fixed so you could hard code the moves of your team (would this be 'legal'?).
  • mostly open so has no real easily defensible choke points (something most great FPS maps have).
• All the troops are right handed so going round things to the right could provide better cover and faster aiming. If two AI's do this with the current 'circular' layout it could just be a race to the flags and back.
• The current example...
  • does not handle picking up dropped flags.
  • can be stopped or slowed down with only a few troops down the middle.
  • does not defend the flag at base or once picked up.
  • does not directly use sub groups (the random starting positions and centre circle in the level tends to cause them).
  • goes at one speed. Could speed or pace affect tactics?
  • does not alter strategy/tactics based on health, e.g. flag grabber.
• I get the impression that it's all about the angles, you know those games where the player is the only light source or there is strict line of sight. Well every grid square in the level could have a vision value on how much it restricts vision.
• The flip side of vision is cover. I'm thinking there might be some way to calculate the cover value of every grid square but it would have to be from every other square or how else could you work out the best squares when you spot the enemy.
• The challenge has 6 rounds so could some kind of heat map work? To move your troops away from where they get shot and towards where they shoot the enemy.

What are you thoughts/ideas on how to tackle this kind of AI problem, care to share, all hints and tips welcome?

 

"What are you thoughts/ideas on how to tackle this kind of AI problem, care to share, all hints and tips welcome?"

I'd do like a SSAO/global illumination style pass over the map, find the locations that had the lowest amount of exposure, then use that data for positioning.

I don't think that "tactical ai" as most people would think of it has anything to do with winning this challenge. It's about breaking down probability and increasing odds by paying attention to small details like "right handedness".

If 'ties' are decided by kills, I don't think any competitive AI design will be focused on touching a flag. In playing around with a couple ideas, I've personally never thought about the flag. My thoughts are always focused on how to reduce angles and maximize the number of shooters.

Moving is the biggest vulnerability. So I would think you want to figure out how to avoid that as much as possible.

Could be wrong, but those are my gut instincts. People want larger teams, but I would expect that to reduce the number of viable strategies since you increase the opportunity for like massed fire one shotting a guy as he crosses an edge.

I would really recommend that the point system strongly favor fast action and encourage movement. If you don't get some kind of massive point bonus for touching a flag (with very significant time based bonus), I really think this will become very degenerate. If 'degenerate' strategies are prevented via disqualification then the game becomes finding the line where you can use the most abusive tactics without being disqualified.

This is all raw speculation though. Maybe someone can come up with 'fair' tactics that work, maybe the specifics of the map layout or the turn rate don't allow for as much degeneracy as I think. Who knows.

 

But if both sides choose not to move it's a draw?

Here's an idea, here's the map...



What's your play?

e.g...



Here's red doing a 4x2 flag run with edge runners and blue are going for an ambush strategy. Who do you think would win this?

My take on this is blue will get in position faster, and should stop reds middle runners with 2-3 guns vs 2/2 at the middle point then reds surviving middle run will hit two more blues outside the flag zone. I'm guessing reds middle runners will be taken out.

The question is will reds middle runners do enough damage to allow the reds edge runners to make the flag. Assuming they do that's 4 vs 3 in the flag zone with the potential for 1-3 near flag/edge defenders.

Remember we are talking 65 degrees a second turning rates so the blue ambushers should get 2-3 shots off (0.6 seconds a shot) before red can retaliate. Mind you red could run it's 2 man teams with 240 degrees vision to improve detection and reduce aim for times.

Just an example but if it works for American football maybe thinking up plays, could work for this, and it could be fun...

What's your play (MS Paint TM)?

 

Looking over the map from top down, I think red team has a huge advantage. The square right next to their deployment zone is one of the best locations on the map in terms of angles.



My play would be to camp there until the clock runs down to the latest time I could (hopefully killing some of your guys) and then march to the flag and back as a solid block, the 'march' would probably not involve any return fire unless directly in the path. The logic of the 'march' would probably depend on how many guys blue has left at this point.

As blue I would have to do tests on exactly how possible it is to kill red when camping around that spot. This would most likely be a race between movement speed, turn rate, vision range and the exact squares involved.

The "camp until last moment" is probably ideal depending on the exact details of the scoring system.

 

Arrow is experimenting, this won't be in the final project.

You can only use the Raycast methods because they take into account your field of vision and viewing distance. Meaning that if the raycast is out of your FOV or distance it'll return and empty RaycastHit. Raycast methods you make or Spherecasts will probably not take this into consideration.

 

Teams are alternated every round, keep that in mind. 3 rounds as blue, 3 as red.

 

Hadn't thought of that, I just copied and pasted AI code for another game I made. I should probably optimize that one too using a sphere cast. I pushed a new version with a few bug fixes and this implementation which improved speed 6x. Down to below a millisecond processing time with 16 units in the scene.

 

Cool competition, sorry to see it's being ruined by Arrowx.

Due to his constant babbling about his ideas, I fear something will be changed mid tournament that will just cause frustration to the ones actually competing. "The squeaky wheel gets the grease."

Based on that, I will not compete.

 

Lmao. Sorry to hear that. I can assure you however I am a little too lazy to make any major changes. So far all changes have been super seamless and just bug fixes. First day was adding in some methods I hadn't thought of but I think everything right now is more or less final unless I find more bugs. I'd like to change your mind

 

Your right of the 132 post I have made 23 posted so far, and my contribution summary is:

1. (Q) FAQ and Request for Video/Graphics.
2. (Q) Query over openness of challenge submissions.
3. (R) Chat about openness and possible metagame.
4. (F) Feedback on 6 possible bugs and 5 suggested improvements.
5. (I) Comment on performance of LOS Eyesight() approach and suggestion for improvement.
6. (C) Hint to use in Mathf rounding to avoid position bugs.
7. (I) Ideas, half height walls and navmesh.
8. (I) Static sniper idea.
9. (FS)Tested half height walls and they work suggest crouching for stealth.
10. (R) Designed a complex level and tested it showed images (half walls in level).
11. (R) Clarification reply post to other poster.
12. (R) Comment on collision and why it's not in and the concept of the legion strategy or bug?
13. (I) Suggestion for collision and topology/height on maps.
14. (FS) Tested map with topology and it works suggested tweaks needed for map height and Collison to work.
15. (R) Reply to poster about advantages of topology e.g. strategic advantages/disadvantages.
16. (C) LookAt bug fix in SoldierWrapper.
17. (I) Comment on the need for > 4v4 team size to actually have strategy in the challenge.
18. (Q) Query on level design.
19. (I) TeamAIManger proposal.
20. (C) Code to try and fix collision/overlap bug/feature.
21. (F) Minor damaged by bug reported.
22. (Q) Query on rounds per match it's.
23. (RI) this post

Or

(I) Idea/Suggestions 9
(C) Code/Fix/Improvement 3
(R) Reply 6
(Q) Question 4
(F) Feedback 4
​

I apologise if my enthusiasm for this community challenge puts you off, my posts 'babbling' are aimed at improving the challenge for everyone.

Of course I could just be Meta Gaming you Mohammed Ali Style, if you rage quit I win!

And we could have a challenge with SniperMode (non moving/shooting soldier gets boosted visual range next frame), Topology (more tactical depth), Half Height Walls (free), Collision*, Weapon Aiming*

*go on we do need these it looks/works way better and I have the code to fix it!

[Suggestion] Fixed deployment Pattern - Now it's 8v8 we can avoid the advantage/disadvantage of random placement with a fixed pattern. Note: about 4.5 second difference between positions in starting box.

@frosted OK your Square Hedgehog Ambush might work against the Example but what happens if I do this...


AnglerFish Edge Feint 4/4 split with a delayed edge run. Team A manoeuvre to get the right side advantage and turn your men towards them. Team B delay a bit then do an outer edge run on the flag when your men are focusing on Team A.

PS @frosted how would you aim your Hedgehogs quills 4 left, 4 right? As that could block the AnglerFish's teeth.

 

I dont disagree that it'll make things more interesting its that it would complicate things for less experienced devs and scare them off. It is also already released so anyone working on something will need to start over due to new features.

 

I've already had to start over due to the team size change. I had an AI that was great at 1v1, decent in 2v2, not so great at 4v4. Now with only 8v8 battles I have to scrap/cannibalize it if I want to continue.

 

You know, I think I was wrong. Even if camping behind that square is really effective, it really comes down to the little details. Like you said, what direction they're facing, etc.

If you suspect that the enemy is camping and waiting till the last minute to make a flag dash, you could just time it so that you wait outside their vision and grab their flag first.

Maybe you can do other stuff like trade aggro between a clump of dudes and distribute damage so a camper simply cannot kill all of them in time, (race between rate of fire/aim, movement rate, and hitpoints).

So I think some of my earlier posts were wrong, it may not be degenerate at all, as long as people are aware of and planning for strategies like those. It's entirely possible that a kind of 'meta game' emerges with different approaches and counters.

If that's the case, then well... may the best ai win.

 

Im really sorry for throwing that in at the last minute.

 

If you run the example a few times you will notice drastic changes in groupings, contact points and outcomes the cause is mostly down to the initial random deployment pattern of the soldiers.

[Idea] For Future Challenges - Deployment Patterns, as long as the deployment area is fixed to 9x9 then players could have custom deployment patterns which can have a big impact on the games outcome.

Had the idea that it might be possible to scan a levels Line of Sight pattern with a simple moving light...

In theory you could then parse this LOS data into useful info for your troops, the problem is how could you incorporate the data into this challenge when you only have a single Soldier.cs file to play with?

Data Point - the level has about 2,601 squares.

 

You can throw as many classes as you want into a single cs file. You could hard code the baked LOS data into a class. Using the data would be a more significant challenge then baking it.

 

Under which license is the content available? In case I decide to do the "scrap half of the framework and do things my way" thing.

 

There's a license file in github, MIT license.

Feel free to do whatever you want with the framework. Some of the assets used however may have other limitations, the ones used are listed in the credits section of the readme.md in github and in the first post.

 

Got it. (Should've checked github straightaway, I suppose. Forgot that having a LICENSE file is encouraged on github).

 

It would be great to have some other AIs to fight against as just the ExampleSoldier. After playing around with some different approaches, it’s easy to win against it.

It would be nice if everyone who participates at the challenge also indicates if he allows Samuel to publish his solution or not. On that way, we could analyse the different approaches and improve our own solution for the next challenge.

 

My approach will be to make a lot of different AIs and make them fight eachother. Otherwise it would be pretty hard to arrive at an optimum solution.

 

Yeap, I do this, too. But on that way I only test my own ideas. I suspect that you use maybe some totally different approachs I don't think of

 

I can see how this would work for improving the basic soldier example, improved Aiming, team based shooting, better flag grabbing, but...

Why makes lots of different AI's when you could think about what makes them different and put it in one AI then have lots of different data profiles/configurations battle it out. Upside of this approach is it could accidentally hit on a combination that you would not have thought of.

For Example:

• Defenders 0-8
• Attackers 0-8
• Groups 1-8
  • Ambushers - Ambush Points A,B,C,D
  • Left Flankers - Flank Points A,B,C,D
  • Right Flankers - Flank Points A,B,C,D

Even with this simple set of Plays there is a very large set of possible plays.

PS: This is like Genetic Algorithms they all use the same code but have flexible data DNA that drives what they do also people tend to test their fitness and discard the weaker ones.

[Edit] A Quick way to test might be to make a random AI, it simply chooses a random location to move to/prior to the target flag for all soldiers or groups of and leaves a random number at the spawn site. You then run it lots of times against your AI and see if you can spot problems with your AI. A heatmap might be good for this, one for where your AI's are shot and one for where it shoots the enemy.

 

@Arowx yeah, I didn't mean a new script for each one, but rather changing settings and configurations etc.

@THoeppner yeah it would be good to be able to download other's source code, if they want to post it.

 

Well if you post your AI first I'll post mine!

Really there is a fun meta game in posting or not your AI or a dumb early build, surprised more are not posting their failed AI's.

 

@Samuel411 How many submissions have you got so far?

I think you should be open about this, even update a submission count on the top page.

 

[Procrastination or Artwork] OK Have you seen this board game...

Well it got me thinking could we take the AI challenge and re-skin it with Giant Robots, something like this...

OK, my mecha 3D skills are not up there with WETA's, but it actually fit's the blocky cube obstacles better at this scale.

Or just for fun and giggles Monsters VS Mechs?

Also would a board game style of play add much more strategic depth, dice/rolls, energy, damage limiting weapons/actions. Food for thought for future AI challenges.

One of the advantages of the TanksAI challenge was it still had a player controller, would having a simple RTS style player controller improve this challenge?