Менеджер точек и игроков всяко понадобится (контейнер точек можно и отбросить, если их множество достаточно прозаично и легко описывается "плоским" множеством (т.е., достаточно простой набор без дополнительных свойств точек). Функции перемещения нужны и там, и там (в классе игрока и в классе менеджера). Здесь должны учитываться такие зависимости, может ли в одной точке находиться более одного игрока, если нет, то менеджер делает перебор контейнера (множества игроков) с целью определить доступность хода, если ход разрешён, то вызывает для конкретного игрока метод Player::MoveTo(Point &)

Проблема вообще в рзаработанности ТЗ для задачи, написано оно, например, мной, или кем-то ещё (находится в стадии постоянного пересмотра). Если в стадии пересмотра и доработки, значит, придётся менять структуру и функциональную нагрузку схемы классов (что-то добавится, а может быть, и не добавится). В случае если добавится, то структура классов и функциональная нагрузка на классы и методы должна быть максимально гибкой, но и сразу включать необходимый набор ограничений, которые, вероятней всего, понядобятся в последующем.

Например, на первоначальном этапе выбрана схема "одна точка - не больше одного игрока", а в последующем может осуществиться переход к схеме "одна точка - от нуля до бесконечного числа игроков". Так что метод самого хода прописать в класс игрока Player::MoveTo(Point & dest), а более общий метод Game::MoveTo(Player & victim, Point& dest) в классе, содержащем контейнер игроков, и этот общий метод будет проверять допустимость хода и в случае возможности вызывать


Для соображений удобства может показаться приемлемым написание что-то навроде функции

Но тут надо понимать, что раз пишется "менеджер", то на стадии неокончательной схемы классов такие функции несут в себе риск появления ошибок.

Это сообщение отредактировал(а) akizelokro - 15.12.2013, 13:06