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.Rsalesc (talk)
Return to Thread:Talk:Oculus/Movement/reply (28).
- 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.
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.