Editing revision 160 of Simonton/DCGTResearch

Robo Home | Changes | Preferences | AllPages

Editing old revision 160. Saving this page will replace the latest revision with this text.

My next experiment: goto path surfing.  <strike>It works by choosing (currently) 31 impact points on each wave, spread out across GF -1 to 1, then plotting the path through them with the least sum of the dangers.</strike>  It currently works like this, which will become more sophisticated with time:
* For each [[Wave]] choose 31 GuessFactors, spread out across GFs -1 to 1, being sure to include local minimum danger points.
* To find the best path from a given point:
** Find the next wave to strike that point.
** Find the points on that wave that meet the 31 chosen GFs AND could be reached from this point along the path of maximum escape.
** Recurse to find the danger of each of those points.
** Choose the point with the least danger.
** Add in the danger of this point, add this point to the best path so far, and return.
So far there's very humble beginnings:

See old results at /DCGTResearchArchive

'''[[MovementChallenge2K7/ResultsFastLearning|MC2K7 Fast Learning Results]]'''

| '''Bot Name''' | '''Author''' | '''Type''' | '''HOF''' | '''SPL''' | '''GRG''' | '''Sub 1''' | '''WAY (Sub 2)''' | '''GR3''' | '''RKM''' | '''Sub 3''' | '''ASC''' | '''CC''' | '''CHK''' | '''Sub 4''' | '''Total''' | '''Comments'''
| 0038 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.23 | 85.89 | 86.57 | '''90.56''' | '''62.90''' | 53.18 | 68.64 | '''60.91''' | 34.39 | 42.98 | 40.12 | '''39.16''' | '''63.38''' | 90.0 seasons
| 0039 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.75 | 85.78 | 87.29 | '''90.94''' | '''64.62''' | 53.05 | 69.49 | '''61.27''' | 34.71 | 40.46 | 39.79 | '''38.32''' | '''63.79''' | 90.0 seasons
| 0040 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.75 | 85.90 | 86.73 | '''90.79''' | '''65.18''' | 52.27 | 70.25 | '''61.26''' | 34.24 | 41.26 | 39.97 | '''38.49''' | '''63.93''' | 78.8 seasons
| 0043 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.79 | 86.22 | 86.52 | '''90.84''' | '''64.50''' | 58.29 | 69.33 | '''63.81''' | 35.01 | 42.12 | 38.60 | '''38.58''' | '''64.43''' | 90.0 seasons
| 0044 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.73 | 85.94 | 87.65 | '''91.11''' | '''62.40''' | 51.78 | 68.58 | '''60.18''' | 34.67 | 41.63 | 41.56 | '''39.29''' | '''63.24''' | 83.9 seasons
| 0045 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.81 | 85.86 | 86.95 | '''90.87''' | '''64.27''' | 54.76 | 67.83 | '''61.30''' | 35.02 | 42.20 | 38.85 | '''38.69''' | '''63.78''' | 75.0 seasons
| 0046 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.54 | 87.36 | 89.06 | '''91.99''' | '''63.60''' | 55.20 | 70.14 | '''62.67''' | 33.75 | 41.25 | 39.07 | '''38.02''' | '''64.07''' | 75.0 seasons
| 0047 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.69 | 87.79 | 88.84 | '''92.11''' | '''65.00''' | 55.51 | 71.39 | '''63.45''' | 33.42 | 41.14 | 39.05 | '''37.87''' | '''64.61''' | 75.0 seasons
| 0048 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.65 | 86.84 | 87.68 | '''91.39''' | '''63.82''' | 58.86 | 68.81 | '''63.83''' | 34.65 | 41.52 | 38.23 | '''38.13''' | '''64.29''' | 75.0 seasons
| 0050 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.67 | 87.82 | 89.03 | '''92.17''' | '''63.19''' | 57.96 | 72.58 | '''65.27''' | 33.19 | 40.94 | 39.39 | '''37.84''' | '''64.62''' | 75.0 seasons
| 0051 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.73 | 86.94 | 88.40 | '''91.69''' | '''62.81''' | 60.33 | 70.47 | '''65.40''' | 34.12 | 41.34 | 38.56 | '''38.01''' | '''64.48''' | 75.0 seasons
| 0052 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.70 | 87.79 | 89.77 | '''92.42''' | '''61.73''' | 57.98 | 72.82 | '''65.40''' | 30.41 | 41.93 | 39.99 | '''37.44''' | '''64.25''' | 75.0 seasons
| 0053 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.71 | 87.95 | 88.69 | '''92.12''' | '''62.85''' | 58.24 | 72.11 | '''65.18''' | 33.68 | 41.07 | 40.03 | '''38.26''' | '''64.60''' | 75.0 seasons
| 0054 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.64 | 87.66 | 89.17 | '''92.15''' | '''63.04''' | 60.42 | 72.20 | '''66.31''' | 33.01 | 41.69 | 39.29 | '''38.00''' | '''64.88''' | 75.0 seasons
| 0056 | [[Simonton]] | [[WaveSurfing|WS]]-[[WaveSurfing/GoToStyle|GT]]-[[WaveSurfing/PathFinding|PF]]/[[DynamicClustering|DC]] | 99.72 | 86.65 | 87.72 | '''91.37''' | '''61.41''' | 60.22 | 71.07 | '''65.64''' | 31.93 | 38.37 | 37.65 | '''35.98''' | '''63.60''' | 75.0 seasons
|separator
| [[Dookius]] 1.554 | [[Voidious]] | WS | 99.94 | 86.40 | 94.21 | '''93.52''' | '''69.50''' | 69.35 | 84.08 | '''76.71''' | 40.07 | 53.17 | 51.71 | '''48.32''' | '''72.01''' | 21 seasons 
| DrussGT 0.3.1 | [[Skilgannon]] | [[WaveSurfing/GoToStyle|WS-GT]] | 99.71 | 87.20 | 93.90 | '''93.60''' | '''66.62''' | 66.47 | 81.19 | '''73.83''' | 28.48 | 42.71 | 45.58 | '''38.92''' | '''68.24''' | 22 seasons
| [[Firebird]] 0.1 | [[David Alves]] | DC WS | 99.88 | 87.01 | 86.72 | '''91.21''' | '''67.16''' | 64.53 | 77.10 | '''70.82''' | 30.02 | 42.54 | 42.16 | '''38.24''' | '''66.85''' | 100.0 seasons
| [[DrussGT]] w/<br>my "segments" | [[Skilgannon]] | WS-GT | 99.99 | 83.56 | 84.96 | '''89.50''' | '''65.03''' | 69.14 | 76.01 | '''72.57''' | 29.08 | 38.64 | 43.65 | '''37.12''' | '''66.06''' | 20.8 seasons
| '''Bot Name''' | '''Author''' | '''Type''' | '''HOF''' | '''SPL''' | '''GRG''' | '''Sub 1''' | '''WAY (Sub 2)''' | '''GR3''' | '''RKM''' | '''Sub 3''' | '''ASC''' | '''CC''' | '''CHK''' | '''Sub 4''' | '''Total''' | '''Comments'''

'''[[MovementChallenge2K7/Results|MC2K7 Results]]'''

* '''0038:''' Considers points on a wave that it must drive ''through'' to reach (without coming to a stop).
* '''0039:''' Add back DiveProtection again.
* '''0040:''' 0038 with added danger for taking up more GFs (i.e. being closer), instead of explicit DiveProtection.
* '''0043:''' 0041, fixed back to the danger calculation I've been using.
* '''0044:''' 0042, fixed back to the danger calculation I've been using.
* '''0045:''' Putting together features of 0039 (DiveProtection), 0043 (distancing) & 0044 (harmless EnergyDrop wave)
* '''0046:''' Finally found a couple of those off-by-one errors [[Skilgannon]] has been figuring I have!  0038 with those (hopefull?) fixed.  Thanks to [[Rednaxela]] for the conversation that prompted me to look for these.
* '''0047:''' 0046 with DiveProtection (0039 w/out the off-by-one bugs)
* '''0048:''' 0046 with angle-based distancing (0043 w/out the off-by-one bugs)
* '''0050:''' 0046 w/ speed optimization/bugfix: only recaclulate the path when something changes.  Recalculating every tick threw off predictions for any destination generation that depended on distance.
* '''0051:''' angle-based distancing
* '''0052:''' 0050 but travels perpendicular to the line (wave origin, point on last wave), rather than the line for GF0.
* '''0053:''' 0050 but don't turn toward the next destination when there will be enough time to do so later.
* '''0054:''' 1) Don't fire an enemy wave the same tick as a collision (it's complicated to figure out if you should, and you can't surf a wave that close anyway). 2) Don't turn toward the "retreat point" when sitting still waiting for the energy drop wave (since no real waves are in the air), to avoid having to turn right back to perpendicular once he fires.
* '''0055:''' <strike>Linearly normalize wave dangers to 0-1.  This will give much higher danger to "clumped" waves than those spread out.</strike> on second thought, it will be no different.
* '''0056:''' Normalize dangers to 0-1 by taking danger from nearest logged gf.  This will give no higher to "clumped" waves.
* '''0057:''' Accellerates before pointing straight at its destination.
----

