Объектная Модель: зачем она нужна и как ее описать

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

 

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

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

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

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

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

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

Теперь подробнее о каждом из этих пунктов.

Справочник

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

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

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

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

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

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

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

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

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

Пример:

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

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

Члены типа GameEntity (это верхняя, самая главная сущность в архитектуре проекта и то, как она хранится в БД)
Описание
Тип
Имя
Рут тайп int RootType
Идентификатор сущности, уникальный в группе данного типа сущности int Id
Имя string GameName
Члены типа InventoryItem
Описание
Тип
Имя
Вес int Volume
Стоимость игровой валюты int PlayMoneyPrice
Стоимость реальной валюты float RealMoneyPrice
Члены типа Equipment
Описание
Тип
Имя
Прочность максимальная int DurabilityMax
Прочность текущая int DurabilityCurrent
Тип доспехов ItemTypes ItemType
Члены типа Armor
Описание
Тип
Имя
Тип доспехов (легкий, средний, тяжелый) ArmorTypes ArmorType
Снижение урона в единицах float DamageReduxF
Снижение урона в % float DamageReduxP

 

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

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

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

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



Мысли на тему “Объектная Модель: зачем она нужна и как ее описать” (46)

  1. Pingback: Легкий способ написать диздок | Gamedis.ru

  2. Здравствуйте!

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

    Забавно, но до большей части того что вы пишете о создании проекта я дошел сам, и был приятно удивлён, что мыслил в правильном направлении. Впрочем, у меня возник вопросы о вашей Объектной модели, и я не уверен что правильно понял как её нужно описывать. Вы бы не могли меня поправить, если я ошибаюсь?

    Как я вижу описание ОМ:

    1) Описываем все возможные свойства объекта, например, если это юнит, то: живой/неживой, стелок/мили, наземный/летающий, типы брони, типы атаки, демедж, хп, скорость атаки и т.д.

    То есть, на этом этапе мы перечисляем все возможные параметры и описываем их.

    2) При описании сущности мы пилим табличку с её свойствами по принципу родитель-ребёнок, например:

    Юнит
    —Тип брони
    ——Количество брони
    —Тип атаки
    ——Скорость атаки
    ——Урон

    И так все параметры.

    Единственное что, я не совсем понял по поводу двух вещей:
    1)»Более того, добавив какой-то новый параметр в верхнюю сущность, мы повлияем на все ее подсущности. Это существенно облегчает работу, если подсущностей, например, сто штук.»
    2)»float» , «int» — я так понял, это параметры типа «процент», «число» и т.д, не подскажете полный перечень этих обозначений?

    • Анти on 02.10.2013 at 12:02 дп ответил:

      1. Про описывание свойств, если я правильно понял вопрос: у нас есть существо (юнит). У него есть параметры табличном виде, как вы описали, например:

      | существо живое или неживое | alive | bool |

      Что мы тут видим: в пером столбце описание, что это за параметр. Во втором — название параметра. В третьем — тип параметра, в данном случае boolean, так как существо (в нашем примере) может быть или живое (1), или неживое (0)

      2. Можно и так, если удобнее. Лично мне удобнее без иерархической системы — параметров обычно у сущностей не настолько много, чтобы делать такую иерархию и обычной таблички более чем достаточно (так даже нагляднее).

      3. Про изменение параметров верхних сущностей: например, у нас есть главная сущность — GameItem, и например он имеет только один параметр — Value. У него есть дети — Weapon и Armor. Так как они его дети, они наследуют параметр Value от верхней сущности GameItem. Теперь, если мы изменим уже в игре Value, то он изменится и у Weapon, и у Armor. Но если они у например Weapon задано свое значение Value, то оно может иметь приоритет над передаваемым значением. Это уже зависит от реализации и архитектуры проекта, а также от того, какой вариант лучше. Где-то это вообще не нужно и наследуется только наличие переменных, но изменения у родителей их не затронут; такая реализация полезна, чтобы избавить документацию (да и код) от кучи лишних полей.

      4. float, int и тп — это типы данных. Рассказывать долго, почитать и понять можно тут: типы данных — статья

      Надеюсь, ответ помог и понятен. Если нет или есть еще вопросы, смело можно и нужно задавать.

    • Gamedis on 28.01.2014 at 11:30 дп ответил:

      Отвечал уже ниже:

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

      Теоретически, можно описать только ОМ, а все сущности по шаблону создавать в редакторе/вне документации (часто так происходит в продакшене), но если у вас есть время на предпродакшен и нужно написать подробный диздок, то уже конкретные экземпляры описываются в разделе контента по правилам, описанным в ОМ (шаблонах).

  3. фенрир on 04.12.2013 at 6:38 пп ответил:

    Слуште, ну а как быть с проектом, где сущностей очень много? Например, рпг с крафтом. Всё описывать — голова взорвётся. Как объектно описывать сущности в большой игре?

    • Gamedis on 04.12.2013 at 8:57 пп ответил:

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

      Если вы говорите о том, что в игре сто разных мечей, то в ОМ описывается только одна сущность — меч. А конкретные мечи описываются в другом месте, у меня этот раздел называется Контент, и там тоже есть своя структура. Но там уже в табличном виде идут все мечи, которые есть в игре, их конретные параметры, иконки, названия и все прочее, что нужно.

  4. DenisFx on 22.12.2013 at 2:29 пп ответил:

    Здравствуйте,

    Пытаясь переписывать с нуля ДизДок для соц. РПГ в правильном формате, наткнулся на этот блог…
    Перечитав Ваши статьи так и не смог для себя решить следующие вопросы касательно объектной модели:

    1. Как же описывать члены типа InventoryItem если в стоимость объекта включены помимо игровой валюты, еще и ресурсы? Скажем: шлем стоит 500 золота и 5 слитков серебра…

    2. Как делать описание для расходников (зелья доп.атаки, Зелья лечения и т.д), ведь зелья действует совсем по разному в отличии от доспехов или оружия…?

    3. Необходимо ли вообще описание параметров самого игрока? (прическа, цвет кожи, раса и т.д.) Если да, то где это необходимо описать?

    Заранее спасибо, за просвещение начинающих! )

    • Gamedis on 25.12.2013 at 6:45 пп ответил:

      Я смогу ответить нормально только а крнце января. Если не отвечу — напомните, обязательно расскажу.

      • denisfixed on 25.12.2013 at 9:39 пп ответил:

        Спасибо, буду ждать!
        Пока набросаю с учетом того что я вынес и понял со статей, может к тому времени еще вопросы выплывут )

      • Вы не ответили, а мне очень интересно, пусть я и не тот вопрошающий

        • Anti Danilevski on 12.09.2014 at 12:47 пп ответил:

          Действительно. Окей, вот ответы:

          1. Без разницы сколько чего включено в InventoryItem — хоть одна валюта, хоть сто. Ресурс, по сути — это тоже валюта. И будет InventoryItem, у которого два поля, например MoneyCost и ResourceCost.

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

          3. В ОМ необходимо указать наличие этих параметров. А что конкретно в них будет — это уже прописывается не в ОМ, а задается в редакторе (если он есть) и хранится в БД уже в самих сущностях.

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

  5. Кирилл on 19.01.2014 at 7:05 пп ответил:

    Не могли бы вы еще немножечко разжевать. Я так понял что в ОМ описывается все начиная от зелья и заканчивая финальным босом ?(способности бафы дебафы монстры и все все все? а что тогда входит в контент? чтото немогу сообразить как поделить это.

    • Gamedis on 19.01.2014 at 8:16 пп ответил:

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

  6. R(65) on 27.01.2014 at 6:38 пп ответил:

    Здравствуйте, если вас не затруднит могли бы вы вы показать более развернутый пример ОМ

    • Gamedis on 27.01.2014 at 6:59 пп ответил:

      К сожалению, времени совсем нет. Того описания, что тут есть вполне достаточно для написания своей модели.

  7. R(65) on 27.01.2014 at 7:21 пп ответил:

    Может тогда ответите:
    К примеру:

    Предмет
    Оружее
    меч
    топор
    лук
    Доспех
    Нагрудник
    сапоги

    Но если тутже начать описывать свойства их: Например двуручное одноручное прочность урон, тип урона, то получиться каша
    Предмет
    Оружее Прочность, физ урон, двуручный или одноручный,
    меч (Двуручный, наносит физ урон,)
    топор
    лук
    Доспех тип брони, Физ деф, м деф, прочность, требуемые харак ки)
    Нагрудник
    сапоги

    Вот тут я немножко запутался.

    • Anti Danilevski on 24.02.2014 at 4:47 пп ответил:

      В ОМ описываем только параметры. Например, меч:

      * Название
      * Уровень
      * Мин. урон
      * Макс. урон
      * Вес
      * Материал
      * Прочность

      Далее, в игре есть десять мечей. Это уже будут инстансы, построенные по шаблону меч. Например:

      Название: «Меч ржавый»
      Уровень: 0
      Мин. урон: 1
      Макс. урон: 2
      Вес: 0,2 кг
      Материал: сталь
      Прочность: 10

      И так далее, по каждому предмету. Это делается уже не в разделе ОМ, а в разделе «Контент» (или как вы его назовете).

      А в функциональной спецификации вы пишете то, что можно с мечом делать (я тут приведу по пунктам, но описание может быть полноценным, не списком, описывать весь функционал вообще сущности в игре):

      * Класть в сумку
      * Брать в руку
      * Убирать из руки
      * Его можно чинить
      * Может сломаться
      * Может быть куплен или продан
      * Может быть улучшен / заколдован
      * Может быть брошен в противника
      * Может иметь состояние «сломан»

      И так далее.

  8. Serge on 24.02.2014 at 3:37 пп ответил:

    R(65)

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

    • Anti Danilevski on 24.02.2014 at 3:51 пп ответил:

      Конечно, будет интересно посмотреть. В свое время я описывал ее подобным образом, когда и то, и то было в одном документе (выше — параметры, ниже — свойства и функциональное описание). Но когда сущностей очень много (за сотни), мне стало удобнее разбивать на ОМ и функционал (и программистам проще ориентироваться).Конечно, в ОМ и функционале — перекрестные ссылки.

      • Serge on 24.02.2014 at 4:40 пп ответил:

        Ну я не совсем о том. R(65) имхо имел затруднения с тем что делать сущностями, а что свойствами при построении ОМ. Вот я предложил вариант для первой итерации.

  9. Доброго времени суток!
    У меня вопрос по инструментарию — что использовать для построения архитектуры проекта — сейчас как раз приступаю к этому этапу. Использовать вики? Простые таблицы и текстовые документы? Или вообще заюзать базу данный, типа Access, для построения связей (где таблицы бд как раз будут представлять объектную модель, а записи — это уже контент, конкретные игровые объекты)
    Или есть что-то более подходящее?

  10. Artem on 09.01.2015 at 7:44 пп ответил:

    Здравствуйте, не могли бы вы на примерах немного более подробно объяснить разницу между функциональностью в ОМ и функциональной спецификацией. И спасибо за статью, очень познавательно.

    • Anti Danilevski on 12.01.2015 at 10:54 дп ответил:

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

  11. FantastM on 30.01.2015 at 12:34 дп ответил:

    Здравствуйте. Могу ли я, как то приватно с вами поговорить? Есть пару вопросов насчёт диздока, я уже работаю над ним и хочу кое что уточнить. Если вы не против конечно.

    • Anti Danilevski on 30.01.2015 at 1:33 пп ответил:

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

      • FantastM on 31.01.2015 at 8:49 пп ответил:

        Я отправил вам сообщение. За ранее благодарю за ответы.

        • Anti Danilevski on 31.01.2015 at 9:02 пп ответил:

          Ничего нет. Форму проверил — работает. Попробуйте еще раз, заодно проверим что не сработало.

          • FantastM on 31.01.2015 at 9:49 пп ответил:

            Отправил ещё раз, буквально минуту назад.

            • Anti Danilevski on 31.01.2015 at 10:38 пп ответил:

              Действительно, не приходили сообщения с некоторых адресов g-mail’a. Заменил на другую, теперь будет доходить всегда. Ваше второй раз не дошло тоже.

  12. Celas on 01.08.2015 at 9:39 пп ответил:

    Здравствуйте, Анти! В моем ДД нет раздела объектная модель (новичок, не знал), но в описании структуры игрового мира и каждой его состовляющей(я так понимаю это и есть то, что Вы называете игровая «сущность») в конце я также описываю его параметры.
    Например: состовляющая — Планета. Параметры: название, размер(кол-во места для построек), тип(от типа зависят добываемые ресурсы на планете).
    1.Это тоже, что и в ОМ описывается(только все в одном разделе), или я ошибаюсь?
    2. Как планета, ресурсы, здания, оружие и корабли, которые можно делать из ресурсов наложить на ОМ?

    Извиняюсь, если глупо звучат вопросы.

    • Anti Danilevski on 01.08.2015 at 10:13 пп ответил:

      1. Да, именно это в ОМ и описывается, плюс какие-то справочные моменты, которые а описании могут быть лишними (например, в одном из документов я в ОМ писал прямо например что-то вроде:

      — Может стрелять
      — Может быть уничтожена
      — Может развалиться на куски
      — Может быть починена

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

      2. Не совсем понял вопрос и не знаю деталей, так что наверное не смогу тут конкретики дать. Я бы просто описывал их в категории «Игровая сущность», куда они входят как обычные сущности, у которых есть требования по ресурсам. Если же в игре ВСЕ игровые сущности могут крафтиться из ресурсов, и используется наследование, то тогда у самой верхней сущности «Игровая сущность» были бы требования по ресурсам, которые наследовали бы все ее дети. Опять же, если я правильно понял вопрос.

  13. Celas on 08.08.2015 at 5:46 пп ответил:

    Спасибо, за разъяснения! Возникли еще 3 вопроса:
    1. Можно где то посмотреть более полные примеры составления наследования игровых сущностей? А то в примере всего один родитель и для меня не очень понятно выглядит как для новичка.
    2. Когда создается справочник игровых сущностей, сразу под каждой сущностью идет таблица наследования параметров, а потом возможные функции сущности? Или сперва делается справочник, потом отдельно таблица наследования параметров сущностей и под таблицей перечень функций сущности?
    3. Можно ли изобразить все сущности вместо таблицы в виде карты-мыслей(mind map)? Мне кажется на карте мыслей лучше видно наследование Объектов (Родители-Дети-внуки :)) Чем когда списоком смотришь.

  14. Celas on 11.12.2015 at 9:49 дп ответил:

    Здравствуйте, Анти!
    Вы добавляете в описание ОМ карту на которой происходят действия игры? Ведь она тоже имеет набор параметров. Или, например, внутриигровой магазин?
    Также, ветка технологий (если sci-fi), или заклинаний (если фэнтэзи)?

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

    заранее спасибо!

    • Anti Danilevski on 11.12.2015 at 11:39 дп ответил:

      Добрый день!
      Карту как сущность я бы может добавил, чтобы показать какие в ней вообще есть переменные (например, у нее может быть картинка, название, типы областей, типы поселений/строений и так далее). А вот как она работает, что с ней можно делать — я пишу в разделе Функциональная Спецификация (ФК).

      Про технологии то же самое. Если в ветке они есть и у них есть какие-то параметры, состояния, с ними что-то можно делать — то да, они должны быть в ОМ. А как все это работает, что с этим можно сделать — тоже в ФК. И перелинковать все конечно, чтобы было удобно.

  15. Byrnane on 26.03.2016 at 7:40 дп ответил:

    Насчет вики, хочу порекомендовать https://slimwiki.com Недавно нашел, очень удобный и частично бесплатный продукт

    • Anti Danilevski on 28.03.2016 at 9:30 дп ответил:

      Спасибо, изучу, хотя конфлюенс выполняет все свои задачи на 101% и переходить вряд ли буду. Но кому-то может это пригодиться.

  16. Byrnane on 07.09.2016 at 1:53 пп ответил:

    Доброго времени!
    Хотел такой вопрос задать — как отобразить в ОМ уровни прокачки или улучшения? Например, есть здание, которое можно улучшить н-раз, каждое улучшение стоит некоторое кол-во ресурсов и дает прирост к некоторым характеристикам. Можете что-нибудь посоветовать на этот счет?

  17. Здравствуйте, спасибо за статью!
    У меня возник вопрос по описанию ОМ. Рассмотрим пример с мечом выше.

    Сущность Меч:
    * Название
    * Уровень
    * Мин. урон
    * Макс. урон
    * Вес
    * Материал
    * Прочность

    Данное описание подходит очень хорошо для того, чтобы в разделе контент в данных терминах описать конкретные мечи, которые есть в игре (по сути справочник/контент).
    В итоге, данный меч (точнее его инстанс) в игре принадлежит конкретному персонажу и к нему добавляются еще ряд полей:
    * Текущая прочность
    * Улучшение на мече (может игрок заточить/улучшить предмет)
    То есть это уже игровой предмет, инстанс, созданный на основе справочной информации из сущности «Меч». Как описывать такие игровые сущности, которые имеют место быть. Отдельной сущностью? Или как?

    • Anti Danilevski on 17.02.2017 at 4:04 пп ответил:

      Я это делаю в разделе «Контент» и там может быть например подраздел «Предметы», в котором подраждел «Мечи». Там создаете «Меч деревянный» и прописываете его конкретные параметры (не надо «текущая» и тп, просто прописывается параметры прочность и тп). Соответственно, в контенте у вас получается набор мечей с базовыми характеристиками, по которым можно уже считать баланс даже на бумаге.

Добавить комментарий

Навигация