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 this rewrite is done and ready.

How competitive is it?

Hard to say as it isn't in the RoboRumble yet, but it's first incarnation performs half-decent against mid-ranking bots, but gets slaughtered by the top bots. Hopefully the write will not be a regression.

How does it move?

The first incarnation of Gwynfor used a TrueSurfing-Flattener without WallSmoothing. In the rewrite I eventually plan to replace this with real bullet-dodging WaveSurfing, using flattening only when the enemy hitrate is high enough.

How does it fire?

Gwynfor's first version used a VirtualGuns array of CircularTargeting and GuessFactorTargeting with some inspiration from AutomatedSegmentation. In the rewrite, I'm going to first focus on a NeuralPatternMatcher and see where that leads me

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, at least currently.

What does it save between rounds and matches?

It's first form saves all GuessFactor data between rounds and matches. In the rewrite I plan to save the neural net weights between rounds but not between matches.

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. After it's released, maybe.

What's next for your robot?

Get this rewrite off the ground, and then attempt the PatternMatcherChallenge using my NeuralPatternMatcher plan.

Does it have any WhiteWhales?

All the top bots? No real WhiteWhales yet, but I'm sure there will be some.

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

---

I seem to be having alot of issues with getting movement right. For quick tests, I've tried plugging in various WallSmoothing code snippits that I've seen on the wiki, but they often seem to get my bot stuck even more, and if they don't they still cause a large drop in my score even though the movement may look fine to my eye. Anyone have some general tips for movement development? Would it be worthwhile to work in the context of MovementChallenge2K7 in order to develop movement while being sure the gun isn't getting in the way?

Yeah, working against something solid is a good way to go. Do you have any graphical debugging? It can help a lot for working out the finer details of the trig. -- Skilgannon

Currently, I use alot of debugging graphics in my targeting (i.e. a pretty display of the opponent's movement profile and as well as showing which gun is the active one of my virtualguns array), and also display a pretty graph of my own movement profile, however don't currently have any debugging graphics for my movement itself. Also, I just read more about WaveSurfing and found that apparently WaveSurfing is actually generally more about avoiding where you've been hit before. My implementation just was about avoiding anywhere I've been before. I think my movement therefore counted more as a "Flattener Surfing" of sorts (Haha, explains why I saw such a darn flat curve before). I'm thinking of making it bias against place where it's been hit before, anyone have any tips from experience about how heavily/lightly the flattener should be weighted compared to where I've been hit before?-- Rednaxela

In general, you shouldn't need any 'flattening'. Pure hit-dodging is good enough. I only recently (last week) added flattening to DrussGT, and it only gave me a 5 point boost. You have to be careful about flattening against simple targeting bots, because if you do hit-surfing you should be able to 'learn' their gun and dodge it perfectly, but if you add 'flattening' you will only make their hitrate drop to that of a random-targeting gun. DrussGT only enables its flattener if the enemy hitrate is above 10%, and even then it only gets weighted 50/50 with the hit-surfing buffers. I know Dookious, Phoenix and Shadow all employ similar methods. -- Skilgannon

Hm, true enough. Since I still want to track my movement profile for display, and I already have flattening coded, I'll keep it around, add hit-dodging, and use something like that hitrate threshold to decide if it should use the flattener or not. Thanks. -- Rednaxela

(edit conflict) First, you should consider what your tank's goal is: winning battles (premier league) or winning them absurdly (roborumble). A flat movement works best against strong guns, but it will not be as good as it could be against weak guns. As I have neither, I am not speaking from experience. -- Martin

My goal? As much of both as I can get of course I'll probably use something like hitrate as Skilgannon noted to decide if the flattener is needed. -- Rednaxela
As I read your goal is to get into The2000Club, the only thing you need is a flawless straightforward implementation of any kind of surfing. That should give you a 90+ score against the vast majority in the rumble, propelling you (close) to a 2000 rating. Nevermind those around 50 excellent targetters, they won't bring you down much. And when you have accomplished your goal, you will have lots of room for improvements. Welcome by the way, seems you are really doing your homework. -- GrubbmGait
Thanks. Hopefully switching from a TrueSurfing-Flattener to a TrueSurfing-Dodger (with optional flattening against stronger opponents) will improve things a bit. It shouldn't be hard to get that implemented as that isn't far from what I already do for the TrueSurfing-Flattener. What I'm most worried about right nowChanges is getting a robust WallSmoothing working, but I'm sure I'll get that working sooner or later. Thanks for the welcome, and I'm trying a bit even if I'm occasionally misinterpreting some things at first :-) -- Rednaxela

Interesting... before starting code to match onHitByBullet? events to known waves, I noticed I haven't constructed my EnemyWaves correctly, and they lagged two turns behind the real bullets and were not firing from the exact correct location (I found details about this offset around the wiki). So after fixing this, I thought "heck, it'll be interesting" so I did another test with my TrueSurfing-Flattener vs. Shadow to see the effect this had. The end result, was that whenever I wasn't stuck in a corner, I was actually getting an extremely similar hitrate against Shadow than Shadow was getting against me. It's rather fun watching Gwynfor and Shadow both missing eachother a lot, but Shadow being down to 0.0 energy while I still had 16.0 or so (sad thing is, it made a comeback and I didn't have it dead again till at 5.3 energy). I'd call that test encouraging that my WaveSurfing-Flattener is pretty good besides the lack of WallSmoothing and that my targeting isn't 100% useless... :-) Anyways, back to matching onHitByBullet? to EnemyWaves now, so I can do WaveSurfing-Dodging properly against people who don't target as well as the top bots '(edit: Okay, well, it seems getting that great hitrate ratios only happens every so often. It seems however, that sometimes Shadow gets a series of consecutive hits on me, but other times I'm just dodging perfectly. I'm not certain, but I think this likely means that sometimes Shadow is able to sometimes find some predictability in my flattening but other times it's just clueless. Still, the fact that it's able to fool Shadow fairly often isn't a bad thing. Anyways, back to concentrating on making movement that's good for thrashing non-top bots.)' -- Rednaxela

While working on getting WaveSurfing-Dodging coded more, I casually did a codesize check for the heck of it. Sure, for a MegaBot, codesize is meaningless, and I do have some "historic" classes of unused movement/targeting methods around, but even so... 14412 codesize. This one is getting big ;-) -- Rednaxela

