Viewing a history listing
Was just reading oldwiki:RobocodeNG/Archive and came across this choice quote from Albert.
Robocode as it is has reached its maximum. It was more than a year ago that the las truly new idea came (ie. WaveSurfing) and now its all tweaking and optimizing... really boring.
Not sure the date, I think 2005ish. =) And here we are, 7-8 years later, still reaching new heights with our bots. No more paradigm shifting breakthroughs, true, but tons of refinements, many small to medium improvements, and a few pretty big ones along the way. To me, it seems like Wave Surfing was more the beginning of something than an end to Robocode innovation. I think we've taken a more precise and mathemetically sound approach to all aspects of our bots since then.
Since then we've had:
- Precise Intersection
- Precise min/max GFs
- Bullet Shadows
- Kd-trees (and with them, fast log-based targeting)
- Super-survivalist bullet powers
- Gunheat waves
- Genetic tuning of variables
- Shoot-everybody melee gun
- Melee surfing
A lot of these ideas were dependant on wave surfing to begin with, I agree a little with Albert's quote, but it was a bit like saying that now that the transistor (or vacuum tube) was developed, suddenly hardware design was over. I would say no, it has only just begun =) Once we had wave surfing, the same ideas and stats which we used for gun we could adapt for movement, although the lower quantities of data posed a whole new set of problems. I would argue that before wave surfing, the tweaking of movement profiles was much more boring than what we are doing now (although definitely had a lower barrier to entry).
K-nearest neighbours/kd-trees and genetic tuning in particular are bleeding edge AI techniques that come from outside the Robocode world.
Yeah, very well put. At this point, "Wave Surfing" feels to me like a very broad term that would be applied to any intelligent movement system, while there are still so many differentiating details beyond that. I mean, looking at any popular game or sport, most are long past the stages where earth shattering insights can be discovered about game play, but that doesn't mean they are immediately uninteresting. Michael Jordan didn't really do anything new, besides just doing everything better than everyone ever. And he's a pretty exciting chapter in basketball history, if you ask me. =)
Sort of on topic, as I've been working on a new game recently and designing rules, I've been thinking a lot about Robocode's rule set and how much of the game play depth is by luck or by design. It's pretty insane and impressive that the game has held up so well for so long. I try to give credit where it's due and believe it's by design. But then I think about how the scoring had to be changed after release because Mat didn't realize that a non-shooting bot might have the best survival strategy. And how simple the sample bots are, or even the earliest public bots - it's like nobody had any idea where things were going. But maybe if you have some good grasp of game play mechanics at a fundamental level, you don't have to be able to see where things are going to know that you have something with balance and depth. Or maybe Robocode isn't really all that deep compared to what could be, but it's the best we have in a really cool genre and succeeds for lots of other reasons too.
Robocode is NP-complete as most games with depth. Other games might include chess, go and poker.
But Robocode is more than simply a complex game. Having tanks and bullets as theme makes it a lot more fun. There is an intuitive feel about how a tank should behave. Moving and aiming efficiently is simply not enough, robocoders like to make theirs bots move smoothly or turn their guns without shaking.
The engine being open to everyone, with anyone being able to develop a bot (not necessarily competitive) and also being able to upload them in an open internet environment removes most barriers to entry. And being an AI competition ensures there is always someone to compete against. A great deal of Robocode longevity can be credited to RoboRumble.
I think the coolest thing about Robocode is the fact that it has incomplete information, but some information. As in, we don't know what they will be doing, but we can see what they are doing now, and we don't know where they shot, but we can tell that they shot. I'm not sure if this was accidental or not, but it allowed for an extremely complex set of strategies to emerge, and I think it is something which you should attempt to incorporate into BerryBots if you can =)
But yes, I totally agree with MN here, without the rumble and the competition it provides Robocode wouldn't have been nearly as interesting =)
FWIW, I have absolutely been trying to keep some good dynamics with incomplete information in BerryBots. But I haven't spent enough time writing bots yet to get a good feel for what I have so far.
I think what I'll end up with in BerryBots is significantly more information than you get from Robocode on an open battle field, but you also don't see anything beyond walls (besides death events), which is pretty major. I also think that between the visibility stuff and how I'm planning to model the coding of teams, team play could be a lot more fun and popular than it is in Robocode.
Out of curiousity, with regards to teams... how large teams are you thinking of? Some of the videos you've showed with a bunch of bots bouncing around make me think it would be kind of neat to do large swarms if it can be done with acceptable performance :)
Well, I'm certainly leaving the door open for huge teams (say 20, 50, 100 bots?), which I also think would be awesome. Running more than a few complex bots at once is probably not going to be a great experience on the Raspberry Pi, so running huge numbers of bots isn't a major focus just yet. But it should be fine on modern computers.
The big difference in how I want to handle teams is it will just be one program controlling multiple bots, instead of independent programs with only cumbersome messaging between them. You'll have a global view from the visibility of all your bots and be able to control them individually without messing with communication protocols or anything. This should also offer performance gains - the engine has a lot less line of sight calculations to deal with, running 2 Lua states with 50 bots each seems a lot nicer than running 100 separate Lua states, and the bot author can eliminate duplicate processing that would probably exist in each bot if they were running separately.
Imperfect information (invisible bullets) is what makes learning strategies dominant.
If radars could see bullets, Robocode would easily degrade into a ramming game. Imperfect information was probably intentional.
I agree that the game would be much less interesting with visible enemy bullets. However, I don't think that the game would devolve into ramming, or at least, not only ramming at the higher levels. It might make an interesting Robocode sub-species.
Actually, make the bullets visible, crank the gun cooling rate up, and get rid of the turret so that a bot can spit a bullet out in any direction it wants.
With visible bullets, the focus would become (in addition to ramming) the construction of configurations of bullets in air that are impossible to dodge. Pinning the enemy into a corner so that they have limited dodging options would be paramount.
The counter-resonse would be to shoot down the incoming wall of enemy bullets, though this means that one is spending time on defense rather than offense. The refinement of that would be finding the pockets of space-time that bullets could serve both a defensive and offensive function! This would probably represent an investment of processor cycles way beyond what has our bots skipping turns these days.
It'd still be interesting, but probably not as interesting. That information asymmetry really makes things fun!
Yeah, I was thinking that the incomplete information aspect has a lot to do with the depth of Robocode as well, but it's certainly also true that the rumble has a lot to do with it's longevity, allowing it to survive quieter periods when some authors are inactive.
The comparison to other NP-complate games like chess, as well as the incomplete information aspect being brought up makes me wonder how chess strategies would differ if the game rules were modified for incomplete information (i.e. you can only see spaces that your pieces either occupy, can move to, or can attack)
Oops, NP-complete means the perfect move can´t be easily calculated. NP stands for Non-Polynomial runtime complexity.
But yes, imperfect information is a key feature in Robocode.
Perfect information and imperfect information usually leads to 2 completely different paths. The first leading to backward induction style analysis and the second leading to forward induction.