View source for User talk:Xor

Archived talks

Archived talk:Xor 20180221

Hey there!

To accurately measure the performance of different components of a bot, we do ablation study by disabling each of them. However, due to the popularity of hand-made bot frameworks, it is generally hard to compare your bot to other bots component-wise, even when source code is given.

Since we cannot have everyone rebase onto a common framework, another approach would be replacing part of the behavior of a robot dynamically. This should also work with bots without source code.

A robot can be divided into 3 basic components: Movement, Gun and Radar. Replacing behavior from one component is as simple as hooking calls like setBodyXXX, setGunXXX, setRadarXXX to IAdvancedRobotPeer. This way we can e.g. easily compare different guns from different bots while having movements fixed, even without doing anything with the code.

There are certainly drawbacks:

1. Replaced components are still consuming CPU while contributing no behavior.
2. No fine-grained way of comparing sub-components, e.g. Bullet Shadow
3. Certain features may not work properly without manually changing code, e.g. bullet shadow may have wrong gun firing angles

Also, frameworks like this should only be used for experimental purposes, and forbidden in competitions unless given permissions from original authors.

"My version" is also a little bit old, I will publish a recently updated one, hope that it can solve your problem.

thanks, looking forward to a new version

I updated the RoboRunner page to add the link to the fork. You can try and see whether it solved your problem.

Thanks. I already using and it it works.

Could you enable issues in your github repo, in case there are problems to report?

Done. It seems that issues aren’t enabled by default for forks ;).

Player: Write a simple robocode robot that dodges bullets.

ChatGPT: Here is a simple Robocode robot that dodges bullets by always moving in a circular pattern:

import robocode.*;

public class CircleBot extends Robot {

  public void run() {
    // Always move in a circle
    while (true) {
      turnRight(10);
      ahead(10);
    }
  }

  // When a bullet is fired, turn in the opposite direction
  public void onScannedRobot(ScannedRobotEvent e) {
    turnRight(e.getBearing());
  }

}

The robot moves in a circle by turning right 10 degrees and moving forward 10 units in each iteration of the run() method. When it senses a bullet being fired, it turns in the opposite direction to avoid it. This simple strategy can be effective against some opponents, but it may not be sufficient to win against more advanced robots.

Player: Detecting bullets fired by the opponent requires first recording the energy of the opponent, then check if the energy drop by a specified amount. Improve the above program so that it uses this technique.

ChatGPT: Here is an improved version of the CircleBot robot that uses the technique you described to detect bullets fired by the opponent:

import robocode.*;

public class CircleBot extends Robot {

  // Record the energy of the opponent
  double opponentEnergy = 100;

  public void run() {
    // Always move in a circle
    while (true) {
      turnRight(10);
      ahead(10);
    }
  }

  // When a bullet is fired, turn in the opposite direction
  public void onScannedRobot(ScannedRobotEvent e) {
    // Check if the opponent's energy has dropped by a specified amount
    if (opponentEnergy - e.getEnergy() >= 1) {
      // Turn in the opposite direction to dodge the bullet
      turnRight(e.getBearing());
    }

    // Record the opponent's current energy
    opponentEnergy = e.getEnergy();
  }

}

This robot works in the same way as the previous one, but it also checks if the opponent's energy has dropped by a specified amount (1 in this case) in each iteration of the onScannedRobot() method. If it has, this indicates that the opponent has fired a bullet, and the robot turns in the opposite direction to dodge it. This improved strategy can help the robot avoid being hit by bullets more effectively.

As per JEP411, SecurityManager is deprecated for removal as of Java 17. However, robocode (before Tank Royale) is fully dependent on SecurityManager in order to ensure fairness. Unfortunately, there are no official alternative to SecurityManager, which left us only three options:

1. Stick to Java <=17, which may be the last LTS version with SecurityManager support.
2. Switch to Tank Royale, and develop some container based security (which is platform dependent, unfortunately).
3. Find alternatives to SecurityManager, which can be used in both original robocode and robocode Tank Royale. SecurityManager alternatives can be used as pure Java sandbox solution for Tank Royale, which is cross-platform.

Good news: Java 9 Modules have complete support for encapsulation, which can be used as a shallow sandbox mechanism. Direct and reflective access to public members of non-exported packages are forbidden by the language, making robocode engine potentially safe from attacks. Custom ClassLoaders can be used to forbid or replace certain risky java APIs. File & network access can be further restricted by creating dedicated user, and Linux systems can take advantage of chroot & cgroup for enhanced control over resources.

By taking advantage of multiple layers of security countermeasures, we can achieve even safer & fairer environments for robocode competitions.

How comes that User:FlemmingLarsen kept the Tank Royale announcement outside of this Wiki? I think it seems to be the clear direction for a switch. It would be nice to have a bridge for legacy bots to run to avoid loss of historical stats. But the use of standard coordinate alone would justify the switch for me :) Also we would need a new rumble logic to be done.

I also get tired of java where a lot of high level math libraries need to be reinvented. I would love to see what is possible if we do not have to build our own implementation of machine learning tools.

We might get new flock of people if a python API is available.

Tank Royale is very exciting in allowing Python & C++, since a lot of us are tired optimizing Java code to make it more C.

However, Python & C++ are not as platform independent as Java, so in order to build a rumble ranking that everyone can run on their own, we must find some solutions. This could be the long term choice anyway.

In the short term, Security Manager is still there, and sticking to Java <=17 isn’t very bad as a lot of companies are still using Java 8. We have plenty of time to develop our own sandbox solutions, which is still useful for Tank Royale.

Tank Royale definitely sounds exciting. I feel like we would get a lot of new people if people could use more than just Java. I haven't looked at the technical details of Tank Royale but WASM sounds like a secure environment and a variety of languages can be compiled to it.

WASM is a great idea, we could keep a list of supported languages, where Java can use existing JVM sandbox, and C++ & Javascript into WASM. Not sure how Python can be adequately supported in this mode though, popular frameworks such as Numpy, Tensorflow & Pytorch are all not fully Python.

Update: Pyodide is a full WASM CPython implementation with Numpy support, which can be a good starting point.

Targeting maximizes cross-entropy

Wave-surfing minimizes cross-entropy

Random movement maximizes self-entropy

But random movement doesn't minimize cross-entropy

Flattener minimizes "self" cross-entropy

But flattener doesn't maximize self-entropy

What deeper insight can you get from this?

Guess Factor based methods generalize well, based on priori knowledge about robots moving in circles & max escape angle. Better methods such as precise max escape angle helps greatly. However given enough samples, I wonder whether some deep enough model can learn the shape of escape envelop, as well as precise max escape angle, etc. And generalize even better.

I could imagine developing some sort of "LearnedFactor" function that takes as input the firing angle along with the enemy's position, velocity, maybe more complex features like precise MAE, etc. As long as the function is invertible with respect to the firing angle you could then do KNN with those instead of GuessFactors.

The biggest challenge will be how to deal with different settings in recorded and aiming. Guess Factor indeed do this with orbital movement assumption, and PIF with not moving out of wall.

I'm thinking about some end2end deep model, where transformations between recorded and aiming angles can be learnt automatically. E.g. Given a sequence of historical wave intersect location, movement and bullet hits, try to predict the next wave intersect location.

Thanks Skilgannon and Voidious for maintaining the awesome robowiki and literumble!

I almost couldn’t wait to put my new bots into rumble ;)