Подтвердить что ты не робот

Монопольная игра в OOD?

Я нашел это интересное сообщение в блоге через CodingHorror: Мой любимый вопрос о интервью. В двух словах он рассказывает об объектно-ориентированных задачах проектирования разработки игры в монополии с упором на то, как моделировать правила игры. Например, "Если игрок владеет Балтийским проспектом, может ли она добавить к нему дом?"

Интересно, что в нижней части сообщения он пишет:

Вероятно, вы можете сэкономить много времени на интервью. Вместо всего этого hoopla попросите кандидата описать, когда они фактически использовали шаблоны Strategy, Visitor и Command вне рамки.)

... что, вероятно, означает, что вы можете использовать шаблоны проектирования для моделирования правил игры (см. выше). Кто-нибудь когда-либо делал это? Разработал игру Монополии с использованием шаблонов дизайна? Если да, то как это получилось?

4b9b3361

Ответ 1

Вот как я хотел бы создать монополию. Я взял на себя смелость принять язык с динамически типизированным языком, поскольку это облегчает процесс. Ruby специально.

У вас есть простой объект Game, в основном обертка вокруг Array размером 40 и некоторые удобные методы. Объект Game также отслеживает количество доступных houses и hotels и двух стеков карт шанса и сообщества. Предусмотрено несколько удобных методов, таких как current_turn и next_turn! - оба возвращают объект Player; next_turn! увеличивает индекс поворота, при необходимости обертывая на 0.

Все места, в которые игрок может приземлиться, должны наследовать от суперкласса Property. Класс Property определяет несколько общих вещей, таких как rent, owner, set, houses, purchasable? и upgradeable?. Свойства rent и owner могут быть nil. Свойство set возвращает Array, содержащий все свойства внутри группы. Свойство set может варьироваться в размере от 1 до 4. Свойство houses представляет отель как 5 'домов'.

Объект Game имеет Array объектов Player, каждый с такими полями, как position (целое число от 0 до 39), money (нет верхней границы - банк технически никогда не заканчивается of money '), get_out_of_jail_frees и in_jail? (так как для этого недостаточно места). Объект Game также имеет индекс для отслеживания своего хода.

Правила, специфичные для свойства, кодируются в пределах их соответствующих подклассов. Так, например, реализация rent на a Railroad будет:

def rent
  owned_count = self.set.select { |rr| rr.owner == self.owner }.size
  return 25 * 2 ** (owned_count - 1)
end

Карты шанса и сообщества Chest могут быть просто реализованы с кучей замыканий, в результате чего игра и объект игрока будут параметрами. Например:

# Second place in a beauty contest
COMMUNITY_CHEST_CARDS << lambda do |game, player|
  player.money += 10
end

# Advance token to Boardwalk
CHANCE_CARDS << lambda do |game, player|
  game.advance_token!(player, 39)
end

# Advance token to nearest railroad, pay double
CHANCE_CARDS << lambda do |game, player|
  new_position = [5, 15, 25, 35].detect do |p|
    p > player.position
  end || 5
  game.advance_token!(player, new_position)
  # Pay rent again, no-op if unowned
  game.properties[new_position].pay_rent!(player)
end

И так далее. Метод advance_token!, очевидно, обрабатывает такие вещи, как передача go.

Очевидно, что есть более подробная информация - это довольно сложная игра, но, надеюсь, это дает вам правильную идею. Это было бы более чем достаточно для интервью.

Update

Правила дома можно включить или выключить, добавив house_rules Array к объекту Game. Это позволит реализовать свойство FreeParking следующим образом:

class Game
  def house_rules
    @house_rules ||= []
  end

  def kitty
    # Initialize the kitty to $500.
    @kitty ||= 500
  end

  def kitty=(new_kitty)
    @kitty = new_kitty
  end
end

class FreeParking < Property
  def rent
    if self.game.house_rules.include?(:free_parking_kitty)
      # Give the player the contents of the kitty, and then reset it to zero.
      return -(_, self.game.kitty = self.game.kitty, 0)[0]
    else
      return 0
    end
  end
end

Ответ 2

Я думаю, что вы здесь ошибаетесь.

...which probably means that you can use design patterns to model the rules of the game (see above). 

Я думаю, это просто показывает, что вы действительно не понимаете, какие шаблоны дизайна. Известные шаблоны проектирования - это просто имена, которые мы приводим к повторяющимся ситуациям при кодировании. В вашей повседневной жизни вы никогда не говорите: "Я проснулся в 8 утра, чтобы поехать в 9 утра, чтобы разместить X, программируя весь день до 5 вечера, чтобы они заплатили мне до конца месяца". Вы говорите: "Сегодня я был на работе". У вас есть проблема желания зарабатывать деньги, и текущие решения этой проблемы будут работать. Итак... у нас есть образец здесь! Позвольте называть его "Рабочим"!

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

Возвращаясь к

...which probably means that you can use design patterns to model the rules of the game 

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

Ответ 3

Я никогда не разрабатывал правила монополии (слишком легко, понятно), но я потрудился писать машины для других известных игр для личного удовольствия и с пониманием, что все это академическое упражнение.

Две игры, которые я пытался смоделировать (и продолжать пытаться), D & D и М:. Т.Г.

С D & D акцент делается на очень хороший дизайн OO - создание классов и иерархий классов, которые имеют смысл.

С M: tG, вы в основном понимаете, что прямая парадигма OO является неполной для такого рода вещей. В итоге вы работаете с агентами, брокерскими событиями и создаете действительно сложные наборы правил.

Все это довольно бессмысленно, если вы не дизайнер игр. Хорошо, однако.