- [View source↑]
|Thread title||Replies||Last modified|
|Rumble Topping||7||17:32, 20 June 2013|
|Bullet Detect||2||17:15, 17 June 2013|
|Match Length||1||16:45, 10 May 2013|
With this you are at the top of every one of the one vs one rumbles. Now all you have to do is melee nano, micro and mini rumbles, then the team and twin duel.
Yes, he is winning a bit much. Someone should do something about that. Trouble is he is winning because he is good and he puts in a lot of effort. Talent+work, a hard combination to beat :-/
I am working on updating my microbot at the moment as it is languishing down in 7th. I am pretty sure I can raise it a few spots but I doubt it will be able to challenge 1st.
My next project is to make a mini bot by adding wave surfing to my micro, but as a new minibot entrant that is unlikely to be a contender for a long while.
I have put a lot of effort into my nanos, even stealing Yatagan's movement, but have only managed to get up to 2nd. I have one bot that might win (my bechmarks suggest it will rate 80.6 APS, just above Yatagan), but am hesitant to release it as it uses an opponent table, which is cheesy.
The only other option I can think of to topple Yatagan is to update LittleBlackBook, which as I mentioned in a previous post should be able to get up to around 84 APS. Updating all those tables would be hard work. I dare say Mike had lots of testing and table generating code for LBB that I would have to rewrite from scratch to do a proper job.
I didn't say it was bad. I just found it interesting.
I might've been the last to come "close" to stealing of his crowns, in General 1v1 (RumbleArchives:RoboRumble 20120730). So it's one of your turns. :-P
I'm trying, I'm trying. I've just been spending my robocode time writing the guide to Gilgalad (about 1/3 of the way done with the javadocs). I find that taking a break from robocode has been very bad. It means I need to re-learn lots of the stuff I was working on, but hopefully documenting Gilgalad will get me back to where I left off...
Not quite. EpeeistMicro legitimately took the micro throne from Toorkild a while back. Unfortunately, it wasn't there long enough to be archived.
Well, I share Nano with Sheldor, so I don't think that really counts. He got it most of the way there with the main structure, I did the tuning and feature-cramming.
Personally, I think my most vulnerable bot is CunobelinDC. That, or Neuromancer, although I think a 1v1-specific bullet power function would help there a lot.
I am working on a new version of my microbot and noticed that Cotillion and several other top bots use different bullet detect logic. I am currently using 0 < energyDrop <= 3. Cotillion uses energyDrop > 0, but also corrects enemy energy in onHitByBullet and onBulletHit.
Having thought about the robo-physics of it that looks to be superior as it will not miss a shot that is coincident with taking damage. Is that correct?
Also assuming that enemy energy is adjusted properly then energyDrop > 0 is sufficient and the <=3 is no longer necessary to avoid false detections?
With that the only issues would be ramming and wall hits, but that is a little hard to account for in a micro.
Yes, that's correct. I found it helped my stop-n-go a lot doing it this way, and the <=3 didn't have any effect on score. Also, don't worry about ramming because if they are ramming then they are too close for stop-n-go =)And wall hits would be nice to take into account, but I'm afraid they are a tough nut to crack even in mega, never mind in micro :-/
Yeah, I've found using
onBulletHit adjustment instead of limiting the energy drop to be much more effective against linear targeting, because if the enemy fires the same tick the bot hits it, or the same tick it hits a wall, or even the same tick it gets a bullet hit bonus, its fire will not be detected. If you have some codesize to spare, I would also recommend adjusting the enemy energy variable on
onHitByBullet, to make it even more accurate.
I was thinking of this, but hadn't gotten around to it yet. The reason I went with the other way was because of execution speed.