[Home]FloodMini

Robo Home | Changes | Preferences | AllPages
FloodMini is like FloodMicro with some of the movement from my test bot, SandboxFlattener put back into it (and alas, some removed again), and a somewhat effective deviant GuessFactorTargeting gun. This is probably my first all-around effective bot. FloodMicro was somewhat good at beating good bots and bad at beating bad bots, and of course it lost to most elite bots. FloodNano was almost stupidly simple, and lost to a lot of really basic bots, but it also beats a lot of really good bots (actually, among these bots that it beats is FloodMini, I'll come up with some way to hit him, though... maybe...). FloodMini is both hard to hit and hard to consistently dodge, so it should beat less advanced bots fairly handily and it also beats a lot of more effective bots.

What's special about it?

Call it a hunch, but I think we can consider this "Kawigi's official first good bot".

Great, I want to try it. Where can I download it?

https://www.robocoderepository.com/BotDetail.jsp?id=1462

How competitive is it?

In my tests, it does very well. It saves data between matches, too, which makes it more competitve over a bunch of short spurt-like rounds. It's not too slow to learn, either, and it's a good early-round robot (due to its movement).

How does it move?

See FloodMicro. The movement is based on SandboxFlattener, my test bot. It is less tweaked than FloodMicro, which I think is good - the test bot was pretty well tweaked, and a few of the things I added or changed going to FloodMicro were just not worth keeping.

How does it fire?

A sort of deviant version of GuessFactorTargeting. Someone (it might have been Nano) told me that some Duelist bots do this, too - I have my stats divided on distance (which is pretty standard) and the absolute value of their LateralVelocity. I have distance factors segmented every 100 pixels (10 of them, I just make one segment for 900 and further), LateralVelocity divided into 3 segments. And then I have 31 guess factors ranging from asin(-9/bulletv) to asin(9/bulletv). I take all the stats using power 3 wave-style bullets, but my opinion is if the guess-factor is translated into an angle using the bullet velocity as I just said, the stats are valid for other powers of bullets, at least at reasonably close range. All stats are also taken relative to the sign of the bots lateral velocity (or last sign of it if the enemy's lateral velocity is zero). I believe that SandboxDT does it this way too, and logically, it should help it learn twice as fast against most competitive opponents.

As of version 1.2, the statistics are also segmented on the opponent's relationship to the wall - one segment if they will hit the wall if they continue at their current velocity and direction for something like 10 turns, and another segment if they won't. Almost every bot except SandboxDT (1.81 and later) is weaker in this segment, and it was enough to get me to start beating some generally better bots like Cigaret.

As of version 1.3, the statistics are segmented on acceleration - I use actual change in velocity instead of change in lateral velocity for this, because I just felt like it. One segment for staying at roughly the same speed, one for accelerating, one for decelerating. I think this gives the LateralVelocity segments more meaning, and helps me tell a real story, especially when the opponent only slows down when he's changing directions.

For the sake of size, and because I've found it a little unstable, I've never used rolling averages in FloodMini. I also fire a wave every turn and laugh at all the top bots who don't react to bullet fire the way I do and allow me to learn about 16 times faster against them. FloodStationary? only fires a wave when he fires a bullet, so as to be a better diagnostic tool.

How does it dodge bullets?

It reacts to bullets being fired by its opponent by changing direction and speed. It doesn't react to every bullet like FloodNano, but it should react to about the same number as FloodMicro. The movement does have some weaknesses, which may be fixed by a future attempt at a similar movement, but it is (in general) strong, and it is meant to particularly be aimed at making GuessFactorTargeting less effective. This is ironic, since it uses GuessFactorTargeting itself, and it is probably less effective at hitting itself than it needs to be (run it a few rounds against the other Flood series, GouldingiHT, or MakoHT to see what I mean).

How does the melee strategy differ from one-on-one strategy?

I have not made it work intelligently in Melee, so I expect its primary strategy would be to lose, whereas its OneOnOne strategy is to win.

Just a note about using it in melee battles - it will load up data from one bot, and if it doesn't crash every battle with an exception (which it may, starting with version 1.3), it will possibly corrupt that data. Of course, it won't save over the data unless it actually wins a round.

How does it select a target to attack/avoid in melee?

I suppose it would aim at guess factors on the very edges of the range and always hit someone other than who it's looking for if it hits at all.

What does it save between rounds and matches?

It saves its guess factors and its DynamicDistancing factors. I'm not sure if I've ever read up on another bot that saves defensive information between matches. Can anyone think of one?

Where did you get the name?

Just like FloodMicro, but twice as big :-p The test-robot for this basic movement concept was SandboxFlattener, named as such to flatten out that SandboxLump into a beach to make it hard to hit by GuessFactorTargeting. What flattens out a pile of sand like nothing? A flood, of course...

Can I use your code?

Sure. Especially if you're working on Wave or GuessFactorTargeting, check out MiniBullet? and how I use it in FloodMini - it's a fairly effective wave-style virtual bullet class that could easily be applied to either and could also be easily made more versatile. I thought about only including that in the source, but then I realized that half of a class is in how its used externally (especially if you keep cutting down code). If you are making deviants of it (I didn't comment it very well), the 1.41 that is hard-coded in is supposed to be an estimate for asin(10/11), my internal max firing angle offset.

What's next for your robot?

After I see how it does for a little while, I may tweak it a little, or I may leave it alone. Or I may find a bug. I almost uploaded it a day earlier before figuring out that somewhere in my code-trimming I created a bug, which I luckily finally found today.

Does it have any WhiteWhales?

I like to think that they're all problem bots, and I'm the WhiteWhale. Realistically, I think that FloodMini 1.3 is capable of beating any current robot except for SandboxDT, and will probably beat most robots most of the time.

What other robot(s) is it based on?

SandboxFlattener, FloodMicro. I suppose SandboxDT, since I borrowed some aiming concepts from Paul Evans, but not in actual code. I was originally actually going to make this a pattern-matcher, but I had a bug in the MiniBullet? class that I didn't figure out until after I converted it all to statistical targeting.

Comments, questions, feedback:

I know for sure Fermat saved defensive information between matches. Try shooting him with a circular targeter. :p -- Kuuran

Marshmallow has done this since Kawigi showed us how to serialize in a zip stream. Princess does it. And it's the only thing Mako saves between matches as well. I, like you Kawigi sure take movement seriously. =) -- PEZ

Nihil also saved defensive data...a lot of.... HoD

Yes, I think segmenting on closeness to walls can be very good. Marshmallow used to do it, but since I only have half-solved the issue with many-segments=>slow-learning I had to remove it. So Cigaret is vulnerable in that segment huh? Maybe that was why Lacrimas had such en edge on it. (Since Lacrimas fed it's pattern matcher with this information.) -- PEZ

Congrats on the #12 ranking! -- PEZ

Congrats again. You now have two bots before any of mine. I must work harder. -- PEZ

Congratulations!! Great work Kawigi.~;] -- iiley

I readed FloodMini's source code,and known that it stored 5580 int and 40 double for every opponents,and one data file is about 2.5KB,My testing bot CigaretST stored 2583 float for every opponents,but one data file is large as 5KB,i know int and float is all 32bit number(is that right?),2583 float should my about 1/2 of 5583 int,but i get double size of 2583 int's size.This is a large problem for me to improve my gun,is there any guy know the reason?Kawigi? Thanx in advance. -- iiley

Maybe ints are better gzipped than floats? -- PEZ

Oh~~ints,mybe i would have a try on ints.It seems that ints can be gzipp to 1/4 of floats can be. -- iiley

Have you confirmed this in a test? That would help me a lot, because I currently save doubles and should, without losing precision, be able to use longs. And since I don't save nearly as many cells as any of you this should make my data files really small. Or, leave room for more segmentation of course. -- PEZ

Yes,of course,those my true testing.You can have a look on my CigaretST's datas.But i cannot sure is the reason is between int and float.Maybe FloodMini's data is more compressable.~;] -- iiley

Woah, longs? I think ints are more compressible the way I use them, because the first two bytes of every one of them is usually 0's, and quite often the third byte, too. That's because I'm using a count of hits to the bucket instead of an average. If you were to just directly convert doubles to longs in a way that would create extremely large numbers, I think that would still be wasteful. FloodHT 0.9 will use a combination of ints and bytes to store data even smaller ;-) -- Kawigi

FloodMini produces this error message from time to time: :-( --Dummy 

kawigi.sbf.FloodMini 1.4: Exception: java.lang.ArrayIndexOutOfBoundsException
java.lang.ArrayIndexOutOfBoundsException
    at kawigi.sbf.FloodMini.onScannedRobot(FloodMini.java:124)
    at robocode.peer.robot.EventManager.onScannedRobot(EventManager.java:607)
    at robocode.peer.robot.EventManager.processEvents(EventManager.java:738)
    at robocode.peer.RobotPeer.tick(RobotPeer.java:1024)
    at robocode.peer.RobotPeer.turnRadar(RobotPeer.java:1086)
    at robocode.Robot.turnRadarRight(Robot.java:1001)
    at kawigi.sbf.FloodMini.run(FloodMini.java:41)
    at robocode.peer.RobotPeer.run(RobotPeer.java:616)
    at java.lang.Thread.run(Unknown Source)

Ah, I suppose I don't bound my distance factor there. Oops. It should only happen at a distance of 1100 or more, though. -- Kawigi

IIRC, the scan range of a radar is 1200, so you might want to use that as your maximum distance. --Dummy

Yeah, that's way better than using getBattleFieldWidth?() like I usually do. =) -- PEZ

Well, I suppose I could do that. What I would normally do however, is cap it off (group the furthest few segments into one segment), but when I went from using distance to using bullet flight time, I lost the built in way I used to bound it. The 1100 might sound aribitrary, but it's the distance a power-3 bullet travels in 100 ticks, and I have 10 segments of 10 ticks each. -- Kawigi

Robo Home | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited October 27, 2003 19:15 EST by Kawigi (diff)
Search: