Spitfire
Spitfire is a robot that only uses bullet shielding. It provides an interesting point of reference for the technique, and also serves as a base for the bullet shielding mode in my robot XanderCat. It is based on my Xander Framework.
Contents
Version Notes
Version 1.1
- Improve how lead time required for successful shielding is calculated. This improves shielding against close fighting opponents.
- Fix bug that was causing Spitfire to not shoot against some opponents.
Version 1.2
Framework Updates
- Add new checks of velocity and gun cool time to try to avoid registering an opponent wall hit as firing a bullet.
Spitfire Updates
- Allow bullet power to go up to 1.5 for better shielding coverage. Limitations: bullet power used will not exceed the power of the bullet being shielded; bullet power will not exceed minimum if opponent has more energy.
Version 1.3
- Add ability to to shield against multiple targeting methods.
- Add secondary guess on opponent targeting method.
Version 1.3.1
- Move less when shielding against stationary opponent. Previous movement was apparently too much; enough to cause a shift in opponent aim.
Example Code
The main robot class; short and sweet:
public class Spitfire extends AbstractXanderRobot { @Override protected void configure(Configuration configuration) { configuration.setAutoFireOnDisabledOpponents(false); } @Override protected void addComponents(ComponentChain componentChain) { componentChain.addDefaultComponents(new BasicRadar(45, 3)); BulletShieldingFactory.addBulletShieldingComponentsAsDefault(componentChain, 0.1d); } }
Above, the call setAutoFireOnDisabledOpponents seems a little backwards, as Spitfire does fire on disabled opponents. The Xander Framework auto-fire functionality (which this setting turns on and off) is set up to fire a head-on shot immediately on a disabled opponent. However, with Spitfire, it needs to be sure that all opponent shots have been shielded before firing on a disabled opponent. For now, I just handle this in the bullet shielding gun. In the future, I may update the framework to make this a little more configurable to handle either approach.
Below, a look at the BulletShieldingFactory method for setting up the bullet shielding components:
public static void addBulletShieldingComponentsAsDefault(ComponentChain chain, double maxAdjustedFirePower) { BulletShieldingDrive bulletShieldingDrive = new BulletShieldingDrive(); BulletShieldingController bulletShieldingController = new BulletShieldingController(bulletShieldingDrive); BulletShieldingGun bulletShieldingGun = null; if (maxAdjustedFirePower < RCPhysics.MIN_FIRE_POWER) { bulletShieldingGun = new BulletShieldingGun(bulletShieldingController, getCommonBulletTargeters()); } else { bulletShieldingGun = new BulletShieldingGun(bulletShieldingController, maxAdjustedFirePower, getCommonBulletTargeters()); } chain.addDefaultComponents(bulletShieldingDrive, bulletShieldingGun); }
My current design uses a "controller" to deal with tracking shots, and it serves as an intermediary between the drive and gun. The gun requests waves from the controller, and the controller tells the drive what to do and lets the gun know when it's okay to fire.
For v1.0, I'm not utilizing the max adjusted fire power functionality. I just always use 0.1 shots. If I ever turn it on, it will vary the fire power up to the given amount in an attempt to improve the shielding overlap.