ОБЪЕКТНАЯ МОДЕЛЬ: ЗАЧЕМ ОНА НУЖНА И КАК ЕЕ ОПИСАТЬ
В своей предыдущей статье «Легкий способ написать диздок» я рассказал о том, что делю дизайн-документ на Объектную Модель и Функциональную Спецификацию. Я получил довольно много вопросов, в том числе и вопрос о том, зачем я делаю такое деление, а также в чем разница между ОМ и Функциональной Спецификацией, почему не совместить эти две части? Я начал было отвечать, но в процессе понял, что, по сути, я начал писать отдельную статью. А раз так, то лучше я напишу ее здесь.
Зачем нужна Объектная Модель (ОМ)
Кратко — чтобы в проекте не было вот этого:
Не поймите превратно. Я люблю пасту, но только в качестве еды.
Обычно про пасту любят писать и говорить программисты. Но и в дизайне тоже она может быть, и еще как. С пастообразным дизайн-документом работать крайне трудно и даже поиск по ключевым словам не всегда спасает. И даже перекрестные ссылки (в тех редких случаях, когда они расставлены) не всегда помогают, а иногда и запутывают.
Поэтому, Объектная Модель выполняет две важные функции:
Справочник игровых сущностей. Его может посмотреть любой член команды без углубления в дебри дизайн-документации и долгих поисков в удобном алфавитном порядке;
Структура наследования параметров. Это уже для pro, которые пишут не просто диздок, а еще и формирую архитектуру будущего проекта. Теперь подробнее о каждом из этих пунктов.
Справочник
Справочник позволяет отделить сущность и ее параметры от ее функционала. Это дает возможность быстро, одним взглядом понять как и из чего она состоит, как хранится в базе, как работает в логике игры и так далее. Такое простое восприятие сущностей позволяет программистам легко понять будущую архитектуру проекта и спроектировать то, как он будет создаваться еще до того, как они начнут воплощать его в коде. Такое четкое понимание может спасти от переработок в будущем, когда спустя год-полтора вдруг оказывается, что все работает не так, не хватает гибкости, это не предусмотрено а то вообще потребует полного рефакторинга 75% кода. Конечно, справочник ОМ — это не волшебная пилюля, но как минимизация таких рисков работает отлично при условии, что она грамотно составлена).
Кроме того, справочник позволяет сортировать игровые сущности по их типам, в то время как в Функциональной Спецификации они сортируются или описываются по функциональности. Например, у нас есть такая иерархия в ОМ:
Игровая сущность
Предмет
Оружие
Меч
Лук
[*]Расходники
Бутылка
Но при описании геймплея у нас может быть совсем иная структура. Например:
Боевая система
Начисление урона
Работа брони
Бутылки во время боя
Стрелковое оружие
Холодное оружие
[*]Крафт
Крафт бутылки
Крафт оружия
Стрелкового
Холодного
То есть получается, что, описывая ФС, мы либо в каждой статье рассказываем, какие бывают бутылки, либо делаем ссылку на описание нужной сущности. Если это описание лежит где-то в Функциональной Спецификации и является частью, например, боевой системы — а мы описываем крафт, то именно это и приведет к пастообразности диздока. В большинстве случаев такой диздок приведет к такой же архитектуре (или ее отсутствию).
И обратный пример, если у нас весь диздок отсортирован в по иерархической системе сущностей: при описании боевой системы, она будет размазана по всему диздоку.
Наследование (pro feature)
Составление диздока с применением наследования может значительно облегчить жизнь программистам (тем, кто при создании архитектуры игры го использует). Кроме того, это вносит ясность в саму дизайн-документацию и избавляет от перегруженности ненужными деталями.
Пример:
Игровая сущность (GameEntity)
Предмет (InventoryItem)
Одежда (Equipment)
Армор (Armor)
Ниже — как они выглядят в документации (естественно, в сокращенном виде, по 3-4 строки из ОМ):
Члены типа GameEntity (это верхняя, самая главная сущность в архитектуре проекта и то, как она хранится в БД)
Члены типа InventoryItem
Члены типа Equipment
Члены типа Armor
Как видно, Armor — это последняя сущность в приведенном примере, и имеет всего три параметра: ArmorType, DamageReduxF, DamageReduxP. Однако он наследует из предыдущей сущности: DurabilityMax, DurabilityCurrent, Tiemype. В свою очередь, та сущность наследует: Volume, PlayMoneyPrice, realMoneyPrice, и так далее до самого верха.
Таким образом, используя наследование в структуре ОМ, мы избавляемся от лишней работы — нам не нужно для каждой сущности заново прописывать все ее параметры. Мы не упустим ничего важного и снизим вероятность возможных ошибок или расхождений.
Более того, добавив какой-то новый параметр в верхнюю сущность, мы повлияем на все ее подсущности. Это существенно облегчает работу, если подсущностей, например, сто штук.
Про то, насколько облегчается программистами понимание структуры и архитектуры игры, думаю, очевидно.
Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.
Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.
Рекомендованные сообщения
ОБЪЕКТНАЯ МОДЕЛЬ: ЗАЧЕМ ОНА НУЖНА И КАК ЕЕ ОПИСАТЬ
В своей предыдущей статье «Легкий способ написать диздок» я рассказал о том, что делю дизайн-документ на Объектную Модель и Функциональную Спецификацию. Я получил довольно много вопросов, в том числе и вопрос о том, зачем я делаю такое деление, а также в чем разница между ОМ и Функциональной Спецификацией, почему не совместить эти две части? Я начал было отвечать, но в процессе понял, что, по сути, я начал писать отдельную статью. А раз так, то лучше я напишу ее здесь.
Зачем нужна Объектная Модель (ОМ)
Кратко — чтобы в проекте не было вот этого:
Не поймите превратно. Я люблю пасту, но только в качестве еды.
Обычно про пасту любят писать и говорить программисты. Но и в дизайне тоже она может быть, и еще как. С пастообразным дизайн-документом работать крайне трудно и даже поиск по ключевым словам не всегда спасает. И даже перекрестные ссылки (в тех редких случаях, когда они расставлены) не всегда помогают, а иногда и запутывают.
Поэтому, Объектная Модель выполняет две важные функции:
Теперь подробнее о каждом из этих пунктов.
Справочник
Справочник позволяет отделить сущность и ее параметры от ее функционала. Это дает возможность быстро, одним взглядом понять как и из чего она состоит, как хранится в базе, как работает в логике игры и так далее. Такое простое восприятие сущностей позволяет программистам легко понять будущую архитектуру проекта и спроектировать то, как он будет создаваться еще до того, как они начнут воплощать его в коде. Такое четкое понимание может спасти от переработок в будущем, когда спустя год-полтора вдруг оказывается, что все работает не так, не хватает гибкости, это не предусмотрено а то вообще потребует полного рефакторинга 75% кода. Конечно, справочник ОМ — это не волшебная пилюля, но как минимизация таких рисков работает отлично при условии, что она грамотно составлена).
Кроме того, справочник позволяет сортировать игровые сущности по их типам, в то время как в Функциональной Спецификации они сортируются или описываются по функциональности. Например, у нас есть такая иерархия в ОМ:
[*]Расходники
Но при описании геймплея у нас может быть совсем иная структура. Например:
[*]Крафт
То есть получается, что, описывая ФС, мы либо в каждой статье рассказываем, какие бывают бутылки, либо делаем ссылку на описание нужной сущности. Если это описание лежит где-то в Функциональной Спецификации и является частью, например, боевой системы — а мы описываем крафт, то именно это и приведет к пастообразности диздока. В большинстве случаев такой диздок приведет к такой же архитектуре (или ее отсутствию).
И обратный пример, если у нас весь диздок отсортирован в по иерархической системе сущностей: при описании боевой системы, она будет размазана по всему диздоку.
Наследование (pro feature)
Составление диздока с применением наследования может значительно облегчить жизнь программистам (тем, кто при создании архитектуры игры го использует). Кроме того, это вносит ясность в саму дизайн-документацию и избавляет от перегруженности ненужными деталями.
Пример:
Ниже — как они выглядят в документации (естественно, в сокращенном виде, по 3-4 строки из ОМ):
Члены типа GameEntity (это верхняя, самая главная сущность в архитектуре проекта и то, как она хранится в БД)
Члены типа InventoryItem
Члены типа Equipment
Члены типа Armor
Как видно, Armor — это последняя сущность в приведенном примере, и имеет всего три параметра: ArmorType, DamageReduxF, DamageReduxP. Однако он наследует из предыдущей сущности: DurabilityMax, DurabilityCurrent, Tiemype. В свою очередь, та сущность наследует: Volume, PlayMoneyPrice, realMoneyPrice, и так далее до самого верха.
Таким образом, используя наследование в структуре ОМ, мы избавляемся от лишней работы — нам не нужно для каждой сущности заново прописывать все ее параметры. Мы не упустим ничего важного и снизим вероятность возможных ошибок или расхождений.
Более того, добавив какой-то новый параметр в верхнюю сущность, мы повлияем на все ее подсущности. Это существенно облегчает работу, если подсущностей, например, сто штук.
Про то, насколько облегчается программистами понимание структуры и архитектуры игры, думаю, очевидно.
Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.
Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.
Опубликовано Freezze,
Закреплено Strаtegium