Talk:Anti-Gravity Tutorial

I'm posting this in it's current form because it took me a lot longer to write than I thought it would, and I don't want to lose all of my work. I would appreciate any ways people could improve it; please go ahead and change anything you can! I'm not exactly a Robocode guru, and there's still stuff that needs to be added to this--CrazyBassoonist 02:38, 21 January 2010 (UTC)

One quick note, is I'm pretty sure the "check various angles" approach is very much not the traditional anti-grav approach, and is closer to min-risk movements actually. The 'traditional' anti-grav approach is simply summing up a 2d total force vector rather than checking angles. --Rednaxela 02:48, 21 January 2010 (UTC)

Yeah, it's actually a little simpler than what you have here. For each enemy, something like:

xForce += Math.sin(absBearing + Math.PI) / (distance * distance);
yForce += Math.cos(absBearing + Math.PI) / (distance * distance);

Then just move in the direction of the resulting force. Not to say that checking angles is wrong (or even likely to give a different result), but it's veering into min risk territory, and not traditional AG. --Voidious 15:57, 21 January 2010 (UTC)

Indeed, like that. In this case, checking angles gives a... similar result, except 1) less precise, and 2) rotates to a sane angle if the forces are *perfectly* blanced, but that's unlikely and normally non-issue anyway. If there are no objections soon I'll modify it to use the vector summing approach. As a side note, I'd also say that using a try/catch instead of an explicit null check is... disagreeable code style. --Rednaxela 16:17, 21 January 2010 (UTC)

Aye. It should be either like that or

xForce -= Math.sin(absBearing) / (distance * distance);
yForce -= Math.cos(absBearing) / (distance * distance);

And use Math.atan2(xForce, yForce) to get the direction of the result vector. --Nat Pavasant 16:31, 21 January 2010 (UTC)

In my thought a 'Tutorial' should involve creating a robot. I'll change it later when I have more time. --Nat Pavasant 14:14, 21 January 2010 (UTC)

I'm not sure everyone agrees (though I think that is a good style). When we discussed tutorial style on Category talk:Tutorials, it seemed most people preferred to have pseudocode tutorials, not the explicit bot building style I use in the Wave Surfing Tutorial. --Voidious 15:22, 21 January 2010 (UTC)

I am not really sure, but I for one only think of advanced tutorial at that time of discussion. I myself prefer pseudocode for advanced tutorial, and bot building for basic tutorial. I don't believe pseudocode is suitable in such situation -- it won't make more sense than just literal explanation. But for advanced techniques, sometimes you can't explain it with literal explanation, and giving the code is just spoil, so I prefer pseudocode. Any one agree with me on this? And since this article cover from data gathering, I consider this a 'basic' tutorial. --Nat Pavasant 15:46, 21 January 2010 (UTC)

Also: thanks for posting, that was pretty quick. =) --Voidious 15:57, 21 January 2010 (UTC)

One note about the enemy tracking this tutorial suggests: The approach it uses only really works when one is very certain that enemies will be scanned in the same order each time around. It can have significant anomalies with a non-spinning radar, and even with a spinning radar the order changing could cause the bot to move oddly every so often. I'd only consider using that type of approach in a highly codesize-restricted bot. Do others approve of changing it to a slightly more advanced system for tracking the enemy points without such issues? :) --Rednaxela 21:06, 21 January 2010 (UTC)

Well, thanks for correcting the page! About the enemy tracking, I did point out that it would only work with spinning radar, and would occasionally cause problems. I just used it because it's extremely simple, and making a decent enemy tracking system in melee can get awfully complex. But yes, I would support changing it if anyone else feels like it--CrazyBassoonist 22:05, 21 January 2010 (UTC)