View source for Talk:Neuromancer

Does Neuromancer use a Melee Flattener? It could be interesting.

No, because there are so many simpler targeters in melee I think it is more important to try to dodge the easy bullets you know about. Against these simpler targeters a flattener would make things worse, since I already dodge them so well.

Also it is very difficult to know when to enable it against better targeters, since hitrates are hard to track as you don't know which bullets were fired at you.

Neuromancer 5.1 seems to have a bug when Hide Enemy Names mode is enabled. It will stall in the middle of the battlefield some time after the second round.

Run a battle between Neuromancer and 9 TrackFires with Hide Enemy Names on, you'll see it.

I don't think that it would effect the rumble results.

Thanks! It seems that there was an bad == string comparison, which was safe when using the static names but caused problems with the dynamic names. It should be fixed in 5.2.

Looks like Neuromancer is not that bad in 1vs1. My guess was, he will be within the top-50 but top-30 is quite nice, i guess.

Thanks. It has improved a bit since 1.0, I think it is due to the better bullet power selection and escape angle selections. Also it logs bullet-hit-bullet, which didn't work before (it was buggy).

Looking good. I guess it's time to stop focusing on Melee for a while and try to climb to #1 in 1v1 with Neuromancer? O:-)

Time to put some work into my MSc, I think ;-)

I've observed a few times Neuromancer's gun thrashing pretty badly - sometimes doing a full circle before firing. I'm currently trying to avoid this by accounting for an extra of max(time-till-gun-turns-to-angle,time-till-gunheat-is-0) in my PIF time, but I wonder if anybody else has come up with some way to avoid this problem?

So is your firing condition just that the previous tick's aiming completed? And if it didn't, you re-aim? That's all I do and I haven't noticed thrashing, but I don't watch as many Melee battles as I probably should. Projecting extra ticks in the PIF seems like a good idea. Maybe also try adding a factor into the kernel density evaluation that penalizes angles that will make you fire late?

Yeah, that's it. I'm hoping that the extra PIF ticks will cause more spread in the enemy movement, correctly accounting for the increased uncertainty, but I think with the sample sizes we are looking at that isn't really good enough. Perhaps there are points hiding in not going for angles which will take a 180 degree gun rotation, although I really doubt it...

Not sure if you did this already but you could try to bind the targeting to the gun heat. The closer it comes to zero gun heat the less it changes the once found target/area. But i guess if your gun shoots 'blind' you have to weight the new (maybe better target) to the couple of turns you might loose. Because especially in the beginning of the battle 'trashing' is not that bad if your radar detects an enemy that is sneaking up to you (in this case i wouldn't call it trashing - its more likely an emergency reaction). Overall i would guess your targeting is a little to picky dependent on your movement and battle state. Its like 'oh this one is nice ... no wait this one ... oh hang on, this one looks nice ... hello what are you doing right behind me?' :) So i guess you can just let the targeting more space (dependent how many opponents left) to pick a target/area and should be fine.

I found I was waiting for this tick's targeting to align to within 40/distance of the current gun angle before I would fire, so now I just wait for the current (getGunTurnRemaining() == 0 && getGunHeat() == 0) and then I fire. This will lower my accuracy, but I will fire much more often, so I'm interested to see what will happen!

I guess this makes no difference. If the targeting is sound, it should be within 40/distance on this turn as it is at zero at the next turn. Anyway, this will not solve your trashing issue :). If the gun is on its way to lets say PI and the next turn the targeting decides no its not PI its PI/2 your gun will trash between the targets and will not shoot at all for the time it 'trashes' between two headings.

I think the trouble is if there is say a peak at 3*PI/4, and another at 7*PI/8, and both are almost of the same likelihood, then even though the gun can easily turn to both, if they keep changing which is better then I might never end up shooting. Now, as soon as I have a single tick which the best angle changed less than MAX_GUN_TURN_RADIANS, I will fire next turn. Although it seems I have lost some score with this version, so maybe it was better before??? I know I need to do some serious work on my gun, it matches vs all the top bots I get much lower bullet damage.

