Наследование / Дизайн интерфейса игры

Question

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

Я пытаюсь смоделировать парусные суда - подумайте, Эпоха Паруса.Предположительно поэтому все расширяет класс судна.

Существует несколько типов судов: гребная (камбузы, каноэ), квадратная, передняя и задняя части, с различным поведением.Каждый из них подразделяется на несколько других типов.Я не могу решить, должна ли это быть серия интерфейсов или расширений Vessel.Заметьте также, что может быть некоторый переход (судно может быть как гребным, так и квадратным), что заставляет меня думать, что интерфейсы?

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

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

Моя большая проблема в том, что каждый стиль корабля (фрегат, линкор и т. Д.) Может выполнять практически любую из этих ролей, поэтому я не могу построить простое телоструктура наследования.Фрегат не может продлить войну, потому что некоторые из них - каперы.Шлюп не может вытянуть квадратную оснастку, потому что некоторые из них носовые и кормовые.etcetc.

Любые мысли будут оценены по достоинству, я немного не в себе.Спасибо

Answer 1

Сделать часть "поведения" интерфейсом. Это поможет вам без проблем назначить разное поведение на разные корабли. Шаблон стратегии полезен здесь. В двух словах, он утверждает, что изменяемые и постоянные свойства должны быть разделены.

Для различных средств движений композиция звучит как самый подходящий ответ на данный момент.

Относительно "но может работать во флотах, эскадронах или независимо. Частники и пираты атакуют только в случае слабости - обычно независимо, но иногда парами". частично, я думаю, это не имеет ничего общего с деревом наследования. Вы можете создавать «группы» классов в зависимости от ваших потребностей.

Это может помочь вам:

«Тогда существует несколько типов стиля судна: ...» определяет различные возможные варианты поведения. Так что интерфейс «Подвижный» и его подклассы для этого. В классе «Судно» вы можете иметь члена типа «Подвижный». Поскольку «Movable» является интерфейсом, любой класс, который его реализует, назначается этому члену. Таким образом, любой подкласс Vessel может иметь любое возможное поведение, которое мы также можем изменить во время выполнения. Вы также можете сделать это ArrayList. (Не уверен, если вы действительно хотите сделать это или нет). Но если вам нужно несколько вариантов поведения для одного и того же судна, вы можете это сделать.

Когда вы говорите «Корабли также ведут себя по-разному: ...», создается впечатление, что отдельные классы, расширяющие Судно, будут удовлетворять этому требованию. Тем не менее, предложение «В данном случае пересечения типов не существует». облегчает жизнь.

Для параграфа «Наконец, есть несколько вариантов поведения, которые могут иметь отдельные корабли ...», вы должны добавить еще одного члена для различных возможных вариантов поведения. В основном это будет ArrayList, поскольку у одного судна будет несколько режимов атаки.

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

Answer 2

Я хочу дать несколько советов, основываясь на втором абзаце ответа Бхусана, который я цитирую здесь полностью:

«Относительно», но может работать во флотах, эскадронах или независимо. Каперы и пираты атакуют только в случае слабости - обычно независимо, но иногда парами. «Думаю, это не имеет ничего общего с деревом наследования. Вы можете создавать« группы »классов в зависимости от ваших потребностей».

Это наводит меня на мысль, что вы, возможно, захотите рассмотреть составной шаблон для определенных групп кораблей, по крайней мере тех, которые состоят из кораблей, которые ведут себя одинаково. См. http://en.wikipedia.org/wiki/Composite_pattern, где написано, что «составной шаблон описывает, что группа объектов должна обрабатываться так же, как один экземпляр объекта».

Например, вы говорите: "Торговцы могут быть в конвое (защищаться)", но, по-видимому, они могут защищать себя и индивидуально? Конечно, все проще сказать, чем сделать, и я советую вам не задумываться над этим и начать с очень небольшого подмножества того, что вы хотите сделать как прототип

Answer 3

Хорошо, вот несколько идей:

• Суда имеют одно или несколько средств движения (весла, паруса и т. Д.), Которые вы можете смоделировать по составу (например, иметь список методов движения).
• Суда используют одну из множества стратегий (используйте шаблон стратегии - см. http://en.wikipedia.org/wiki/Strategy_pattern - для этого)
• Стратегиям, которые зависят от присутствия других близлежащих кораблей, потребуется какой-то способ запроса этих других кораблей - поэтому вам понадобится какая-то структура данных, которая позволяет вам найти, какие объекты находятся рядом с какими другими объектами (посмотрите на вид структур данных, которые используются для обнаружения столкновений в широкой фазе)

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

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

Возможно, вы захотите посмотреть здесь, если вас интересует такой подход:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Answer 4

Вы не должны расширять класс судна.Скорее, объект Vessel должен содержать другие объекты, которые его описывают.(Это известно как инъекция зависимости, чтобы быть досадно педантичной - забудь, что я это сказал.) У вас есть класс Propulsion, с примерами для паруса, носа и хвоста и весла.Вы могли бы хотеть специальные экземпляры каждого для больших и маленьких корпусов.У вас есть класс поведения, чтобы справиться с их отношением.Иногда простое целое число работает так же, как класс.Вместо этого ваш класс вооружения может состоять из нескольких орудий.(Или два числа, по одному на фунт.) Если вы планируете таранить или у вас есть корабль, загруженный ракетами, или вам необходимо различать длинные пушки и карронады, вам, возможно, придется вернуться к использованию класса.

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

Answer 5

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

Например: Корабль имеет Поведение.(Состав ... корабль делегирует поведение, чтобы определить, как реагировать на ситуацию X) *

Пират - это Поведение (Наследование от интерфейса Поведения) ...

Answer 6

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