And I thought "WS-GT/DC" was bad. =) -- [[AaronR]]
* =) -- [[Simonton]]

Surely you would want your points to be between GFs -1 to 1? Otherwise you never get to a negative GF... -- [[Skilgannon]]
* Heh.  Good eyes.  At least I got it right in my code ... ''(fixed above)'' -- [[Simonton]]

Not to be an organization freak, but why not put this under [[Simonton/DCGTResearch]], like [[Simonton/DCResearch]]? A subpage of WaveSurfing seems a little general for somebody's specific development stuff. I can rename it for you if you agree. =) -- [[Voidious]]
* Ha!  That's exactly where it was supposed to go.  Sorry.  Umm ... I don't know how to rename, so please do.  -- [[Simonton]]
* Thank you! -- [[Simonton]]

Wow, those acronyms are getting out of control. --[[David Alves]]
* :) Yeah, I'm thinking of just making a page for GotoPathSurfing, and defining it there.  -- [[Simonton]]

0014 is '''not''' done - is has a lot of bugs (or maybe just one big one?) and is in serious need of speed optimization.  I skips turns pretty badly on a CPU constant of 100.  BUT, it looks like it could actually be paying off.  It just went 100 rounds against HawkOnFire MC2K7 without getting hit once. -- [[Simonton]]
* Are you caching the bins for each wave? That would be way faster than re-generating from the DC each tick. -- [[Skilgannon]]
* Yup.  But what are you trying to say about my tree??  Huh? -- [[Simonton]]
* Your tree may be fast, but caching is faster. =) Do you know where the CPU cycles are being eaten up? I'm always wary of trig... -- [[Skilgannon]]
* Yeah, it's in the trig.  I should be able to cut it in about 1/3 by evaluating points from the starting position outward, then stopping as soon as a point on a wave is unreachable (since any points past that will certainly also be unreachable).  And there's probably a <code>sqrt</code> and/or <code>sin</code> in those loops I could get rid of.  But all that can wait until the thing actually '''works''' first. -- [[Simonton]]
* I just implemented surfing the second wave in DrussGT, and I thought up a useful speed optimization: check whether the points are reachable, from the outside in, using a simple (non-trig) distance based method. Once you find a point that is theoretically reachable, you use the trig method to see if it's actually possible. And, once you find a reachable point, you don't have to check whether they're reachable any more. -- [[Skilgannon]]
* Yeah, that sounds great ... except I need to know exactly ''when'' I'll reach that point.  So I can't skip that part of the precise prediction.  And since I can't skip it, it makes more sense for me to evaluate from the inside out, stopping when a point becomes unreachable.  I only use trig for the precise prediction until I'm pointed in the right direction, though, at which time I switch to just a distance based method.  -- [[Simonton]]
* I created a PlaceTime object, place is point, time is time when the wave would hit it. I'll put up my code for the reachable() method now.. -- [[Skilgannon]]
* Oh, and the hitTime for a position is <code>((surfWave.fireLocation.distance(testPosition) - surfWave.distanceTraveled - surfWave.bulletVelocity)/surfWave.bulletVelocity) + getTime()</code>. I always work with absolute times, so much easier =) -- [[Skilgannon]]

