2017-02-20 5 views
1

Я создаю небольшую RPG. Персонаж имеет несколько характеристик, таких как: сила, магия, стрельба из лука и защита. Также игрок может носить снаряжение, как шлем, туловище, ноги, сапоги, перчатки и оружие. Каждое оборудование имеет свои собственные характеристики. Например, Серебряный торс имеет 10 защит.Слишком много подклассов при создании оборудования для персонажа (Ролевая игра)

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

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

Поэтому мой вопрос: что является лучшим способом производства оборудования, с меньшим количеством классов, которые более полезны. Поскольку для школьного проекта я предпочитаю использовать шаблоны проектирования. enter image description here

+1

В чем смысл специализированных классов для представления определенного типа оборудования? Я бы ожидал * все * экземпляры, например. сапоги должны быть представлены одним классом Boots. – Durandal

+1

Почему вы используете фабрики? Когда я ношу костюм, это всего лишь один костюм. –

+1

Зачем вам использовать фабрику, если вы собираетесь называть ее определенной строкой типа? Вся идея абстрактной фабрики заключается в том, что вы фактически не знаете тип или реализацию того, что вы создаете. – NickL

ответ

1

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

Вы, кажется, взрывающийся ваш дизайн не без оснований. Вся иерархия может быть заменена только одним классом, называемым Equipment.

public class Equipment { 
    private Stats stats; 
    private String equiptmentName; 

    //constructors and getters and setters follow.. 
} 

Ваш Player класс может затем быть Set из Equipment следующим образом. Вы обновляете статистику Player с помощью stats от Equipment всякий раз, когда экипировка монтируется или размонтируется.

public class Player { 
    private Set<Equipment> mountedEquipment; 
    private Stats baseStats; 

    public Player(Stats baseStats) { 
     this.baseStats = baseStats;//set base stats for player 
     mountedEquipment = new HashSet<Equipment>(); 
    } 

    public void mountEquipment(Equipment equipment) { 
      baseStats.setMagic(baseStats.getMagic()+equipment.getStats().getMagic()); 

     //update base stats similarly for strength, hitpoints, etc 
     mountedEquipment.add(equipment); 

    } 

    public void unmountEquipment(Equipment equipment) { 

     baseStats.setMagic(baseStats.getMagic()-equipment.getStats().getMagic()); 
     //update base stats in a similar fashion for strength, hitpoints, etc 
     mountedEquipment.remove(equipment); 
    } 

    public Set<Equipment> getMountedEquiptment() { 
     return Collections.unmodifiableSet(mountedEquiptment); 
    } 

} 

Вам не нужно какой-либо из Factory классов, которые вы показать в вашем вопросе, так как вы можете добавить все возможные stats к классу Equipment и Player всякий раз, когда вы вводите новый Equipment типа.

1

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

Вы можете получить представление о внутренней работе этих систем, взглянув на то, как работают моды для RPG. Например, взгляните на привязки «Papyrus» от Skyrim, или для более простого примера посмотрите на привязки lua Связывание Исаака: Возрождение.

1

я бы подойти к нему так:

есть абстрактный класс брони, что все шлем, торс и т.д. наследовать имущество. Тогда у вас может быть один класс Silver и Bronze, возможно, также объединенный под классом ArmorType. У меня был бы какой-то модификатор, основанный на каком бы оборудовании он был, например, Bronze :: modifier = 1.25; Silver :: modifier = 1.5; и т. Д. Таким образом, для каждого нового ArmorType или Armor у вас есть, t нужно добавить тонну новых классов. Это будет только ухудшаться по мере расширения игры.

Когда фактические расчеты стат сделаны в броне подклассов, он будет идти, как, например:

// Это в классе брони.

class Torso extends Armor { 

     public Torso(ArmorType armorType) { 
      this.armorType = armorType; 
      this.baseStat = 10; 
     } 

     public double calculateStats() { 
      return this.getBaseStat() * armorType.getModifier(); 
     } 
    } 

И вот пример. Если у Торса есть базовый стат из 10 доспехов, у Серебра есть модификатор 1.5, то в результате защита этой части брони будет 15. Конечно, вы можете настроить эти цифры по своему вкусу или добавить больше граней в вычисления. Это просто простой пример того, что вы можете сделать.

Если вы хотите, чтобы часть Stats вашего оригинального дизайна была включена, я бы поставил объект Stats в класс Armor. Таким образом, вы эффективно используете узор Decorator, чтобы украсить ваши классы брони с помощью ArmorTypes. Вы также просто придерживаетесь слоя между классом Stats и вашим подклассом брони.

Дайте мне знать, что вы думаете.

Смежные вопросы