Запрос о дизайне текстовой приключенческой игры на основе классов.

Ответ 1

Как насчет класса "Игра", который будет содержать большую часть информации, например, игрока и текущей комнаты. Для такой операции, как перемещение игрока, класс игры может переместить игрока в другую комнату на основе карты уровня комнаты.

Класс игры будет управлять всеми взаимодействиями между различными компонентами игр.

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

UDPATE:

Чтобы сделать код более управляемым, вы могли бы моделировать некоторые из взаимодействий между основными классами как сами классы, такие как класс боя. Используйте интерфейсы, чтобы ваши основные классы могли выполнять определенные взаимодействия. (Обратите внимание, что я взял на себя смелость придумать несколько вещей, которые вы, возможно, не захотите в своей игре).

Например:

// Supports existance in a room.
interface IExistInRoom { Room GetCurrentRoom(); }

// Supports moving from one room to another.
interface IMoveable : IExistInRoom { void SetCurrentRoom(Room room); }

// Supports being involved in a fight.
interface IFightable
{
  Int32 HitPoints { get; set; }
  Int32 Skill { get; }
  Int32 Luck { get; }
}

// Example class declarations.
class RoomFeature : IExistInRoom
class Player : IMoveable, IFightable
class Monster : IMoveable, IFightable

// I'd proably choose to have this method in Game, as it alters the
// games state over one turn only.
void Move(IMoveable m, Direction d)
{
  // TODO: Check whether move is valid, if so perform move by
  // setting the player location.
}

// I'd choose to put a fight in its own class because it might
// last more than one turn, and may contain some complex logic
// and involve player input.
class Fight
{
  public Fight(IFightable[] participants)

  public void Fight()
  {
    // TODO: Logic to perform the fight between the participants.
  }
}

В вашем вопросе вы определили тот факт, что у вас будет много классов, которые должны знать друг о друге, если вы застряли что-то вроде метода Move в своем классе Player. Это происходит потому, что что-то вроде движения не принадлежит игроку или комнате - этот шаг затрагивает оба объекта взаимно. Путем моделирования "взаимодействий" между основными объектами вы можете избежать многих из этих зависимостей.

Ответ 2

Звучит как сценарий, в котором я часто использую класс Command или Service class for. Например, я могу создать класс MoveCommand, который выполняет операции и координацию между Уровнями и Лицами.

Этот шаблон имеет то преимущество, что он обеспечивает соблюдение Принципа единой ответственности (SRP). SRP говорит, что у класса должна быть только одна причина для изменения. Если класс Person ответственен за его перемещение, у него, несомненно, будет несколько причин для изменения. Разбирая логику "Переместить" в свой класс, он лучше инкапсулируется.

Существует несколько способов реализации класса Command, каждый из которых лучше подходит для разных сценариев. Классы команд могут иметь метод Execute, который принимает все необходимые параметры:

 public class MoveCommand {
    public void Execute(Player currentPlayer, Level currentLevel) { ... }
 }

 public static void Main() {
     var cmd = new MoveCommand();
     cmd.Execute(player, currentLevel);
}

Или иногда я нахожу его более простым и гибким, чтобы использовать свойства в объекте команды, но это облегчает для клиентского кода неправильное использование класса, забыв установить свойства - но преимущество в том, что у вас есть тот же функциональную подпись для Execute для всех классов команд, поэтому вы можете создать интерфейс для этого метода и работать с абстрактными командами:

 public class MoveCommand {
    public Player CurrentPlayer { get; set; } 
    public Level CurrentLevel { get; set; }
    public void Execute() { ... }
 }

 public static void Main() {
     var cmd = new MoveCommand();
     cmd.CurrentPlayer = currentPlayer;
     cmd.CurrentLevel = currentLevel;
     cmd.Execute();
}

Наконец, вы можете предоставить параметры как аргументы конструктора классу Command, но я откажусь от этого кода.

В любом случае я нахожу использование Commands или Services очень мощным способом обработки операций, таких как Move.

Ответ 3

Для текстовой игры вы почти наверняка будете иметь объект CommandInterpretor (или аналогичный), который оценивает введенные пользователем команды. При таком уровне абстракции вам не нужно выполнять все возможные действия над вашим объектом Player. Ваш интерпретатор может подтолкнуть некоторые напечатанные команды к вашему объекту Player ( "показать инвентарь" ), некоторые команды для текущего объекта сектора ( "list exits" ), некоторые команды для объекта Level ( "move player North" ), а некоторые команды к объектам специальности ( "атака" может быть перенесена в объект CombatManager).

Таким образом, объект Player становится больше похожим на Character, а CommandInterpretor более репрезентален от фактического человека, сидящего на клавиатуре.

Ответ 4

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

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

Уровень "содержит" все в нем. Вы можете начать там. Уровень не обязательно должен вести все, но все находится на уровне.

Игрок может двигаться, но только в пределах уровня. Поэтому игроку необходимо запросить уровень, чтобы увидеть, действительно ли направление движения.

Уровень не берет предметы у игрока и не наносит урона. Другие объекты на уровне делают эти вещи. Эти другие объекты должны искать игрока или, возможно, рассказывать о близости игрока, а затем они могут делать то, что хотят прямо от игрока.

Это нормально для уровня, чтобы "владеть" игроком и для игрока иметь ссылку на его уровень. Это "имеет смысл" с точки зрения ОО; вы стоите на Планете Земля и можете влиять на нее, но она тащит вас по вселенной, пока вы копаете дыры.

Простые вещи. Каждый раз, когда что-то осложняется, выясните, как сделать его простым. Простой код легче работать и более устойчив к ошибкам.

Ответ 5

Итак, во-первых, это хороший способ сделать это?

Абсолютно!

Во-вторых, если глава делегата была не было представлено так, как было, я бы не подумали об использовании таких 'Мероприятия'. Так что было бы хорошим способом реализовать это без использования обратные вызовы?

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