My bot is 37586 in a test compile tonight. /shrug -- Martin
- Haha, nice. But yeah, issues of messiness in my code worry me more than my codesize :-) -- Rednaxela
What about 158026 codesize? :D --Krabb

Well, code rot has been kind of ill-managed here as I've developed Gwynfor. Now I need to decide, if I want to remake Gwynfor largely from scratch, do a lengthy refactoring, or hackishly finish off WaveSurfing before moving on. It's a pity because I put a lot into it. Hopefully lessons learned will make the next attempt smoother. If I remake from scratch, or move on after finishing off WaveSurfing, I wonder what I'll call my new bot, if it will still go by the name Gwynfor, use a variation like GwynforII?, or if I'll choose a new name entirely. Decisions, decisions... Curse you code rot... -- Rednaxela

I let Dookious go a long time before a full rewrite (it was already 2100+). With Robocode's addictive properties, it's easy to fall into a trap of writing messy code, for me anyways. I'm not sure if I can give advice on when is the best time to do it, but I can say that I was a very, very happy camper afterwards. I went from ~36k CodeSize to just over 20k (not that I made it a goal), I could once again be proud of my code (and not just my rating), and I even ended up gaining a few rating points. Plus it's so much more enjoyable to work with the code and easier to add new features. -- Voidious

DrussGT is in need of a major re-write as well... -- Skilgannon

Okay, in the rewrite, one issue I'm pondering, is how to set up robust event handling. In Gwynfor's first incarnation, I didn't really deal with many events besides onStatus, onScannedRobot and onPaint, however in order to do really nice surfing I'll have to deal with the different bullet events and such things. The issue is, I'm pondering a robust way to handle events in a way that keeps the state of the robot while it's processing a tick completely atomic (i.e. all events are buffered until the next time around the main loop). In Gwynfor's first form, It wasn't hard to make my "EnemyRobot?" data storage class buffer scannedRobotEvent? objects, and also make my "BattleState?" data store the next pending statusEvent, and such things. I'm just wondering what have other people tended to do to address this type of issue? I haven't seen much on the wiki about handling this. I'm thinking of storing a list of all events that occurred on a tick, and letting various data storage classes rummage through the list themselves, but I'm not sure if this is a great way to deal with it. -- Rednaxela

I have a heirarchy like this: 'Ugluk' extends 'Foundation' extends 'EventHandlerBase' extends robocode.TeamRobot. In EventHandlerBase the only event handlers I have are 'OnStatusEvent', 'OnSkippedTurnEvent', 'OnWin', and 'OnDeath'. In 'OnStatusEvent' (and only then) I first update my general state data, and then I collect all other events available as Vectors (e.g. super.getScannedRobotEvents() ), translate the events into custom data formats, and then process them in Foundation via abstract methods. You will not receive a StatusEvent following a DeathEvent, but you will with the other two. After processing the StatusEvent, control returns to my bot (after super.execute() in my run() loop) and my bot acts on all of the updated data. -- Martin