Grrrr.  Well I know 0015 still has bugs, but I still thought it would be the best version so far.  I know WaveSuffuring is the common experience, but this is getting out of hand.  I have an idea how to throw off [[Waylander]] - maybe I'll do that now just to see my score go up & make myself feel better :/.-- [[Simonton]]
* It's your best score against GRG so far - and by a margin! To me that means that you did ''something'' right, even if it didn't pay off across the board. And what about doing those optimizations? They'll speed up your testing, if nothing else. Sometimes I run across bugs when I'm trying to optimize for speed ( DrussGT is fast for a reason!) ...you never know! -- [[Skilgannon]]

Ouch! I'm guessing it's your wave times, probably a tick or two off. But how about a test version that only surfs the first wave? -- [[Skilgannon]]
* Yeah, wave times were 1 off and I was using getBullet() instead of getHitBullet() in the onBulletHitBullet handler, so there were a lot of hits that couldn't be matched to waves.  It's looking much better now.  Here's some preliminary results. -- [[Simonton]]

* Another bug is probably in segmentation, from looking at your score against RaikoMicro, Ascendant, etc. -- [[Skilgannon]]
* Ah, looks like it just needed to stabilize a bit.  No bugs left in the refactoring ... just the ones that were already there ... -- [[Simonton]]
** You we're just telling me never to claim there we're no more bugs. tsk tsk --[[Chase-san]]
** Heh.  It's true. -- [[Simonton]]
* Oh wait - never mind me - I just woke up from a nap.  Yeah, nothing changed with more battles.  -- [[Simonton]]

Well, I just found one, disappointing bug.  My "precise" prediction was being smarter than Robocode.  If your bot is traveling at a speed of 3 and you tell it to move 1.1 pixels forward, my code assumed you would travel at a speed of 1.1 and arrive at your destination next tick.  Robocode, however decides you should travel at a speed of 1, then travel at a speed of 0.1 to arrive at your destination in 2 ticks.  -- [[Simonton]]
* Hmm ... on a "positive" note, it did accurately predict that if you are traveling at a speed of 8 and tell your bot to go forward 14.883138, it would (needlessly) overshoot that destination by 0.116862, then spend an extra turn backing up to arrive where you asked it to.  Maybe down the road, if this pathfinding thing ever takes off, I'll write some driving code that will trick robocode into making better decisions. -- [[Simonton]]

Does that 0.1 pixels really make a difference? I mean, how many pixels are between each point on the wave that you're checking? And feel free to try my reachable() method, it's free code =) -- [[Skilgannon]]

It's not the .1 pixel that concerns me as much as the 1 tick.  There's 2 buggy behaviors I'm trying to fix right now: 1) It adjusts its path mid-flight when the enemy has not just fired a new wave and a bullet of the enemy's has not been discovered.  This means it is not accurately predicting its own future movement: some points become "reachable" that it previously thought were not and vice versa.  2) Well ... I'm kinda hoping fixing number 1 fixes this one too ... it's kinda hard to explain.  It oscillates sometimes, which it should not do.  But anyway, again, your reachable method does not tell at what time you'll reach a given destination - only whether you can reach it, which my surfing requires.  Anyway, after those two bugs it looks like that method is working well.  But - the hunt continues.  -- [[Simonton]]

That clustering bug is a bit embarrassing.  0018 shows a stronger performance, though it is still far, far from being considered a good surfer.  However, I actually don't know of any more bugs!  Which is amazing and exciting - I can actually start thinking about improving it again!  I think the best next step is to get it to consider running through waves rather stopping at each one, but that's a step I'm not yet ready to take.  Too complicated.  Whatever is next, I need to do some execution speed optimizations first (5 minutes for one battle is not acceptable).  -- [[Simonton]]

