Gwynfor

What's special about it?

Well, not too much really. It's my first bot that will go public. Pretty boring... so far...

Great, I want to try it. Where can I download it?

You'll have to wait for a moment, as I've yet to release it, but it should be out there shortly... just as soon as I get a decent movement.

How competitive is it?

Hard to say as it isn't in the RoboRumble yet, but currently it performs half-decent against mid-ranking bots, but gets slaughtered by the top bots. I hope for this to change with better movement because I have higher bullet damage despite lower score...

How does it move?

Currently? Pretty badly. What's that mean? Running into walls :)

How does it fire?

Currently uses a VirtualGuns array of CircularTargeting and GuessFactorTargeting with some inspiration from AutomatedSegmentation.

How does it dodge bullets?

Currently uses a variation of goto style wavesufing, that is broken in various ways.

How does the melee strategy differ from one-on-one strategy?

Well, not at all. It can handle storing stats for multiple enemies and dealing with everything, but I'm suspecting it'll likely skip turns alot in that case, and certainly wouldn't perform well. I'm only developing for one-on-one so far.

How does it select a target to attack/avoid in melee?

Targets the nearest known enemy. Not very smart, but again, not built for melee yet

What does it save between rounds and matches?

Currently it saves all GuessFactor data between rounds and matches. I plan to make it only save between rounds in the future to stop the data from overflowing

Where did you get the name?

Well, it's a Welsh name, which I felt represented my hopes for this bot sort-of. Kind of silly.

Can I use your code?

No, it's not released yet after all.

What's next for your robot?

Movement, movement, and more movement. After that's somewhat livable? I'm thinking about a NeuralPatternMatcher as well a little idea I cheekily call "Second Guessing".

Does it have any WhiteWhales?

All the top bots? :) I often test/lose against SilverSurfer, Shadow, and Dookious but I'm catching up, even if slowly.

What other robot(s) is it based on?

The code architecture is somewhat inspired by my old Mervin robot (see Rednaxela) but it's all new code.

Comments, questions, feedback:

Just WRT your hitting walls problem, you do have WallSmoothing implemented, don't you? -- Skilgannon

Nope, haven't implemented WallSmoothing, nor any other form of WallAvoidance (i.e. limiting goal guess factors via PrecisePrediction that accounts for walls). I do have a form of WallSmoothing planned for the new movement method I'm working on. At some point I may add PrecisePrediction and/or WallSmoothing to my goto style wavesufing, but for the moment I see more potential in a new movement that I've just started coding. -- Rednaxela

If you're doing a style of goto wavesurfing, it's fairly simple to 'warp' any points you are aiming at inside the field, so you don't hit the walls. But good luck for getting your wavesurfing working, and if my 'reachable' method will come useful for you goto-surfing (it's what both DrussGT and Stormrider use), feel free to use it. -- Skilgannon

Thanks, I'll keep that in mind. First though I'm going to to experiment with a hybrid/combination of AntiGravity Movement and True Surfing that I have some high hopes for. Hopefully this idea won't flop... :)

Hmm, after looking at more stuff on the wiki, I see a few have tried a combination of AntiGravityMovement and WaveSurfing before... however from what I see, everyone who's tried that combination before has failed to some extend or another. I wonder if this will be worth trying or not. -- Rednaxela

Well... after some work I got my AntiGravityMovement working, and wavesurfing (using "True Surfing" which moves to local minima on the movement profile instead of the global minima). It seems to surf as intended, however: 1) This surfing style doesn't seem as effective, and 2) I'm not having much success making a "Gravity Source" to do effective wallsmoothing. In particular it seems to get stuck in the corners where it's close to two walls at once. If anyone has any tips they're welcome of course. In the meantime I'll probably leave this code and go back to working the goto wavesurfing -- Rednaxela