Yes thats how it works if you take gunTurnRemain() before fire() (worst case is checking against 0) but with 40/distance you have a good value that it happens very rare. You just have to decide whats better for you - shooting one tick earlier (with 40/distance) or shooting more precise with one tick later (zero check). I spend quite a while on this issues and finally decided to go all the way with zero check. You also have to decide what bullet power to use - the one that is used to calculate the angle or the current one. Both have some pros/cons to. Shooting if the last target is not the same as the current target is also something you have to decide.

Hmm its hard to explain for me right now but even with zero check you can end up with not firing. If your gun targeting constantly decides to change the target/area your gun will never (at least less often) be zero as you wish. That mostly happens on loose radars, every time the radar sweeps to the opposite side and finds a better target the gun begins to rotate to this point - the radar sweeps back and decides oh this target is better (consider the movement as well) so the gun has not finished its turn and gets a new target - and so on.

A quite good test to see if your gun has trashing issues related to your movement is putting your bot against 9 Sitting ducks. If he misses some shoots or break the fire frequency to often you have something to change.

If it comes to score, my experience tells me that +-0.3 after 5000 battles translate to no change at all. I see you have a 0.04 difference and this is clearly equal to the last version. In melee it depends on what start battles you get to bring all the pairings up. I have seen jumps of 0.8 score even after 15k battles just because the start battles where to easy.

Maybe it helps: i have a test bed of some sample bots (always the same) and let it run 100 rounds ... i call it 40k/100k+ challenge. 40k = 100 firsts 100k+ = dmg. If your bot loose just one round he has some radar/movement issues. If he gets less than 100k dmg the gun need some changes. To be one of the top bots i guess you have to try 110k+ or more. I use this challenge almost exclusively to decide if i had made progress or not, because it runs fast and has almost every battle state i have to take care of in it. I might be wrong with it but it served me well so far.

Take Care

edit: not sample melee bots just sample bots

Thank you for the info - I often wonder how other people test their bots =) I know I did a similar technique for 1v1, I test a lot with DoctorBob to get my surfing right, as well as RaikoMicro for my stats systems. It seems to have worked well there =)

However, you have the ways I check for targeting error wrong. The first way (1.9) aims, then checks if the gun is within 40/distance. If so, we fire. The other way (2.0) checks if gunTurnRemaining() is 0, sets gun to fire, THEN aims. So, the second way will fire more than the first way even though it is checking for 0 instead.

Uhh mate stop confusing me :) .. i thought i figured it out and would never think about it ever again :)

The way you describe it was how i was understanding it.

1.9: gun heat has to be zero
calculate angle
check angle (if you check here against zero it almost never shoots, but with 40/distance it will shoot)
fire
next turn: bullet is on its way

2.0: gun heat has to be zero
check angle (zero)
fire
calculate angle
next turn: bullet is on its way

So both versions are the same, they shoot one tick after the gun heat is zero. But 1.9 has the advantage of shooting in cases where the gun is almost pointed to the target where 2.0 has to wait one more turn. If both versions are already pointed to the target then there is no difference. Thats how i understand it and therefor it looks to me that the first one shoots more often and the second one is more precise. Am i wrong with this? Man this stuff really confuses me :)

Hopefully I won't confuse this further, but I think the two options are:

• Style 1:
  • if (gunTurnRemaining() == 0) then fire()
  • re-aim (won't effect angle used in fire())
• Style 2:
  • re-aim
  • if (gunTurnRemaining() < 40 / distance) then fire()

So the first option just sees if your aim from last tick has completed, fires, and then continues re-aiming for next tick (which won't affect this tick's firing angle). The second option requires that the firing angle remains somewhat stable from last tick to this tick. It's also sort of the case that the first option is aiming 1 tick further into the future, since the second option will hold off firing if the aimed firing angle doesn't line up with the next tick's firing angle. FWIW I used to do Style 2 (Dookious, early Diamond, but with 18 / distance) and now use Style 1 in Diamond.

Style 1 makes it a lot easier to deal with firing pitfall.

Sorry, I guess maybe that was clear already. The reason the zero check thrashes less is that it only requires that the last gun turn was <= 20 degrees, while "re-aim and check within threshold" requires that the firing angle somewhat lines up two ticks in a row. (Though 40 / distance is a pretty big threshold, too - I always used 18 / distance.) And while the zero check is more precise, it's also in a sense projecting one tick further in to the future, since the other one is effectively aiming one tick later (by vetoing if the current gun heading isn't close to how we'd aim this tick).

Using Swarm Targeting with gaussian kernel density usually gives a single angle which doesn´t change often.

Gun thrashing means the bot keeps changing its mind every tick. Usually happens when you target the closest bot and there are 2 or more bots with similar distances.

Swarm targeting (which is what I am using) can change rapidly too, because of the discontinuities caused by scanning new robots. For instance, if you are aiming towards a bot, then scan them and discover they moved further away and in a movement pattern you haven't seen before, suddenly it is better to target a bot on the other side completely. Of course, I'm using a square kernel instead of gaussian, I might try a 1/(x^2 + 1) kernel sometime but I've never found improvement over square when targeting.

Uniform kernel gives a bunch of tied best angles. If you use random tie-breaking and recalculate every tick, then the gun can thrash a lot. Generating a random number only once per shot solves the problem. I used it before switching to gaussians.

But it doesn´t solve the problem of turning the gun 180 degress. Besides Swarm Targeting, the only thing my bot does to avoid it is trying to stay near walls/corners.

Most articles dealing with gun thrashing in melee try to lock the gun on a single target.

Hmmm, I weight each hit based on the inverse distance that the KNN point had to the current point, so I don't have that problem. I'm just thinking, that isn't made equal on a per-enemy basis, so if one enemy has KNN points closer together its points will be weighted higher. Hrmmm... at the same time surely those shots are of a higher certainty? Will need to test.

Maybe inverse distance is overflowing kernel density estimation. When KNN distance is too low, classification score tends to infinity. The result is a bunch of tied angles with infinity classification score. Depending on the tie-breaking being used, the gun can trash a lot too.

I just want to say, if you thought 1v1 WaveSuffering was bad, melee is on a whole different level. For instance, in 1v1 the changes I made from 1.1 to 1.2 would probably boost my score by over 1%, but in melee it got lost in the noise. I've done a major restructure to allow me to keep post-scantime-interpolated snapshots of where everybody is on the battlefield, and to let my wavesurfing get updated by it to use the improved wave centres, enemy locations at fire etc. As far as I can tell everything is working perfectly, but it now tanks fairly horribly against simple targeters outside of the 1v1 context.

I can only imagine. And you're making me feel pretty good about my hunch that there's not enough data in Melee to effectively surf. :-) But if your score is tanking vs simple targeters, I have to think you have introduced a bug somewhere. How could it be otherwise?

Unless there's a side effect to the predictability of your movement profile, or other risk factors are now being under-weighted... I guess there's a lot to consider. But if it's really that much more accurate, I'd expect the scores to improve after some re-tuning, right?

There is less data to surf in melee, but completely ignoring opponents energy drops and bullet hits is counter-intuitive. Changing your movement when you are hit contributes to being less predictable at least, even if only at the end of a round.

Maybe some weighting according to number of opponents?

The only catch is the one arguing against melee surfing, Voidious, have a bot in 1st place in meleerumble, and my bot is 12th. Intuition says one thing, the numbers say another.

My bot uses neither wave surfing, nor minimum-risk, but anti-gravity with shrapnel dodging instead. The idea is the same, but with a lot less code, and lower accuracy. Try to stay away from other bots, and stay away from points in waves where you expect to have bullets in it. Dodging incoming waves at least help the bot not getting stuck in stationary local minima, the worst problem with anti-gravity movement.

I guess, in melee you have to be careful with wave surfing taken from 1v1, because you can not just move to the least dangerous position. The field changes sometimes very quickly, especially in the first rounds, that it would be better to do some sort of weighting between defense and offense. Most bots that only avoiding confrontations get caught on a local maximum and if the whole field changes it position they are in a very bad position. A nice example is, if Wallaby goes for a corner and moves closer and closer, most bots get out of the corner because the risk raises and end up in the open field. I guess a well weighted wave surfing combined with a nice minimum risk would be awesome if not to say superior :). Just my 2cents.

My observation for simple targeters is, that because of the radar sweeps most guns shoot not straight HOT or linear. There is always a little shift. Especially nano bots have not very reliable (from defenders point of view) simple targeting. The fact that most nano bots don't have the setAdjustXX() methods set is also one thing that they don't shoot 'straight'.