So it was that clustering bug that was causing you to change directions sometimes? Makes sense that it would, if it keeps thinking different parts of the wave are dangerous. -- [[Skilgannon]]

No, the clustering bug didn't do that (it would pull the same "arbitrary" cluster every time).  It was just those 2 predictor bugs.  I still thought there were more because I didn't notice bullet collisions when I saw the path change.  I realized that was happening, made it paint a more obvious clue, then everything seemed solid.  So the bug was in the tester :).  -- [[Simonton]]

Above 60! Progress! =) --[[David Alves]]

I'm surprised OnDeath handling increased my score consistently against the top bots, by an average of more that 1%, but didn't help my score against Raiko at all.  Any theories? -- [[Simonton]]

Yeah, interesting. Maybe it's because Raiko learns so slowly compared to the others. What percentage of battles do you lose to Raiko? Are you ready to add some other attributes, like distance, and time-since-decel? And that rambot score doesn't look very healthy. Are you moveing at all when there aren't any bullets in the air? That helps a lot against those pesky rambots. -- [[Skilgannon]]

My scores are low in general because I'm still stoping at every wave.  The rambot score dropped when I added EnergyDropSurfing, so that I'm always trying to move perpendicular (before when there were no waves I retreated).  Those things are not my concern right now.  They will be fixed eventually.  But no, I'm not ready to add other attributes yet, I'm still working on the surfing system itself, and I want to keep a consistent benchmark for it. -- [[Simonton]]

DrussGT (and Stormrider) also stop at each wave, so that isn't the problem. Actually they don't stop, but they have a max speed of 2 as the wave passes over them. If there's anything lacking in your surfing, my guess is the points generation. -- [[Skilgannon]]
* Well, it's worse than that.  It stops at each wave, then if it needs to turn more than 10 degrees toward the next point it does so before moving again.  Considering there's also no wall smoothing, this makes for some very slow near-wall behavior (stop, turn 90 degrees to move along the wall, go, stop, go, stop, turn 90 degrees to come back off the wall).  There's also no distance control; it tends to just always retreat.  This gets it cornered, then, once near a corner, it takes extra time to turn along the walls to try to escape (so usually it decides not to, but just stays near the corner).  Last night I finally started working on these issues, since I've already accomplished most everything else.  But there's still a long road ahead.  But anyway with a max speed of 0, let's see, 8+6+4+2+0+1+2+3+4+5+6+7+8=56, and the same number of tick with a max speed of 2, 8+6+4+2+3+4+5+6+7+8+8+8+8=77.  That's up to 22 more pixels of escape per wave, asuming you don't have to change directions too much.  -- [[Simonton]]

A couple thoughts: 
* OnDeath doesn't help vs Raiko: First, the obvious - you lose less rounds to [[Raiko]], so proper onDeath has less benefit. There is also the question of what power bullets each reference bot fires you when you're low on energy, which might even depend on how much energy ''they'' still have at that point, which would depend on how well you do against that bot; if a 0.1 power bullet is the onDeath bullet each time, that probably isn't as valuable to your surf data as something closer to normal bullet power (1.9 or whatever). Actually, I don't remember what firepower each reference bot is using, but it's still a factor. I wouldn't fret it too much - lots of little things like proper onDeath should add up to an overall gain, but some are such small tweaks that it's just tough to measure reliably.
* Stopping at each wave in DrussGT / DCGTResearch: If there's one thing I've learned about WaveSurfing, it's that a WaveSurfing movement is a ''very'' complex system, where each part affects every other part. Just because DrussGT does well with a max speed of 2 when the wave passes doesn't mean that stopping at each wave isn't greatly hindering DCGTResearch's performance. Often, I have tried to tweak some feature that has been in my surfing a long time and anything I do to it makes it perform worse. "How can this be?", I ask myself, "I just picked that number/setting/behavior intuitively when I first did it - it couldn't be perfectly tweaked!" I'm convinced that you end up tweaking other things ''around'' some stuff like that, and then those later tweaks are dependent on the initial (arbitrary) behavior.

