Repository role in active record design

While developing a game, I've came across an interesting situation.

I'm using the active record design pattern on a very complex model object, let there be a player :

<?php 
class Player{

    function __construct($playerRepo)
    {
         $this->playerRepo = $playerRepo;
    }

    function instantiateByID($playerID)
    {
    $this->playerRepo->getPlayerByID($playerID);
    }

    function save()
    {
        $this->playerRepo->save($this);
    }

}
?>

So the player object requires a repo(or manager, or however you decide to call it), this is basically a gateway to a persistence layer which is abstracted.

While this violates the SRP principle(an argument against AR in general), It makes "sense" as the player is a self sustained entity, It can instantiate itself, save itself and do whatever is needed, with all the good business logic.

The question at hand though, is what entity can I ask for more general information not specific to the current player.

This is obviously bad :

$player->checkIfPlayerNameExists($str);

The player should have no notion of the world or even know there are other players.

The player object itself is created through some factory, however notice that I don't need any concrete information to instantiate a Player. I can create a new object, Fill it with data and then persist it.

So the questions :

1. Given that all precondition checks should be inside the Player's save() method, through what interface should those checks take place? Should the Player have the ability to check all the names in the game?

2. Assuming I want a collection of Players (ranking for example), what entity should be in charge of that? in DDD we have Repositories, but I'm not sure how that fits in AR design pattern.

Thanks!