Объектная модель

[Freezze 1,446]

ОБЪЕКТНАЯ МОДЕЛЬ: ЗАЧЕМ ОНА НУЖНА И КАК ЕЕ ОПИСАТЬ

В своей предыдущей статье «Легкий способ написать диздок» я рассказал о том, что делю дизайн-документ на Объектную Модель и Функциональную Спецификацию. Я получил довольно много вопросов, в том числе и вопрос о том, зачем я делаю такое деление, а также в чем разница между ОМ и Функциональной Спецификацией, почему не совместить эти две части? Я начал было отвечать, но в процессе понял, что, по сути, я начал писать отдельную статью. А раз так, то лучше я напишу ее здесь.

Зачем нужна Объектная Модель (ОМ)

Кратко — чтобы в проекте не было вот этого:

Не поймите превратно. Я люблю пасту, но только в качестве еды.

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

Поэтому, Объектная Модель выполняет две важные функции:

• Справочник игровых сущностей. Его может посмотреть любой член команды без углубления в дебри дизайн-документации и долгих поисков в удобном алфавитном порядке;
  
• Структура наследования параметров. Это уже для pro, которые пишут не просто диздок, а еще и формирую архитектуру будущего проекта.
  Теперь подробнее о каждом из этих пунктов.
  

Справочник

Справочник позволяет отделить сущность и ее параметры от ее функционала. Это дает возможность быстро, одним взглядом понять как и из чего она состоит, как хранится в базе, как работает в логике игры и так далее. Такое простое восприятие сущностей позволяет программистам легко понять будущую архитектуру проекта и спроектировать то, как он будет создаваться еще до того, как они начнут воплощать его в коде. Такое четкое понимание может спасти от переработок в будущем, когда спустя год-полтора вдруг оказывается, что все работает не так, не хватает гибкости, это не предусмотрено а то вообще потребует полного рефакторинга 75% кода. Конечно, справочник ОМ — это не волшебная пилюля, но как минимизация таких рисков работает отлично при условии, что она грамотно составлена).

Кроме того, справочник позволяет сортировать игровые сущности по их типам, в то время как в Функциональной Спецификации они сортируются или описываются по функциональности. Например, у нас есть такая иерархия в ОМ:

• Игровая сущность
  
  • Предмет
    
    • Оружие
      
      • Меч
        
      • Лук
        

      [*]Расходники

      • Бутылка
        

Но при описании геймплея у нас может быть совсем иная структура. Например:

• Боевая система
  
  • Начисление урона
    
  • Работа брони
    
  • Бутылки во время боя
    
  • Стрелковое оружие
    
  • Холодное оружие
    

  [*]Крафт

  • Крафт бутылки
    
  • Крафт оружия
    
    • Стрелкового
      
    • Холодного
      

То есть получается, что, описывая ФС, мы либо в каждой статье рассказываем, какие бывают бутылки, либо делаем ссылку на описание нужной сущности. Если это описание лежит где-то в Функциональной Спецификации и является частью, например, боевой системы — а мы описываем крафт, то именно это и приведет к пастообразности диздока. В большинстве случаев такой диздок приведет к такой же архитектуре (или ее отсутствию).

И обратный пример, если у нас весь диздок отсортирован в по иерархической системе сущностей: при описании боевой системы, она будет размазана по всему диздоку.

Наследование (pro feature)

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

Пример:

• Игровая сущность (GameEntity)
  
  • Предмет (InventoryItem)
    
    • Одежда (Equipment)
      
      • Армор (Armor)
        

Ниже — как они выглядят в документации (естественно, в сокращенном виде, по 3-4 строки из ОМ):

Члены типа GameEntity (это верхняя, самая главная сущность в архитектуре проекта и то, как она хранится в БД)

Члены типа InventoryItem

Члены типа Equipment

Члены типа Armor

Как видно, Armor — это последняя сущность в приведенном примере, и имеет всего три параметра: ArmorType, DamageReduxF, DamageReduxP. Однако он наследует из предыдущей сущности: DurabilityMax, DurabilityCurrent, Tiemype. В свою очередь, та сущность наследует: Volume, PlayMoneyPrice, realMoneyPrice, и так далее до самого верха.

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

Более того, добавив какой-то новый параметр в верхнюю сущность, мы повлияем на все ее подсущности. Это существенно облегчает работу, если подсущностей, например, сто штук.

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

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

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

[Dmsrdnv 1,368]

Короче, вызываю дух Александровиса, мб ему понравится.

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