-- [[Voidious]]

Hmm ... but if the bot you're up against doesn't segment on bullet power, doesn't it still give you the same information about his targeting?  I suppose my movement is going to be slowed down a lot with waves crashing over me more frequently, which could easily land me in different segments in the enemy's aiming stats.  As a side note, "DCGTResearch" is just too much of a mouthful.  Feel free to just say "Simonton's movement" or something.  -- [[Simonton]]

* Umm, you're right.. what the heck was I thinking? I guess I was thinking that GuessFactor data doesn't always translate exactly across different bullet powers, but that's a much different issue in movement than in a gun. -- [[Voidious]]

----

Well, it happened.  I'm back.  Not sure for how long, but I'm back.  :)  -- [[Simonton]]

Nice to see you back Oh Inspiring Methodical One. :) What I've been wondering is.. when will we see some killer bot result from your intensive movement/targeting research? I'm looking forward to it! :) -- [[Rednaxela]]

Funny, that's exactly what I wonder!!  lol . -- [[Simonton]]

I'd be interested to see what you get if you only surf the first wave (as a test). Might be revealing... -- [[Skilgannon]]

* The first 2 waves would be doable, but to only surf the first would waste time turning after that the wave crashes, whereas now it starts turning toward the destination on the next wave while waiting for the first to crash (assuming it has time).  -- [[Simonton]]

----

Nice improvement! I'm guessing your surfing has been a tick off the whole time. -- [[Skilgannon]]

