Oculus's movement fails. I can't download any of the movement challenges(All of the links are broken or the site is closed). I don't know how to be sure that it is improved. Are there key bots to test against?
- I found a proof that my movement is a failure. Here is a battle result against Raiko.
- dsekercioglu.OculusRaikoGun* 2437 (52%) 950 190 1151 147 0 0 19 16 0
- jam.mini.Raiko 0.43 2214 (48%) 800 160 1111 143 0 0 16 19 0
You can try to download them from archive.org even when they are broken ;) Hope the links are archived.
Find the bot you think you're notably failing, enable some graphic debugging and watch some matches at different speeds. Go back to your code, wonder what the hell is going on. Repeat. That's how I fixed most of the bugs for my last release. Maybe It will work for you :P
I don't think that it is because of a bug. Every movement I make is really bad. My old bots were built on BasicGFSurfer so no bugs I think.
Hmmm, it's neural, right? Is there any case of success of neural surfing besides Darkcanuck's bots?
As I know Only Pris uses Neural Surfing. Even if this movement is one of the worst in top 100 it is my best movement=). I think that I should tune it more against mid-level guns so it would be better against general.
Wow, was looking for this (old) challenge! Thank you, MultiplyByZer0.
Regarding the experiment, I know NN has a problem of slow learning since there isn't much data at the beginning of the game. Couldn't a reinforcement of firing waves in the first few rounds solve the problem, though? Another suggestion would be to use waves with low virtuality (those tick waves which are close to a firing tick) to suppress the lack of information without polluting the network with flattening-like data right on the first rounds.
I did something like that in my gun and it improved a lot. Of course, I'm no reference in Neural Targeting: I improved from a really bad gun to a miserable one :) Well, maybe you've already done that after all.
- Thank you MultiplyByZer0. I found out which part of my movement was weak.
You should be getting 99+% against Bot A. If not, you have bugs in your surfing, or you aren't even attempting to control your distances. Look to Komarious or CunobelinDC for help here, and make sure you are predicting the same escape angles you intend to move in.
Once you've done that, if you aren't getting 95% against Bot B, you might still have bugs in your surfing in the attribute collection, or you need to improve your learning. This is the most simple learning, a simple linear relationship between forward velocity and guess factor. If your learning algorithm can't quickly learn a simple linear relationship, you need to rethink it. I would suggest using a super simple learning (8 bins for the velocity value, plus a lower weighted "all the data") to make sure you have the attribute collection correct, then move on to fixing your learning.
Finally, you should be getting 90% against Bot C. This can only be improved by adding better attributes that you think might inadvertently model your near-wall and escape-angle behavior.
Hope this helps. Better scores are of course possible, but are very design specific. However with early non-DC versions of Cunobelin I was able to get a 99.9 - 96.8 - 95.1 score, and this was just BasicSurfer with segmented learning and distancing.
- I just looked a little bit more carefully. I found three reasons of getting hit.
- Unknown Wave
- Bot width calculation bug
- Not enough preciseness
- I will fix them all and try again.
Yes I found a bug in bot width calculation.
You do not have permission to edit this page, for the following reasons:
- The action you have requested is limited to users in the group: Users.
- You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page.Dsekercioglu (talk)
Return to Thread:Talk:Oculus/Movement/reply (32).
If there's one thing I learned from Robocode, there are always more bugs. Sometimes the bugs aren't even in the code, but in the assumptions the code was written with. That second category can't be caught with tests, just by looking for deviations from expected behaviour and being smart. The first category can be solved with just a bunch of hard, boring verification work.