[Question] Rendering issue in mpe

[colourfulspring]

Sorry, I think my issue is Question instead of Bugs. I have edit it. But I do not konw how to change labels.

---

Question

Hello,
I am using this code to test mpe.tag environment.

from pettingzoo.mpe import simple_tag_v3
import imageio

env = simple_tag_v3.parallel_env(num_good=2, num_obstacles=2, num_adversaries=4, max_cycles=100, render_mode="rgb_array")
observations, infos = env.reset()
frames=[]

while env.agents:
    frames.append(env.render())
    # this is where you would insert your policy
    actions = {agent: env.action_space(agent).sample() for agent in env.agents}

    observations, rewards, terminations, truncations, infos = env.step(actions)
env.close()

imageio.mimsave('result.gif', frames, fps=20)

I get this rendering result.

At first I don't understand why obstacles will move. Then I find pettingzoo.mpe._mpe_utils.simple_env has this function in Line 290

    def draw(self):
        # clear screen
        self.screen.fill((255, 255, 255))

        # update bounds to center around agent
        all_poses = [entity.state.p_pos for entity in self.world.entities]
        cam_range = np.max(np.abs(np.array(all_poses)))

        # update geometry and text positions
        text_line = 0
        for e, entity in enumerate(self.world.entities):
            # geometry
            x, y = entity.state.p_pos
            y *= (
                -1
            )  # this makes the display mimic the old pyglet setup (ie. flips image)
            x = (
                (x / cam_range) * self.width // 2 * 0.9
            )  # the .9 is just to keep entities from appearing "too" out-of-bounds
            y = (y / cam_range) * self.height // 2 * 0.9
            x += self.width // 2
            y += self.height // 2
            pygame.draw.circle(
                self.screen, entity.color * 200, (x, y), entity.size * 350
            )  # 350 is an arbitrary scale factor to get pygame to render similar sizes as pyglet
            pygame.draw.circle(
                self.screen, (0, 0, 0), (x, y), entity.size * 350, 1
            )  # borders
            assert (
                0 < x < self.width and 0 < y < self.height
            ), f"Coordinates {(x, y)} are out of bounds."

            # text
            if isinstance(entity, Agent):
                if entity.silent:
                    continue
                if np.all(entity.state.c == 0):
                    word = "_"
                elif self.continuous_actions:
                    word = (
                        "[" + ",".join([f"{comm:.2f}" for comm in entity.state.c]) + "]"
                    )
                else:
                    word = alphabet[np.argmax(entity.state.c)]

                message = entity.name + " sends " + word + "   "
                message_x_pos = self.width * 0.05
                message_y_pos = self.height * 0.95 - (self.height * 0.05 * text_line)
                self.game_font.render_to(
                    self.screen, (message_x_pos, message_y_pos), message, (0, 0, 0)
                )
                text_line += 1

The variable cam_range can explain why the obstacles move, but it still can not explain why two obstacles stay far away with each other at the beginning, and after some timesteps they move to collide. I do not think a moving camera can change the collision status of two actually unmoved obstacles.

In my opinion, here cam_range means the camera will move through the z-axis in 3-dimension space. I guess this problem is because only the position of entities is considered while the camera is moving, but the radius of entities should be considered, too. I don't know why you said

 # 350 is an arbitrary scale factor to get pygame to render similar sizes as pyglet

in codebase. Why the distance between two obstacles is scaled but the radius of one obstacle is not scaled. This seems strange.

Hope for your answer, thanks!

System info

• Pettingzoo installed by pip
• pettingzoo.version == 1.24.3
• OS is Ubuntu 22.04
• Python 3.10.3

Additional context

No response

Checklist

• I have checked that there is no similar issue in the repo