Thanks!  0036 is definitely an improvement (don't put too much stock in those scores from 0035 at only 5 fast-learning seasons).  But no, the bugfix had nothing to do with being one off.  It allowed me to reach another possible point (or two?) on each wave, increasing my options and escape angle.  Hopefully 0037 proves just as fruitful again, by further optimizing the same braking behavior!  This all seems rather detailed to be developing when there are so much more important things, but never fear, it's all in preparation for what I hope will be a very big improvement: consider not stoping on each wave.  Similarly, consider turning without slowing down.  And I think I have everything in place to accomplish it now!  Watch out!  -- [[Simonton]]

Wow, looking over it again, 0036 improved against '''every single bot''' compared to 0034 in the fast learning!  Against all but one bot in the long-learning, too!  That's amazing!  Er, ehem, I mean ... just as I expected ... -- [[Simonton]]
* Well, it was definitely an improvement, but not as dramatic as I was hoping :(.  On the other hand, there are lots of things to play with now that the big obstacles are over.  I should find enough more speed optimizations to run on a normal CPU constant & try this out in the rumble sometime.  -- [[Simonton]]

It's a nice feeling when things go nicely like that regardless of if it's how you're expecting ;-) Glad you're having better luck with this than I am with improving [[Polylunar]] results against [[X2|Xmen]]. Things I expect to improve results, like replacing the antigrav with minrisk just aren't working at all right for some reason. Hope your surfing scores keeping going up :-) -- [[Rednaxela]]

Thank you.  Minrisk is really tricky in my experience.  I have toyed with a [[Melee]] MicroBot in the past, but I could never tune a minrisk movement that could even do as well as MeleeSeed's simple, nano-sized corner movement!  -- [[Simonton]]

Well, as one can [http://rumble.fervir.com/rumble/Rankings?version=1&game=minimeleerumble see], my experiment in minrisk, <nowiki>MiniSurreptitious</nowiki> (which could probably become Micro if I wanted, and has nothing but a HOF gun), didn't go so bad though not great either. In any case I found the main issues I was having integrating it into [[Polylunar]] which were rather stupid mistakes on my part. Not sure if fixing that made it better than the antigrav though, but for the moment, I'm working on other aspects of [[Polylunar]]'s movement first. Also, MeleeSeed has a plain awesome nano-corner-movement! :-) -- [[Rednaxela]]

Ah yes, that must not be a bad movement at all!  Right on par with [[Shiz]].  Very nice.  With my gun and your movement, we could rule the mini throne!  (Sprout is a micro, all gun, with extras just because I had room).  -- [[Simonton]]

Well, I'm note sure we'd rule that much with that combo, at least with <nowiki>MiniSurreptitious's movement</nowiki>, because firstly it's worse than [[HawkOnFire]] while being quite conceptually similar, and secondly [[Coriantumr]] has both a rather good gun and rather good movement at once. Maybe if <nowiki>MiniSurreptitious</nowiki> tops [[HawkOnFire]] while still being shrinkable to micro, we'd have a chance at top mini though... I do have some ideas to improve <nowiki>MiniSurreptitious</nowiki> substantially, however they might make micro-sizing it difficult without help of a Master Codesize Wizard. In any case though, I've given up on working on melee until the widespread details file corruption in the melee rumble is fixed. It just makes it too slow to run the melee rumble. How about this though: If the melee rumble is fixed, once I get <nowiki>MiniSurreptitious</nowiki> to top HOF, we try a <nowiki>wiki.SurreptitiousSprout</nowiki> bot and rule the world! ;-) -- [[Rednaxela]]

It's a deal!  And I don't mean to brag, but I do consider myself pretty handy with codesize reduction ... -- [[Simonton]]

I wouldn't call it bragging really. After all, I seem to recall others reputable sources around here praising your codesize reduction abilities... :-) -- [[Rednaxela]]

Heh, I fully agree, me and [[Simonton]] have very different methods for codesize reduction. I tend to refine my ideas so that I only keep the bare necessities in, whereas he manages to keep full functionality, and just squishes it all together with shared variables, splitting off static functions, changing variable types etc. If I have code to shrink I'll finish with something that acts slightly differently, but (hopefully) retains the important stuff. I might be micro-king, but [[Simonton]] is the master codesize-reducer =) Much can be learned from studying his bots =) -- [[Skilgannon]]

And in the other extreme, I am awfully attached to my MegaBot-style utility classes like <nowiki>"AbsolutePoint" and "RelativePoint"</nowiki>, and use of <nowiki>StatusEvent</nowiki>, both of which cause very large codesize compared to what would be called sane design in a codesize restricted environment :-) -- [[Rednaxela]]

Back to the topic of this page: Very nice improvments in 38 and 39! This is certainly on it's way to being a great movement! -- [[Rednaxela]]
* With 38: thanks!  With 39: I wouldn't call this an improvement.  It helped against HawkOnFire and [[Waylander]], but hurt the rest of my scores.  I consider that a net loss (though I do understand the importance of dodging HOT very well).  Let's see if factoring distance into dangers is better or worse. -- [[Simonton]]
* Nope - looks like it was even worse!  Hmm ... I wonder what to try next.  -- [[Simonton]]
* I'm glad I didn't make any developments recently, because that allowed me to run more seansons & find out that 0039 & 0040 were BOTH improvements over 0038.  I guess 30 seasons is not reliable data!  Hopefully 80-90 is.  Also, note that doing worse against the top bots is no problem with these tweaks.  If I get further away from them gun strength plays a bigger role (when close up anybody could hit them once in a while), and they have me out-gunned.  When I hit the rumble, I will have a gun at least on-par with theirs :).  Ah!  Now I just remembered one of my plans for this movement challenge: come up with a system that effectively measures my gun vs. theirs, & control my distancing accordingly!  -- [[Simonton]]
* Hmm, I'd be curious about change 41 ontop of 40 instead of ontop of 38, because that would create a distancing system conceptually similar to RougeDC (which seems to perform great against rammers for one thing). Nice work lately :-) -- [[Rednaxela]]

Summary:
Consciousness check: 4 * 6 =
This change is a minor edit. Send email notification that Simonton/DCGTResearch has been changed.
(Visit Preferences to set your user name.)

View other revisions
Robo Home | Simonton | Changes | Preferences | AllPages