I found that vector sum based movement didn't play well with the precision demands of surfing. Some of my movement styles are flagged as 'exclusive', and while using them I apply no other influences from walls, other robots, etc. I expect that there are ways to make them cooperate, but for now I don't. -- Martin
Yes, this is rather consistant with the issues I was seeing. For one, I was using a seperate "guess factor force" for each enemy wave, weighting closer waves higher, but even with the weighting, the summation of which way it wants to go for the total of the waves, often produced more danger than just considering the waves one at time (closest only) even. Currently, I'm quite unsure of what kind of movement I want to go for (i.e. True Surfing, GoTo Surfing) but hopefully I can come to some kind of conclusion soon. Or better yet, a unique and effective idea if I'm lucky. Very lucky... -- Rednaxela
Unless you are precise-predicting a final point, it is definitly better to weight later waves on an inverse-exponential function, for example pow(0.7,time-until-wave-arrival). If you plot the function you'll see that the later waves are hardly weighted at all. Even once you have precise-prediction it is still better to weight later waves much lower, simple because so many things can change before the later waves arrive (new waves fired, enemy orbited more to one side, stats changed, etc). -- Skilgannon
Yeah, I think most of us weight the non-closest waves pretty lightly. I weight them by (1/time-to-impact) or (1/square(time-to-impact)) (that one's most common, I think), though I can't remember now how I concluded when to do which... Still, if even 1 in 100 situations makes two movement options seem almost exactly equal based on just the first wave, using the data for the second wave to break the tie is a very good idea. -- Voidious
Ahh yeah, that sort of weighting is probably good. I was using 1/time-to-impact though in my AntiGravityMovement/TrueSurfing method though, and it didn't seem to do too great. Even if I removed my broken-wall-smoothing forces (which caused it to get stuck in corners), it still worked far worse than my "closest-wave-only-goto-surfing-that-ignores-what-is/isn't-reachable-and-ignores-walls-and-bumps-into-them". Perhaps alot of the problem with my "True Surfing" though was that I wasn't accounting for the robot width, which caused it to stick around at local minimums in my movement profile that weren't particularly safe? I'm not sure if "True Surfing" can be brought to the same performance as GoTo Surfing, but I may be wrong. -- Rednaxela
- "True Surfing", as done by RaikoMX, CassiusClay, Dookious etc. will not get stuck in local minima. Every tick they see how far forward they could get before the wave hits them, how far backwards, and where they would be if they hit the brakes, and decide which is the least dangerous. Then they move forward, backwards, or stop. This is TrueSurfing. GotoSurfing? is where you generate a list of points along the entire reachable guessfactor range, and go to the one you decide to be safest. Both require some form of PrecisePrediction. -- Skilgannon
I don't think TrueSurfing or GoTo? Surfing are that different. The important thing is to have it bug-free and very precise. Most top bots use an algorithm that I would consider TrueSurfing (Dookious, CassiusClay), while DrussGT has recently got up to #3 with a GoTo? surfing. (Edit: See CassiusClay/Butterfly or Dookious/DookiSailer for details on the algorithms, if you wish.) -- Voidious
Hmm, I think I misinterpreted the definition of TrueSurfing as stated on it's page, to mean only considering the points one tick ahead and directly behind the robot, which would indeed get stuck in local minima. So if I understand "True Surfing" correctly now, it only evaluates the guessfactors at the end destinations, of going fully forward, fully breaking, and fully reverse and not anywhere inbetween? One other question I have is, when surfing multiple waves (with either TrueSurfing or GoToSurfing?), how do people tend to decide what point to orbit? Do most people tend to orbit the origin of the nearest wave, or the weighted average of the origins of all the waves or something else or does it not matter too much? -- Rednaxela
- It probably doesn't matter too much. I've heard of versions of CC that mistakenly orbited the enemy's current location and didn't lose rating points. Anyway, I think most orbit closest wave, but correctly take into account the waves' different origins when calculating GuessFactors on each wave. -- Voidious
  - Ahh, I see. Thanks. I think I'll give it a try making my own TrueSurfing implementation now, and try out orbiting the average origin of the enemy waves with the same weighting as it uses for the guessfactors. I think using that might give a subtlety smoother movement. -- Rednaxela
    - I found a weighted one (weighted towards the nearest bullet) based on the waves distance to your robot worked well, but it also ate alot of extra cpu clocks. --Chase-san

Okay! I finally got a working TrueSurfing implementation made from scratch (well, with a little code reuse from my old CircularTargeting code to do the precise prediction)! And damn... this thing is creating a really flat movement profile according to my builtin profile monitor (Well, a compliment to Voidious though: I've yet to see a flatter profile than Dookious's profile). I'm quite proud of my predictor code, which is a little sluggish, but fully accounts for everything except for robot-robot collisions (yes, it does include accurate turning speed limits). I haven't implemented WallSmoothing yet, so it's performance is still not so great though. Actually, against Shadow anyways, it wins a couple matches out of 35, but in a majority of the cases where it loses, it's either a close match where it just can't win (my lack of energy management could be alot of the issue) or getting stuck in a corner. It's encouraging that matches against Shadow end up fairly close when I don't get stuck in a corner, even if I very rarely win in those "close" situations. Thanks alot to everyone who's given tips! Next stop? WallSmoothing!

Hmm, One thing I haven't seen much on, is what to do after the enemy has fired a first shot, but my movement profile is flat so far. In the "GoTo? Surfing" I'd select a random guessfactor to go for, but as TrueSurfing doesn't use "goal guessfactors" in the same way, I suppose any sort of randomized perpendicular movement that doesn't run into walls would do the job fine? One other thought I've had is, do people usually save their own movement profile between rounds? Currently I don't, but I ponder if it might help, at least to avoid the points it visits early in the round from being as predictable. -- Rednaxela

Interesting... I just added some energy management code which roughly means: 1) Don't fire more powerful bullets than needed to kill it, and 2) Avoid firing bullets that would use more than 10% of our energy left. The effect of this, was a drastic drop in score against Shadow but a drastic increase in scorn against Duelist. I wonder what the right balance is or if there is an effective way method to manage energy against both bots... -- Rednaxela

