Пошаговая стратегия - где хранить состояние пользователя

Question

Я пишу пошаговую стратегическую игру.У каждого игрока в игре есть команда юнитов, которой можно управлять индивидуально.На очереди пользователя игра в настоящее время следует довольно постоянной последовательности событий:

Выбор юнита -> Переместить выбранный юнит -> Выполнить команду -> Подтвердить

Я мог бы реализовать это с помощьюсоздание игрового класса, который отслеживает, на каком из этих этапов находится игрок, и предоставление методов для перехода с одного этапа на другой, например:

interface TeamCommander {
    public void select(Coordinate where);

    public void move(Coordinate to);

    public void sendCommand(String command);

    public void execute();
}

Однако это позволило бы использовать методвызывается в неподходящее время (например, звонит move() перед звонком select()), и я бы хотел этого избежать.Так что в настоящее время я реализовал его без сохранения состояния, например:

interface UnitSelector {
    public UnitMover select(Coordinate where);
}

interface UnitMover {
    public UnitCommander move(Coordinate to);
}

interface UnitCommander {
    public CommandExecutor sendCommand(String command);
}

interface CommandExecutor {
    public void execute();
}

Однако у меня возникают трудности с представлением этой информации пользователю.Поскольку это состояние без состояния, игровая модель не хранит никакой информации о том, что в данный момент делает пользователь, и, следовательно, представление не может запросить модель об этом.Я мог бы сохранить некоторое состояние в графическом интерфейсе, но это было бы плохо.Итак, мой вопрос: у кого-нибудь есть идеи о том, как решить эту проблему?

Answer 1

Во-первых, здесь есть кое-что, чего я не получаю: вам нужно хранить постоянное состояние где-то , даже если оно только в View / GUI.Без постоянного состояния вы не можете иметь игру.Я предполагаю, что вы используете либо ASP, либо PHP;если это так, используйте сеансы для отслеживания состояния.

Во-вторых, постройте свою логику состояния так, чтобы она знала, где во входной последовательности вы находитесь для каждого игрока / каждого подразделения в команде этого игрока.Не пытайся увлечься этим.B требует A, C требует B и так далее.Пока вы пишете это, просто создайте себе эшафот, выбрасывая исключения, если порядок вызовов появляется неправильно (что вы должны проверять при каждом вводе пользователем, так как я предполагаю, что это игра, управляемая событиями, а не играми, управляемыми циклами), и отладкаэто оттуда.

---

Как отступление: я становлюсь подозрительным, когда вижу интерфейсы с одним методом, как во втором примере выше.Интерфейс обычно сообщает о наличии уникальных SET функциональных возможностей, которые выполняет каждый различных классов - если только вы не пытаетесь создать несколько разных классов, которые используют несколько разные наборы отдельных сигнатур методов,не делай то, что ты там делаешь.Хорошо и хорошо говорить «код для интерфейса, а не для реализации», но сначала нужно использовать подход «сверху вниз», говоря: «Как нужен мой конечный клиентский код (в вашем классе или методе логики корневой игры)призывать к тому-то и тому-то, что происходит?и продолжайте задавать этот вопрос в стеке вызовов (т. е. в каждой последующей кодовой точке под-вызова).Если вы попытаетесь построить его снизу вверх, вы получите запутанный и излишне сложный код, который я там вижу.Единственное другое исключение из этого, которое я вижу на регулярной основе - это шаблон команд, который обычно имеет вид

void execute();

или

void execute(Object data);

... Но обычно не целый ряд слегка отличающихся сигнатур методов (опять же возможно, но маловероятно).Мои интуитивные ощущения проистекают из моего опыта с такими конструкциями в том смысле, что они обычно не имеют смысла, и в итоге вы полностью рефакторинг кода, который их использует.