I've seen this happening many times. A bot will move and fire towards a nice corner position that Neuromancer has, and Neuromancer will dodge the bullets out of the corner and end up going right across the field dodging bullets the whole way, bullets which wouldn't have been aimed at him if he had stayed in the corner. Mostly when Neuromancer gets killed it is because of bad positioning, being so close to an enemy that it was impossible to sense the bullet drop and dodge in time, but can't go in the other direction because of a wall or other bots. It is also a problem when about 5 waves are converging at once, it is difficult to weight which direction is best, although I have an idea for both of these problems...

Nice entrance! Excited to see where this goes. :-)

Now that you're further along, what's your current view on the potential of Melee surfing? Do you think you can effectively dodge simple targeters beyond HOT, or simple learning guns, or even good learning guns? It seems that you and a couple others have proven you can dodge HOT fairly well in Melee...

Of course, there's also the question of whether it's worth it, for what you may sacrifice in good positioning. But that could take a long time to answer.

First off, I'm not purely surfing. I'm doing a minimum-risk movement which has a weighting of wave dangers as well as position dangers, so hopefully my wave dangers don't cause too much of a problem with the positioning, avoiding being targeted etc. If nothing else, hopefully it will take the least dangerous position that doesn't let me be hit by the wave.

As for the potential, from what I've seen the limitation is how much information can be gathered. I'm surfing every bullet fired at every bot by every bot, so theoretically, if I can see all of the waves, I can dodge all of the bullets. I'm not doing energy-bonuses for hits, bactracking chains of energy drops or anything like that, and given the big scan gaps that means I'm missing a lot of the bullet firings. I think there is still a lot of performance that can be eked out of the movement, tracking and weighting still, although it will have to become much much much more complex. I'm not sure if what I envision will successfully run without skipping turns; certainly not without being quite a slowbot. But then, compare any 1v1 surfing movement to a decent 1v1 random movement and the same parallels and trade-offs are also made.

As I said earlier, the cap is the stats gathering. I am simultaneously learning every bot's targeting preferences against each of its opponents, so there is a lot of info that needs to be acquired, and given the big scan gaps, not much data to go on. This will be improved slightly once I get the energy tracking due to more waves being fired, but remains what I think is the main limitation against complex targeters. I don't think it will ever get to a point where it is useful, for example, to add a flattener just against the stats of certain bots but not others. On the other hand, I do think it gives the best possible potential for dodging complex targeters that we're going to get. Anti-gravity-with-perpendicularity type minimum risk movement certainly isn't going to be less predictable, and that is essentially the state of the art when it comes to melee right now.

My feeling from watching matches is that this works extremely well towards the endgame, when there are 5 or less bots on the field. In the beginning it is often too crowded to successfully surf without becoming an easy target, but once there is a bit of space this movement really comes into its own.

Interpolation may help guess what is happening between scans.

Congradulations! I'm eager to reinstal robocode and watch Neuromancer in action! :) Reguarding your 5 bot or less comment: I wonder; Are you effectively doing (minimumRisk*waveRisk = totalRisk), or some sort of wieghted addition instead ? "Limited and sh@#ty info" - Yep, Welcome to MeleeRumble ! :D -Jlm0924

I'm doing an addition, since I don't think the two risks are interdependent. Currently I'm normalising each of them with respect to the median dangers and then doing danger = 3*waveDanger + 1*positionDanger.

Right now I'm just scratching my head as to how I can get better/more information, and besides hardcoding lots of cases of 'they fired once and were hit twice', 'they fired once and were hit 3 times', 'they didn't fire but were hit twice', 'they didn't fire but were hit 3 times' etc I don't know where that info is going to come from.

I'm still just dealing with regular old 1-tick-wide waves, which does need to change, but that can wait for some gun improvements.

Try tracking all waves from all opponents, and if opponent´s A energy drops the same as opponent´s B wave damage passing over opponent´s A, it is probably a hit?

That may work... or open a vulnerability where opponent A shoots an undetected bullet with power equal to opponent´s B wave damage.

That's what I do. I also track gunheat to eliminate invalid waves, and account for the case of them being hit and firing at the same time (or at least, between two consecutive scans).

