Back

Explore Courses Blog Tutorials Interview Questions
0 votes
2 views
in AI and Deep Learning by (50.2k points)

Malmo is Microsoft's AI framework for Minecraft, consisting of a mod for the game itself, and a multi-platform framework for sending inputs and receiving data about the world.

Minecraft's aiming is cylindrical. It's stored in yaw (left and right) and pitch (up and down) instead of a full-on rotation quaternion. Yaw goes from -180 degrees at the far left and wraps to 180 at the far right. Pitch goes from -90 pointing directly up (zenith) to 90 directly down (nadir). In my code, I store these as a Vector2 (recreated to work much like XNA's) such that X represents Yaw, and Y represents Pitch.

I'm having trouble creating a continuous aiming to target algorithm so that the AI can aim its camera to given target yaw and pitch. Because the only way to do so while still allowing continuous movement is through continuous aiming (setting yaw and pitch velocities, rather than values), I need to repeatedly increment the yaw and pitch towards the target direction.

I do this by storing the target direction in a nullable property. If the property is null, that means not to change the aim. Otherwise, subtract the distance between the stored value (target aim) and the current aim (supplied via parameter) each time the update method is called. It then scales the difference so that either yaw or pitch is 1 (max speed), and the other is correctly proportioned for that. This proportioned Vector2 velocity is split into its yaw and pitch and then sent to the client via the turn and pitch commands. Once within 10 degrees of the target direction, the target is set to null.

On paper, it seems like this would make the camera's aim go directly towards the target direction (excluding yaw wraparounds). However, the client's pitch usually goes straight past the target direction, despite the update method sending a pitch command that says to go the opposite direction. This means the pitch somehow gets "stuck" at the zenith and nadir, but fixes itself and "turns around" and gets stuck at the opposite pole after a couple of seconds. The amount of time spent stuck before turning around seems to increase exponentially (or maybe quadratically) each time.

Here's the source code of my aim update method:

public void UpdateAim(Observations obs)

{

    // AimTarget is a Vector2? property

    if (AimTarget == null || obs == null)

    {

        return;

    }

    if (AimTarget.Value.Distance(obs.Aim) < AIM_CLOSE_ENOUGH) // < 10

    {

        Logger.LogInfo("Reached {0}", AimTarget.Value);

        Look(Vector2.Zero);

        AimTarget = null;

        return;

    }

    double deltaYaw = AimTarget.Value.X - obs.Aim.X;

    double deltaPitch = AimTarget.Value.Y - obs.Aim.Y;

    // These two are stored as private Vector2 fields

    deltaAim = new Vector2(deltaYaw, deltaPitch);

    scaledAim = deltaAim / Math.Max(Math.Abs(deltaAim.X), Math.Abs(deltaAim.Y));

    Look(scaledAim); // sets continuous aim velocity

}

And the (simplified) source code of Look(Vector2):

 public void Look(Vector2 direction)

{

    // Agent is an AgentHost property

    Agent.sendCommand("turn " + velocity);

    Agent.sendCommand("pitch " + velocity);

}

UpdateAim() is called 20 times a second (although I have tried as high as 50 times a second and as low as 5) during the main game loop.

At the end of the last time, I ran the AI (which got stuck at the nadir), my aiming to debug data looked like this:

// Format: (yaw, pitch)

Target Aim: (134.75, 27.90)

Actual In-Game Aim: (-6.50, 90.00) // Lines up with MC's debug screen

Delta Aim :  (145.17, -62.10) // Total degrees needed to go in yaw and pitch

Scaled Aim Velocity: (1.00, -0.43)

The scaled aim velocity is what is supplied to Look(). As you can see, the pitch velocity was negative as it was supposed to be, but the actual in-game aim remains at 90 and for some reason doesn't get corrected. Am I doing the math right?

1 Answer

0 votes
by (108k points)

It looks like Agent.sendCommand not doing its job correctly as if the pitch velocity is negative at the nadir then why it doesn't move down. Maybe it has a backlog. I'm not sure as testing it with a 500ms delay between loop runs results in wild inaccuracies and overcorrection that's nearly impossible to distinguish from this issue.

Browse Categories

...