Difference between revisions of "User talk:Chase-san/NewTech"
m (→Refactor TODO) |
m (→Refactor TODO) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 33: | Line 33: | ||
== Refactor TODO == | == Refactor TODO == | ||
| + | |||
| + | More of a 70% Refactor/30% Rewrite. Kakeru was developed for rank 40ish level competition and was becoming very unmanageable in the mid teens where it has ended up. My originaly goal for Nene was rank 28 (high enough I don't have to scroll down to see it). But it obviously got much higher. I have been putting off the refactor/rewrite for awhile. | ||
Goals for refactor: | Goals for refactor: | ||
| Line 39: | Line 41: | ||
#Split giant monolithic class into multiple smaller (easier to handle) classes. | #Split giant monolithic class into multiple smaller (easier to handle) classes. | ||
Thing to do for refactor: | Thing to do for refactor: | ||
| − | # | + | #Add in N wave surfing. |
#Some better way to determine best distance (dynamic?) or remove the concept of best distance entirely. '''Little idea how to do this.''' | #Some better way to determine best distance (dynamic?) or remove the concept of best distance entirely. '''Little idea how to do this.''' | ||
#Better way to actually handle the robot turn for distancing. '''Little idea how to do this.''' | #Better way to actually handle the robot turn for distancing. '''Little idea how to do this.''' | ||
| Line 50: | Line 52: | ||
#Some way to dynamically determine the weighting for point weights. '''Little idea how to do this.''' | #Some way to dynamically determine the weighting for point weights. '''Little idea how to do this.''' | ||
#*Based off how similar the data is to the current state, might combine with number of points. | #*Based off how similar the data is to the current state, might combine with number of points. | ||
| + | #Add pattern matcher to calculate the likely very next enemy location (heading/velocity) for heat wave position. | ||
#Fix a few special case bugs | #Fix a few special case bugs | ||
##Bug in the '''intersected bullet position distance to wave center distance might be a number of turns ahead or behind the actual wave travel distance when detected''' system | ##Bug in the '''intersected bullet position distance to wave center distance might be a number of turns ahead or behind the actual wave travel distance when detected''' system | ||
| Line 61: | Line 64: | ||
# Created a better mouse trap, err, I mean wall collision detection algorithm. | # Created a better mouse trap, err, I mean wall collision detection algorithm. | ||
# Switched wave ETA sorting to use built in Java sorting. | # Switched wave ETA sorting to use built in Java sorting. | ||
| + | # Robot/robot collision energy drop handling. | ||
| + | # Rewrote Heat Wave firing (Pattern Matcher positioning still pending) | ||
| + | # Rewrote Passive Bullet Shadowing | ||
| − | Next | + | Next todo: |
| − | # | + | # ??? (take a break) |
Latest revision as of 00:50, 2 September 2011
Barracuda & DevilFISH
Personal Note: Version MC31
About Barracuda. The robot only so far has naive dive protection in that it dodges bullets and thus will move away when it cannot continue going forward without hitting a bullet.
In the case of DevilFISH. The fact that it prefers to not move when there are no bullet in the air combined with its heat waves is what gains it the most score here. This means it reacts quickly to the close range combat of this robot. Making close range combat against it something of a stop and go movement which is what DevilFISH is bad against.
This behavior against DevilFISH was not planned, though I had taken note of it earlier in development when it strayed near the enemy. This is also what loses it so many points against Barracuda.
Fixing one without breaking the other requires that I try to avoid close range combat with some kind of distance based danger as so it does not get to close to Barracuda to cause it. Tackling specific corner cases such as jammed in corner or rambots would also improve this, though care needs to be taken to not lose this advantageous close range movement.
— Chase-san 09:05, 1 August 2011 (UTC)
About Out of Modifications
I have almost run out of large modification improvements to make. Almost time to hunker down into the tweak phase of production. I am wondering if there is anything else to add that I forgot. 17:35, 7 August 2011 (UTC)
After this phase I will be tweaking the following, followed by adding segmentation. I hope to be able to hit 70 to 72 in MC2k7 before I start on the gun.
- Wall Smoothing Improvement
- Distancing
- Perhaps adding dynamic distancing of some kind
- This should also help improve the Head On Dodging
- Temporal Decay
- Seeking out bugs
— Chase-san 17:35, 7 August 2011 (UTC)
How about exploiting the BasicSurfer bug. Although it is not an 'improvement' on strategylevel, it will help you with approx 0.5 APS. Another 'cheap win' is some protection against bulletshielders. For the rest your list above is rather complete. --GrubbmGait 00:10, 8 August 2011 (UTC)
Refactor TODO
More of a 70% Refactor/30% Rewrite. Kakeru was developed for rank 40ish level competition and was becoming very unmanageable in the mid teens where it has ended up. My originaly goal for Nene was rank 28 (high enough I don't have to scroll down to see it). But it obviously got much higher. I have been putting off the refactor/rewrite for awhile.
Goals for refactor:
- Remove as many magic numbers as possible and replace with automatically or dynamically determined values.
- Elegant handling of two wave surfing
- Split giant monolithic class into multiple smaller (easier to handle) classes.
Thing to do for refactor:
- Add in N wave surfing.
- Some better way to determine best distance (dynamic?) or remove the concept of best distance entirely. Little idea how to do this.
- Better way to actually handle the robot turn for distancing. Little idea how to do this.
- Current version is very hacky.
- Better method for controlling movement behavior in general.
- I just pack everything into a single function at the moment.
- Tuck that function it away into a class w/ interface, etc
- Some way to dynamically determine the number of points it should use for risk evaluation. Little idea how to do this.
- Probably based off hitrate, and bullet damage ratio.
- Some way to dynamically determine the weighting for point weights. Little idea how to do this.
- Based off how similar the data is to the current state, might combine with number of points.
- Add pattern matcher to calculate the likely very next enemy location (heading/velocity) for heat wave position.
- Fix a few special case bugs
- Bug in the intersected bullet position distance to wave center distance might be a number of turns ahead or behind the actual wave travel distance when detected system
- Bug in the revert everything to what it was before we got a fake wave from count down timer execution system.
Flush out ways to do the things I don't know how to, after I proceed to figure them out.
Completed so far:
- Separated out wave tracking into its own class (parent).
- Created a better mouse trap, err, I mean wall collision detection algorithm.
- Switched wave ETA sorting to use built in Java sorting.
- Robot/robot collision energy drop handling.
- Rewrote Heat Wave firing (Pattern Matcher positioning still pending)
- Rewrote Passive Bullet Shadowing
Next todo:
- ??? (take a break)