My suggestion: don't test against Shadow unless you are a) just about to beat him anyways and b) are worried about your PremierLeague score. Not beating Shadow is nothing to worry about, nothing beats the strongest version of Shadow anyways =). RaikoMicro is one of my favourite testbots =) -- Skilgannon

But even so, this has shown me that the optimal level of energy conservation depends on the particular enemy, and thus ideally I'd have some way to adjust this. Some thought/observations about this I've had, is that:

If hit rate is very high, it's optimal to use powerful bullets to finish it quick.
If the hit rate is very low it's optimal to use powerful bullets in hopes of lucky hits getting a win.
If the hit rate is somewhere in the middle, it's optimal to make some efforts to to conserve energy somewhat.

I just wonder what the best way to decide a level of energy conservation is, and what the best factors of it to adjust are. Oh, and yes, RaikoMicro seems like a good test bot, except I'm annoyed at how I can't yet beat it. :-) -- Rednaxela

IMO, the optimal bullet-power algorithm works like this: if the distance is less than 150 or the hitrate is more than 33%, fire 3 power bullets. Otherwise fire 2 or 1.9 power bullets. Don't fire a bullet that would do more damage than the enemy has life, and would gain if one of their bullets in the air hit you. If you are low on energy fire smaller bullets, eg. energy/10 or energy/16, and never fire a bullet if it would disable you. Remember that the minimum bullet power you can fire is 0.1 =). Some parts of this I still need to add to DrussGT. -- Skilgannon

That sounds like overall a good algorithm, however I'm not sure if accounts for the underlying mechanic allowed me to get dramatically better results against Shadow without energy management. I'm not sure of the exact hit rate I was getting there, but I highly doubt it was over 33% -- Rednaxela