Talk:Cannon

Initial Discussion

Ah, another Dynamic clustering micro bot! I made one not long ago, it's called MagicD3. Good luck with yours--CrazyBassoonist 16:04, 20 September 2009 (UTC)

• How did you fit the Waves into the micro? (I couldn't figure out how, so I decided to go with PM for now) --Starrynte 17:05, 20 September 2009 (UTC)

• Well, you can take a look at the source code if you want, I wouldn't recommend it though; there are other micros that do the same thing with better wave tracking and smaller codesize. But basically what I do is gather data when the enemy fires, then put it that data into an ArrayList(maybe LinkedList, I don't remember). Then I go through the List and check to see if each wave has passed the enemy, and if it has I remove it from the list and put it into a log of firing angles to use. Right now my targeting is segmented on lateral velocity, advancing velocity, a rolling average of the enemies lateral velocity, and distance.
• RaikoMicro or Aristocles would be good places to look for examples of waves in a MicroBot. --Voidious 17:26, 20 September 2009 (UTC)

Any suggestions for movement (I have around 142 bytes)? --Starrynte 01:57, 1 October 2009 (UTC)

With only 142 codesize to spare.... you probably can't fit a movement more advanced than any you see in a NanoBot. My suggestion would be to go with either a simple random movement with musashi trick, or if you feel really daring try a so called 'velocity surfer' movement like a few recent NanoBots have tried. For overall strength of the bot though, I think it'll be kind of critical to slim the gun codesize further so you can fit a movement better than a NanoBot movement. --Rednaxela 02:34, 1 October 2009 (UTC)

Now have 170 codesize, if that's any better (BTW, are the units of codesize bytes?) --Starrynte 04:14, 1 October 2009 (UTC)

I'm 90% sure that the unit of codesize is not bytes, despite the fact that the robocode says "bytes" when packaging the bot. Often people say "bytes", but I'm pretty doubtful that's the case. Then again, I'm only 90% sure, not 100% sure. --Rednaxela 04:18, 1 October 2009 (UTC)

A little research turns up that in Java, "Each bytecode opcode is one byte in length", so it very well could be bytes. --Starrynte 04:43, 1 October 2009 (UTC)

If I am getting a spike around GF -0.1, what does that mean? Also, is there such thing as a getMaxVelocity() method? --Starrynte 16:27, 3 October 2009 (UTC)

There is no getMaxVelocity(); --Nat Pavasant 16:40, 3 October 2009 (UTC)

As a quick note, looks like you forgot to change "Movement ripped straight from WaveSnake" when you changed to SandboxFlattener --Rednaxela 17:36, 3 October 2009 (UTC)

Rambots

Any advice against rambots? --Starrynte 15:26, 4 October 2009 (UTC)

• Speaking of which, when I put Cannon (0.94) against Sanguijuela (0.8) in Robocode 1.7.1.4, Sanguijuela seems to teleport. Is it just my Robocode? --Starrynte 15:26, 4 October 2009 (UTC)
• In small codesize bots the most effective way to deal with them is probably distance control and energy management. About the teleporting, that seems like a pretty major problem. It might be related to a teleport bug I heard about in a previous version of robocode; can you describe it more? When does it happen and where does Sanguijuela teleport to/from?--CrazyBassoonist 15:31, 4 October 2009 (UTC)
• Sanguijuela doesn't even appear at the start; it just shows the text with energy, name, etc. in the bottom left corner. But when Sanguijuela dies, it shows the death occuring in the field in the top left corner. I also uploaded a (very short) video showing what I mean, http://www.youtube.com/watch?v=w3RozSP1h2w. --Starrynte 15:50, 4 October 2009 (UTC)
  • You should file this as a bug on sourceforge --Darkcanuck 03:09, 5 October 2009 (UTC)
• The trouble I'm having is that though I set it to 165 distance, 1) It's still kind of useless against GrubbmThree 2) The MusashiTrick kicks in though it shouldn't (it kicks in if it dies in the first 3 rounds, idea from RaikoMicro), making things even worse. --Starrynte 15:56, 4 October 2009 (UTC)
• Well, I don't really know what you should do about that; just try experimenting with different ways to do it. But you could still try firing power 3 bullets when they get close to you, I think that's the main thing that helps in my robots. By the way, I'm about to upload a version of my DC micro with a new anti-HOT trick that should work better than Musashi's =) --CrazyBassoonist 16:34, 4 October 2009 (UTC)

