User:Nat/WaveSurfingQuestion

Hi all, I have some questions about wave surfing.

First, define some term I'll use in this question:

• Surfer: all those surfer around today.
• Wave Surfer: a surfer that log hit for every waves.
• Hit Surfer: a surfer that log hit on only hit waves.
• log hit: the operation that same as BasicSurfer's logHit function.

Question 1

What is the differnce between Wave Surfer and Hit Surfer? On first time I looked into surfing, the statement I found is "Surfing is exactly reverse of GuessFactor Targeting" so I understand surfer as Wave Surfer. But, when I looked into code of DussGT, Dookious, Horizona and PhonixOS, I found out that they are Hit Surfer (unless it enable its flattener which turn them into Wave Surfer). Only Butterfly I've recognize that it's Wave Surfer.

I'm asking this because I'm working on BlackHole flattener. BlackHole is wave surfer so I can't use those bot flattener style. I think that Butterfly does not have flattener.

• Well, I know of NO surfer that logs non-hitting waves EXCEPT for flattener purporses. Bufferfly is included in this statement. As far as terminology, the "Wave" in "Wave Surfer" traditionally doesn't refer to the capture of the data, it refers to how you generate the movement from the stats. "Wave Surfing" is any movement which has a movement that attempts to get to specific 'low danger' guessfactors as the wave passes, and by this definition does not specify whether 'low danger' is determined by hits or flattening stats, or even patternmatcher simulation. As far as the difference between surfing that logs hits verses logs one that logs non-hits equally? The difference is exactly the difference between a bullet-dodger and movement-flattener. That answer the question? --Rednaxela 04:14, 22 February 2009 (UTC)
• Really? If that so, the statement on WaveSurfing/Tutorial should be wrong. It say like above. So now, my BlackHole will act like it always enabled its flattener, right? I am first confused by BasicSurfer code since it does not do exactly like reverse GF so I change that :) » Nat | Talk » 11:02, 22 February 2009 (UTC)

• Yep really. I'm not sure what you mean by "does not do exactly like reverse GF". --Rednaxela 17:47, 22 February 2009 (UTC)

Question 2

How can I create a gradient color for wave like Phoenix does? My style of BlackHole are a bit ugly... :(

• You have to do math and work with the java.awt.Color class. For example

Color ranbow = Color.getHSBColor(somenumber, 1, 1);
Color gradient = new Color(255, somenumber*255, 255-somenumber*255);

I suggest you experiment perhaps :) --Rednaxela 04:27, 22 February 2009 (UTC)

• Whoop! I forgot about HSB! I've try your second way many times but I result in really bad color :( Thanks » Nat | Talk » 11:02, 22 February 2009 (UTC)

Question 3

What will act faster and less memory consume?

• Multiple buffers VCS stats with 16 segmentation.
• One Kd-Tree but difference dimension calculator.

My new BlackHole v1 (not v2) will have around 1000 buffers and up to 16 segmentations. I ask here to develop my robot in right way.

• Compared to about 1000 VCS buffers? Definitely the Kd-Tree in that case. You could also consider an "interpolated VCS" approach like I explore in User:Rednaxela/SaphireEdge, it's rarther non-traditional but I got it working quite strong, and I think it's better in both memory and cpu requirements than many VCS buffers or a Kd-Tree. --Rednaxela 04:58, 22 February 2009 (UTC)
• Can you explain more? I currently not understand every thing you talk about :( » Nat | Talk » 11:02, 22 February 2009 (UTC)

• What part do you want me to explain more? The interplated VCS thing? Also the statement "By default, a DC bot will slower but less memory consume, VCS usually faster but much more memory consume." on your page isn't really correct. A kd tree will not be faster than a small number of VCS buffers, only faster than a very large number. And as far as memory consumption whie the DC uses less at the very very start of the battle it can grow larger than memory use of a small number of VCS buffers in as short as one or two rounds. --Rednaxela 17:47, 22 February 2009 (UTC)

Question 4

What is the simple way to calculate bot width for surfing? DurssGT style is complicated. I'm now create 25px circle and calculate each bins it covered.

• The simple way? The 'simple' angular botwidth is just 2*arctan(18px/distance), convert to GF etc as you wish. Btw, "DrussGT style" was first used by Garm, then independtly rediscovered in RougeDC (I made some explaination [1] here), and then added in DrussGT. Other than those three however, EVERY bot I know essentially uses something like 2*arctan(18px/distance). Note, 36px is the width of the collision square of the bot. --Rednaxela 04:58, 22 February 2009 (UTC)
• Is you formula return a radians? My way is as simple as you can think without any knowledge on trig :) I project current bot position front and back by 25px (the distance from center to corner of bot) and convert it to GF using BasicSurfer's getFactorIndex() function. Using these as covered GF. Much simpler. Or you have any more ideas? » Nat | Talk » 11:02, 22 February 2009 (UTC)

• Yep, that formula returns a value in radians. As far as the trig: Picture a right-angle triangle, the right angle is on the far side from you and you want to calculate the angle: The line from the measured angle to the right angle is called 'adjacent', and the one far from the measured angle is called the 'opposite', and arctan works like this: "radianangle = arctan(opposite / adjacent)" by definition. But anyways, the getFactorIndex() approach isn't really simpler than the 2*arctan(18/distance) approach in terms of quantity of code it takes, and it's also a bit slower for the computer. Really, they'd give the exact same final result, except that the arctan method has less redundant calculation. In any case though, the getFactorIndex() approach is perfectly fine. I would however suggest that when calculating the covered gfs for any purpose except surfing, not using 25px, because often the actual width is considerably less and I think that only in surfing is it best to err on the large side. --Rednaxela 17:47, 22 February 2009 (UTC)

Question 5

What is better:

• Surf the wave until it pass rear edge of the robot.
• Surf the wave until it pass middle of the robot.
• Surf the wave until it reach front edge of the robot.

• Well, ideally, you use a mix. What I do in RougeDC, is I use the crazy precice botwidth calcuation, and as the wave passes through the bot, I set guessfactors that already would have already hit the bot to 0 danger, and keep surfing the remaining parts of the wave that aren't zero'ed out. If you're not using that kind of fancy botwidth though, I'd suggest near the middle, maybe leaning towards the front. --Rednaxela 06:01, 22 February 2009 (UTC)
• Is that? I sometimes found that my robot stop at position that will not be hit by bullets, but when the the wave passed the center, it move again and finally hit! so I not sure. But that a good ideas, I'll try it out... » Nat | Talk » 11:02, 22 February 2009 (UTC)

• Well, that can happen, however usually if the bot is so close to a bullet that it would move onto it sideways, then it didn't really have a good idea where it was to begin with. Also, consider this: If you surf until it reaches the rear edge, then your bot may not get the front edge out of the way in time. I don't know any bots that do this, but one solution to make this situation better without using fancy botwidth calculations, is to when the wave is far away, only consider how far the bot can move till the wave hits the front, BUT once the wave begins to intersect the bot, start making calcuations with regards to when it would pass the rear edge. --Rednaxela 17:47, 22 February 2009 (UTC)