A friend of mine came up with a fantastic strategy based around the fact that shot strength was a float that could be modified.
He used this to have his team fire extremely weak shots at each other, with the value of the float encoding different messages. He then used these to co-ordinate his bots against the enemy as a team, instead of individuals.
TIL that Wi-Fi encryption is vaguely akin to a VPN, in that it encrypts at the TCP/UDP/etc level, not the IP level, and TIL also that Wi-Fi encryption (which is a stream cipher) does not alter packet lengths.
Soooo, when you "pair" such a lightbulb using this protocol, the companion app is actually just spraying empty packets with specific packet lengths to 255.255.255.255, and the lightbulb's ESP8266 (or similar) is sitting in monitor mode and circularly-logging the lengths of the packets it sees into a buffer in memory until it sees a valid setup message.
If you presume the setup message is protected by some sort of key you'd be sorely mistaken :D your Wi-Fi SSID and PSK are available in plaintext to anything and everything that happens to be in monitor mode at the time. Like I said, genius yet very very hard to not see as deliberately chaotic-evil.
A while back after skype got rid of their sdk I was annoyed that the app didn't unfurl gifs. So I reverse engineered their api for sending/updating messages and I realized you could update a message that contained a file. The only problem was the file had to be on their servers or a client wouldn't display it. So I reverse engineered the ios app as well to find a way to get a file on their servers (I don't recall why I couldn't do it from the web api). After that I had two things: a way to get files on their servers, and an api to update messages. So I took each frame of a gif, uploaded to their servers, and then used the api to update the message at the rate of the gif.
Of course there will be people making discord bots out there laughing at how simple this sounds, but the combination of reverse engineering as well as applying that to affect a new feature in the app I thought was pretty novel.
Most people went for an "if-based" strategy. If close to wall turn, if pointing towards enemy shoot, etc. And when that works apply some more rules and geometric calculations.
I did mine trying using neural nets. One net that would learn the movement patterns of opponents (offline) and predict positions and shoot there (since bullets have move time). That actually worked fairly well with a really simple net.
For movement, however, deep-RL etc wasn't that big yet, so I struggled a bit. What to train on? So I used genetic algorithms to train this part of the net. Not the best results, but it worked. Mind you these were simple homemade nets, not sure deep learning even was a concept then.
Hard to write a good fitness function. I tried to deduct the fitness if it hit a wall. Then it would just stand still. Tried to then increase fitness based on movement, then it would just oscillate at one spot. Etc. Etc. GAs exploit all loopholes, pretty interesting.
Great fun. Great tool to explore programming at all levels.
Literally survival of the fittest!
But that worked much better as a fitness score, yes. It's very true that what you measure is what will be optimized for. Both for employees and robots.
One tank is hard enough, but team-games where radar-free drones have more HP seem to provide interesting strategies.
The Radar system is very smart in this game, at most covering 22.5 degrees per tick. Converting one enemy is easy enough, but getting a good view of the battlefield as a whole seems like a different game.
I guess singlebot games and 1v1 is easier to test and make AIs for, and was more fun for larger sets of the community.
[1] https://store.steampowered.com/app/871930/GLADIABOTS__AI_Com...
"wave surfing" is necessary to beat AI-guns (statistical learning) to ensure your bots are "flattening the gun curve", to minimize the gradient, minimizing any system (be it statistical or neural-net) from learning your patterns. Extending the wave-surfing principle to a team-setting means using drones to purposefully protect your radar bots.
---------
Advanced single-player 1v1 dueling bots can already shoot 0.1 bullets to "protect themselves" (the 0.1 bullet travels to "block" out any bullets that are on their way to the planned destination), by using this principle. Stationing a "shield drone" to perform the job would be much much simpler.
---------
https://robowiki.net/wiki/Wave_Surfing
https://robowiki.net/wiki/Waves
All you gotta do is:
1. Detect the wave as the enemy shoots (Bots can't see bullets, but they can see the loss of energy from 0.1 to 3, indicating a fired shot)
2. Plan out where your bot is going to move when that wave intersects your bot.
3. Shoot a "protection bullet" along that wave, blocking any enemy bullets that would intersect with your planned location on the wave.
Alternatively, #3 could be "station your high-HP radar-free drone" to be in that area instead.
Case #1: Your enemy predicts where you are. In this case, the drone (or protection bullet) will cancel out the enemy bullet.
Case #2: Your enemy fails to predict where you are. In this case, the drone / radar-bot / 0.1 bullet will missed entirely. Since 0.1 is the minimum energy spent per shot, you will have more energy than the opponent by the end of the game, and you can kill them once they're unable to fire.
------
It seems that with a good enough radar-network (such that you have 100% vision of the entirety of the enemy forces), you could accurately track all waves. Of course, enemy forces could move in such a way to try to escape your radar vision. Etc. etc.
In any case, the "meta" for the team-game is unknown and untested. There's questions like "how many radars are needed to effectively fight (probably more than 0, probably less than an all-RADAR team).
---------
Because 1v1 duel-bots are so good at tracking waves, the multiplayer meta almost certainly will be about finding "nodal points" and coordinating fire, so that enemies cannot avoid the mass-fire from these droid-bots.
Similarly, moving in such a way that you position your bots far away enough to minimize overlapping vulnerable zones is another point.
Alas, most "team games" are just an off the shelf Melee-bot x5 with very basic "friendly-fire" awareness. I think part of the reason is that the default rulesets (the size of maps and whatnot) are insufficient to develop a fun meta. The Robocode community must first find a good set of rules (map size, in particular) that will create a fun environment to experiment a variety of different strategies.
They'd have four days to come up with strategies and develop their robots and on Friday there was a tournament between all the developed robots. The best teams got a non-trivial prize (and bragging rights).
It was really interesting to see which strategies the students came up with and how they changed from year to year. The amount of material provided really made a much larger difference than one might expect.
Among the interesting challenges of Robocode is that the bullets you shoot are so slow that your opponent has ample time to dodge, so you need to predict their movement. On the other hand you can't see where your opponent is shooting so you need to guess and move elsewhere. It's really quite fun.
I'm assuming you had a longer time frame than one week? I realize this is a long shot, but do you happen to remember what strategies performed best when you took that course?
A programming competition at MIT, it looks like they change the engine out every couple years. When I first encountered it, it was a starcraft style game. Now it looks like agents competing in a resource constrained environment.
For the rest of the thread, Wasm allows the rlc chess engine to limit the amount of instructions executed or memory allocated while supporting lots of different languages, so no language has preferential treatment. The strong sandboxing of Wasm allows anyone to run anyone elses code without worrying about an adversarial attack, either accidental or on purpose.
I used a Java GA lib called Watchmaker and trained my bot against built-in bots AND against a world no.1 bot of previous years.
At that time I could barely code cleanly and I was mostly fighting the frameworks so there was a point where evolution in 3 dimensions (acceleration, bodyTurn, turretTurn) were implemented, but maybe one of the most important one, shooting was not.
I run out of time, next day I had to give a presentation so I just gave it a go. Surprisingly the bot evolved to a point (in minutes) where it beat the ex world champ bot. First its performance went above 50% which was a shock, but later it got to 60%+ sometimes even 80%. But how? How to beat without a single shot?
Turns out evolution and random can find you things which are so anti intuitive you could basically never come up with. ( I had a sense of that, that’s why I choose that domain ;D )
What I have seen is that my bot evolved a really simple but weird technique to dodge the champs bullets: it found some kind of frequency and on that frequency it has just… acceleration up and down (negative velocity) and HIT THE WALL AGAIN AND AGAIN. Wat?
The champ bot’s prediction was just too good but not prepared for such a stupid enemy like my bot and it was basically impossible to predict that my bot will slow down for V to 0 in 0 sec so champ was almsot constantly shooting ahead or behind my bot, shooting the wall instead my bot. If the wall wasn’t there, it would hit almost 100%.
Shooting requires energy and after a given time both bots lose energy at the same rate. My bot could win just by “backing out” and not being hit too often, wasting the enemies energy.
Since that experience I could not care less about NN (except neuroevolution), evolutionary algorithms ftw! :D
(I hope no one will create the AI killing us all thanks to my comment. :D )
[1] - https://en.wikipedia.org/wiki/Omega_(video_game) - https://corewar.co.uk/omega/files/misc/omegamanual.pdf
Carve out a day every year to write a brand new bot (no reuse) to see how it fares against older bots. Try to outsmart ourselves.
At the moment, using classic actors but it'll probably shift to typed actors next time around.
https://github.com/UNEcosc250/2018assignment3
I also put in a bit about "tankfighting with insults" a la Monkey Island, to try to give a little exercise in streams.
(Relatively safe to link because I'll be updating it next year anyway)
Some years ago, a colleague and I ran a software studio course at UQ where we used the original Robocode codebase as the starter project, and had teams adding action-replay, Call of Duty style killstreak rewards and all sorts of other odd features.
(Though the pain of the original Robocode Java codebase was there was a 1,000 line long class that was so central to everthing that by the time students were done with it, it was a 3,000 line class. Our hopes of "prime target for students to refactor" were thwarted by "turns out, students don't do that".)
Roboforge also did another thing that I still - even two decades later in this microtransaction-laden world - haven't seen again: Paid tournaments!
You could enter your bot into online tournaments for free, or you could pay something like $5 to enter a paid tournament, and if you won you'd win a real-money prize. There's probably some huge legal issue around what pretty much amounts to gambling, but it was brilliant.
[0]http://www.roboforge.altervista.org/ [1]https://en.wikipedia.org/wiki/Roboforge
Each tank can move, scan other tanks and shoot.
Your tank has hit points and shooting a bullet decreases your hit points by the amount of firepower you used.
Bullets are particles that move over time, so you have to shoot not at where other tanks are but where they are going to be at based on their last position seen on radar.