Weighting

Because there are millions of combinations of weightings, is there an easy way to find the best, rather than testing each? --Starrynte 04:02, 8 October 2009 (UTC)

No, unless you count grabbing from DrussGT or something =) --Nat Pavasant 04:06, 8 October 2009 (UTC)

Disabled

When an enemy is disabled, is its energy less than 0? If not, how can you tell the difference between a disabled bot and a bot with exactly 0 energy? --Starrynte 16:25, 10 October 2009 (UTC)

No, its energy is exactly zero, so that's how you can tell they are disabled. --Voidious 17:04, 10 October 2009 (UTC)

Ah yes, I forgot that "0.0" could be rounded. --Starrynte 17:24, 10 October 2009 (UTC)

AntiPM

Any suggestions for not being hit easily by PM (mainly in the SandboxFlattener)? (also, Avipes movement is frustratingly hard to hit, any suggestions on that?) --Starrynte 03:17, 13 October 2009 (UTC)

Flat movement’s weakness is PM. I don't think there is any easy and cheap way to avoid PM. About Avipes movement, I think it is Minimum Risk Movement so... --Nat Pavasant 03:37, 13 October 2009 (UTC)

Yeah, avoiding PM is tricky, and in my experience just involves a lot of trial and error. It's not like PM hits Random/Flat Movement any better than VCS or DC (in fact, definitely worse). But it is very tricky to tune against, and it doesn't particularly care about a flat Movement Profile. --Voidious 03:50, 13 October 2009 (UTC)

I once managed to make a almost-nano-sized anti-PM-surfer. It seemed to perform better than the average random movement against PM guns, but only marginally so at best (and it's habit of running into walls didn't do it any good). So anti-pm movement is possible, but that said, I don't think it could fit in a micro-bot without being the only movement scheme. Another idea I once had for dodging PM, was designing an incredibly long non-repeating movement pattern that always ends up where the PM gun didn't expect, for a certain bullet flight time. That would probably work decently as well, but again probably not the greatest, and again probably couldn't fit into Cannon as a microbot at the same time as it's normal movement. Basically.... I think there are ways of avoiding PM better than random movement and better than a GF-surfer at that, however I don't think any would fit into Cannon. --Rednaxela 04:51, 13 October 2009 (UTC)

I made a lot of researches about anti-pm in nanos, and I managed to make a nano sized AntiPM bot. It's actually a reversed symbolic pm gun, so it matches it's own movement and tries to avoid being hit by itself. ;) It was about the size of a pm gun so I stopped experimenting with it, but I think this idea can be improved a lot. If you are interested in the code check out here: [1] ;) -Note: Try it against top pm nanos, because it tries to avoid the gun they have. Due to lazyness it matches only velocity, so this could be improved a lot. As you will notice, it needs 3-4 rounds to 'burn in'. --HUNRobar 16:17, 13 October 2009 (UTC)

Distancing

Sometimes Cannon takes too long to get to the optimal distance (currently 165), causing it to be hit quite often. Any suggestions? --Starrynte 02:38, 14 October 2009 (UTC)

Hmm... Well the first thing to come to mind would be increasing the approach angle--CrazyBassoonist 02:45, 14 October 2009 (UTC)

Well, you just approach at a steeper angle. The only catch is that at a steeper angle you have a greater risk of being hit. It's a tradeoff really. One other important thing to consider, is that at the very start of the battle gun heat is high so you have plenty of time to move to the desired distance, directly even if you want. --Rednaxela 02:47, 14 October 2009 (UTC)

Only thing I have to add is that 165 is a really close distance. It may in fact be optimal for your bot, but I'd definitely try experimenting with some longer distances, too. --Voidious 02:56, 14 October 2009 (UTC)

• The trouble about farther than about 250 is that it often gets caught in corners, but I'll experiment --Starrynte 04:23, 14 October 2009 (UTC)

• Caught in corners? Most megabots use a distance more like 400 and don't get caught in corners. Are you going without wallsmoothing? If not, perhaps the wallsmoothing is not smoothing enough? --Rednaxela 05:13, 14 October 2009 (UTC)

• Everytime you have to change direction because of the wall, turn slightly (extra) towards your opponent. That way you keep out of the corners, except against rammers. I don't think wallsmoothing will fit in a micro anyway. --GrubbmGait 07:52, 14 October 2009 (UTC)