For that vulnerability to occur the enemy wave would have to be very low power - bullet less than 0.75 - and they'd have to wait for it before they shoot. Eventually I want to check for bullet bonus before I count a wave as hit, it would be much more complex but could lead to a significant score increase. The trouble is that I don't know if it would help much because I don't know how many waves are incorrectly labelled as 'hit', so I'm not sure if this is worth it.

I've heard that gun accuracy can go up by scanning targets just before fire time, so maybe I'll give that a shot next.

I'm still very curious how much true bullet dodging value you're getting from this, but I guess I'll need to get down and dirty and investigate it myself if I want to know for sure. :-) Obviously the end result of your movement algorithm is a very powerful one, so huge props on that regardless.

But for instance, I wonder if you fed the wave surfing false (but realistic) data about enemy energy levels, how much would it affect performance? It still seems very possible to me that the net of all this "surfing extremely noisy data" + the MR elements is about equivalent to a nicely randomish minimum risk movement.

Well, watching Neuromancer in a battle is quite interesting. There is none of the usual 'stick in a corner and avoid other bots' mentality that I tend to see with regular MR, instead it is all over the place, right through the middle of the field, for the most part missing bullets that seem to fly all around it. I think Neuromancer tends to get a lot more bullets fired at it than most bots because the MR isn't the only thing that's directing it, but still manages to do a brilliant job of racking up the survival points. So yes, I think I am getting some very real bullet dodging, but it is at least partly offset by the increased 'targetability' created by that same dodging.

That sounds like an interesting experiment, but I think more conclusive would be releasing a version using Diamond's gun - is that OK with you? Would I need to use Diamond's radar as well?

Wow, that actually sounds really interesting. Maybe I'll watch some battles.

Sure, you're free to test with Diamond's gun, would be cool to see the results. I don't think you need the radar - it doesn't look like they're even connected now that I do Shadow/Melee Gun. The only gun/movement/radar connection is the gun reporting to the movement for Bullet Shadows, so if you're doing that you'll need to rig something up.

I'm also going to get a Melee client going and try to get the latest Diamond into MeleeRumble... It's possible I've broken something since 1.5.30, I'm not sure.

Cool thought on feeding it false bullet drops :P (No wonder I have no tools to test:) but I think you'd be surprised Void.. In Diamond I believe you used a random "push", to modivate and randomise it's minimumRisk. Melee surfing is simply replacing that random push; using additional risk based on the danger of crossing waves. (IMO) As long as you collect good wave data (in melee) I don't think it will matter if it is perfectly accurate.. (It will still "push" the minimumRisk in a smarter direction) On the other hand, the surfing data doesn't need to be noisy ether. eg: If you detect a bullet drop, but it's been a few ticks since you last scanned the bot, you could simply throw it away.. :)Keep in mind: even if your still missing 3 scans, simply choosing the middle missing scan (as the fireTime and position) means you'll only be out 1 tick max. (Good in my books:) I remember testing with spinning radar) @Skilgannon: Yeah, I also use a similar addition for total Risk,(using standard deviation ). You might wanna try multipling if you haven't tried it already (without zeros). Reguarding your "regular old 1-tick-wide waves" : I though about that, but I just binn smooth to hell anyway :) -Jlm0924

I'd rather not throw anything away - I feel that even a badly aligned wave is better than no wave. But I might be wrong - more to test, I guess.

Nice update with version 0.6 there! I'm curious, how much local testing have you been doing with Neuromancer between versions?

By the way, it looks to me like it's still slightly behind Shadow contrary to the description thing.

Yeah, between 3000 and 4000 battles it dipped from just above Shadow to a little ways below. I'll wait for this version to stabilise and then see if I need to change that =) My testing is fairly minimal. I do a few battles with some HOF, some Shiz, some DoctorBob, a sample bot and a top bot, just to check I haven't broken anything major and that the changes made some sort of difference, but I haven't had time to do any proper testing. I'm still at a stage of adding major features, once I get on to tweaking the testing will be more important I think.

In future I'll wait for 4000 battles before making any conclusions... sigh.

Ahh, interesting.

Hmm... that number of battles issues makes me wonder if I should experiment with making the rumble server show statistical significance information when comparing versions.

Dunno if any of you read PA, but this seemed timely. =) Comic: One Explanation

Ha! No, I don't do much in the comic scene besides xkcd and SMBC. According to IMDB there will be a Neuromancer movie coming out in 2014... can't wait =)