GravityWave/Tests/Archive June182009

From Robowiki
< GravityWave‎ | Tests
Revision as of 01:32, 12 June 2009 by J Litewski (talk | contribs) (Added new entry)
Jump to navigation Jump to search

05:00, 7 June 2009 (UTC)

1st	hackhalotwo.GravityWave	17933 (81%)	13050	4860	0	0	23	0	486	14	0
2nd	mld.DustBunny 3.5	4344 (19%)	700	140	3319	157	28	0	14	486	0

I doubled the amount of BINS (from 42 to 84). That seemed to do a LOT of good. Other than that, I didn't change to much more.


17:42, 7 June 2009 (UTC)

1st	hackhalotwo.GravityWave	18004 (73%)	13050	4950	0	0	4	0	495	5	0
2nd	mld.DustBunny 3.8	6612 (27%)	250	50	6269	40	2	0	5	495	0

Really no changes besides fixing the wall smoothing buffer to be dynamic instead of static (i.e., it now uses getBattleFieldHeight() and getBattleFieldWidth() minus getHeight() and getWidth() (all as ints) for the wallSmoothing function instead of fixed variables. I also moved a lot of functions from GravityWave to Hh2_Utils, but that shouldn't of impacted the performance any, since it was just a copy and paste job.


03:17, 10 June 2009 (UTC)

1st	hackhalotwo.GravityWave	30167 (74%)	23900	4800	0	0	1366	102	480	20	0
2nd	mld.DustBunny 3.8	10368 (26%)	1000	200	8926	166	76	0	20	480	0

This is actually a glitch in my movement code that I thought was funny. I ran this test three times, trying to figure out why my bot was suddenly ramming DustBunny. Well, in my doSurfing() function, I was adding in some more movement code to make GravityWave move when there was no waves (since BasicSurfer doesn't have any such code). Well, I rounded my setTurnRight wrong, so instead of orbiting the enemy, it rammed him. I may keep this in, depending on the rules of the Movement Challenge 2K9.


05:01, 10 June 2009 (UTC)

1st	hackhalotwo.GravityWave	30215 (80%)	24600	4930	0	0	596	89	493	7	0
2nd	mld.DustBunny 3.8	7517 (20%)	350	70	7023	64	10	0	7	493	0

I hacked the doSurfing() function to accept two double inputs, eBearing and eEnergy, to extend my new ramming movement only after the Enemy's Energy is less than or equal to 0.0. That looked like it did some good. My next feat is adding in some distancing for my 'normal' movement, since if GravityWave gets within 400 pixels of DustBunny, DB rapes him :P.


19:05, 10 June 2009 (UTC)

1st	jam.RaikoMX 0.32	54784 (76%)	10650	2130	39674	2301	4	25	213	287	0
2nd	hackhalotwo.GravityWave	17506 (24%)	14250	2870	0	0	336	50	287	213	0

This is for fun, but I was surprised at the results. GravityWave outlasted RaikoMX over half the time! Of course, RaikoMX swept the floor with GW in score, but this proves that, from when I started tweaking GW, He has become harder to hit. Now it's off to work on implementing some sort of Bin Smoothing function and testing it against DustBunny 3.8.


04:19, 11 June 2009 (UTC)

1st	jam.RaikoMX 0.32	52184 (73%)	9350	1870	38938	2025	1	0	187	313	0
2nd	hackhalotwo.GravityWave	19159 (27%)	15600	3130	0	0	373	56	313	187	0

This is the test for my 2D Segmented BIN Array. It shows a slight improvement all around. I know it will do better if I went in and polished up the functions for the segmentation. I should test this against DustBunny 3.8...


22:02, 11 June 2009 (UTC) Match 1

1st	hackhalotwo.GravityWave	29546 (76%)	24000	4870	0	0	590	86	487	13	0
2nd	mld.DustBunny 3.8	9089 (24%)	650	130	8156	125	28	0	13	487	0

Match 2 (using the data from the end of Match 1)

1st	hackhalotwo.GravityWave	29696 (78%)	24150	4860	0	0	599	87	486	14	0
2nd	mld.DustBunny 3.8	8302 (22%)	700	140	7303	146	13	0	14	486	0

This is a test on the save/load functions and on the 2D Segmentation Array. Both are a success. I'm going to need to polish up the way it picks Danger, since that's not using the 2D Array to it's fullest.


00:32, 12 June 2009 (UTC)

1st	hackhalotwo.GravityWave	29948 (80%)	24350	4920	0	0	590	87	492	8	0
2nd	mld.DustBunny 3.8	7661 (20%)	400	80	7053	95	32	0	8	492	0

I added in a setMaxVelocity() for turning. Other than that and some slight tweaks to the segmentated Array to speed up the execution. After thinking about it, and while looking at the debug data, I noticed that there was a major bug in the distance Segment. The Segment is updated every turn. It should only be the distance when the bullet was fired, not the current distance. So I'm going to work on hacking the enemyWave class to take the distance Segment, then updating and re-polishing things.