Легкий способ написать дизайн-документ

labyrinth

Картинка: фильм «Labyrinth»  by Disney, 1986

Предисловие

Нет, конечно это никакой не легкий способ, а я — не Аллен Карр. Написать полноценный и подробный диздок — это адов труд и требует огромной концентрации, усидчивости и упорства.

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

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

Последовательность

Пустая страница. Если вы ее видите, это хороший знак: значит, скорее всего, у вас уже есть что-то, что вы хотите там записать. Начните с самого простого, с того, что у вас есть — с идеи.

 

 

Light-Bulb-3

Идея

Сейчас идею можно записать как угодно просто, без каких-либо  проработок, любым языком и стилем, с любым количеством ошибок. Главное, чтобы она цепляла и была бы легко понятна. Скорее всего, на этом этапе она не финальная и может много раз измениться: что-то будет дополнено, что-то убрано или переделано. Это нормально, потому что во время проработки деталей, которые будут происходить далее, геймдиз будет не только описывать функционал, но и автоматически проводить экспертизу на пригодность, работоспособность и жизненность описываемых моментов. Но идея — это всегда самый главный отправной пункт, из которого легче всего стартовать. Кроме того, изложение идеи в тексте позволяет взглянуть на нее более объективно и, возможно, увидеть ее слабые места. Часто идея в голове и идея на бумаге отличаются.

 

 

mediat-list-icon

Список основных фич игры  и USP

Каждая игра включает в себя набор каких-то фич, которые формируют геймплей. Среди этих фич есть самые-самые, называемые USP — Unique Selling Points. Как сказал кто-то, уже не помню кто, но что мне запомнилось и очень понравилось: «USP — это то, что можно привести в пример во время рассказа об игре одним игроком другому. Например, рассказывая о Prince of Persia: The Two Thrones, он может сказать: «у героя есть там такой хлыст, состоящий из лезвий, которым он всех красиво рвет на клочки!» — и собеседник сразу же живо это представит (или моментально поймет, о какой игре идет речь).

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

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

 

 

a_unknown

Определение ЦА (целевой аудитории) игры

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

Просто запишите тут, кто ваш основной игрок, если получилось его выделить. Ответ «Все!» не подходит. Описание ЦА может выглядеть так:

Мужчины в возрасте 25-50 лет, увлекающиеся военной тематикой и периодом Великой Отечественной Войны, а также любители шутеров, мужчины от 14 до 20 лет. И те, и другие — обладатели приставки Х.

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

Понимание вашей ЦА даст понимание того, какова вообще ваша потенциальная аудитория, нишевая ли ваша игра, насколько хардкорны или казуальны игроки и как строить для них геймплей, насколько он должен быть простым или сложным; какую выбрать систему монетизации, какие должны быть цены в игре, если это ф2п, и так далее.

 

 

1_Оглавление 2

Дизайн-документ — оглавление

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

  1. Объектная Модель
  2. Функциональная спецификация
  3. Контент игры
  4. Интерфейс
  5. Монетизация
  6. Виральность (если предусматривается)
  7. Техническая спецификация
  8. База знаний (ссылки)

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

Например, вот так выглядит описание сущности Equipment из одного моего рабочего проекта:

Члены типа Equipment
Описание
Тип
Имя
Прочность максимальная int DurabilityMax
Прочность текущая int DurabilityCurrent
Тип доспехов (влияет на то, может ли тот или иной класс использовать этот предмет, или может но с пенальти или наоборот, с бонусами) ArmorTypes ArmorType
Апгрейд (уровень апгрейда) int UpgradeLevel
Модификатор урона float ModDam
Модификатор ХП float ModHP
Модификатор регенерации ХП float ModHPregen
Модификатор маны float ModEP
Модификатор регенерации маны float ModEPregen
Модификатор скорости бега float ModMove
Модификатор скорости атаки float ModAttackSpeed
Модификатор скорости парирования float ModParrySpeed
Модификатор скорости защит щитом float ModShieldSpeed
Свойство (бафф, который вешается на персонажа когда предмет одет на персонажа) ItemAffects ItemAffect
 Функциональность
  • Может быть одета на персонажа или снята
  • Одевается только в предназначенный ей слот (определяется типом одежды)
  • Может быть куплена/продана в магазине
  • Может быть потеряна при смерти
  • Может терять прочность
  • Ломается, когда прочность достигает 0
  • Когда сломана, параметры одежды становятся единицами (0 то они до единиц не повышаются)
  • Может быть починена, при этом максимальная прочность снижается перманентно
  • Может быть улучшена, при этом определенные параметры повышаются (зависит от улучшения), улучшения перманентные
  • Может иметь баф, который влияет на параметры персонажа когда предмет одет
  • Может иметь набор особых свойств (ItemAffect). Например, привязка при взятии, привязка при одевании, проклятое, благословенное и другие


2. Функциональная
спецификация описывает геймплей, что как работает, поштучно. Как работает персонаж и что умеет делать, как работает бутылка, как работает баф, и так далее. Это правила игры, по которым существуют игровые сущности. Здесь — все механики игры, от входа в игру и того, как происходит регистрация, до того, как формируется рейтинг или как считать удар в боевой системе.

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

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

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

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

6. Виральность сейчас становится неотъемлемой частью даже не социальных игр. Если вы планируете  реализовывать ее в игре, то здесь описываются все ее механики: способы, которыми друзья приглашают своих друзей и то, почему они работают; как это должно быть реализовано; какие есть оповещения и в каких случаях, их тексты; какие существуют бонусы, что и когда пишется на стены в соцсетях и так далее.

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

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

8. База знаний — раздел для хранения всего полезного. Статей, ссылок, референсов, статистических данных, видео, контактов и так далее. Полезно всем, кто работает с проектом.

Детализация оглавления

После того, как верхний уровень оглавления сформирован, пишутся подразделы, затем их подразделы и так далее. На выходе вы должны получить подробный скелет дальнейшего диздока. Фактически, это еще и план работ. Сразу же никогда не получится сделать его абсолютно точным и финальным. Даже более того, оглавление будет перерабатываться еще не один раз, и это тоже нормально, нужно быть готовым. Составление такого оглавления прекрасно помогает осознать объем предстоящей работы и проясняет сознание геймдиза.

 

 

1_birds-flying-silhouette-clip-art

Описание (питч)

После того, как сформировано оглавление, можно сделать передышку от рутины и довольно сложной аналитической работы, и переключиться на что-то более литературное. Например, на питч.

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

Есть много литературы о том, как это делать правильно, а вот замечательный ресурс Gamepitches, на котором можно прочитать огромное количество питчей и посмотреть, как это делают профессионалы из игровой индустрии.

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

 

 

1_microscopes

Детализация диздока

После небольшого отдыха во время работы над питчем, наступает самое сложное: детализация и проработка скелета, формирование уже самое плоти. Это — самое сложное, так как требует максимальной целеустремленности, концентрации и умения видеть, представлять конечный продукт. Здесь будет возникать огромное количество вопросов, над которыми придется много думать и выбирать наилучшие решения, прежде чем записывать ответ. На этом этапе ломается больше половины желающих стать геймдизами (по крайней мере из тех, что я встречал).

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

При первоначальном написании «мяса» я делаю 3-4 быстрых прохода по всем разделам. В первый я описываю все в общих чертах на уровне концепций. Во второй я добавляю деталей, делаю все более четко, дорабатываю те моменты, которые были непонятны. В третий проход я убираю лишнее и делаю текст более лаконичным и кратким, дорабатывая детали и нюансы. Но даже сейчас диздок еще далек от финала, потому что не создана объектная модель.

 

 

1_skeleton

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

Объектную модель я уже пишу в вики. Из всех вики (я изучил около пятидесяти разных), мне больше всего подошла Atlassian Confluence. Лицензия до 10 человек стоит около 300 рублей в месяц, но и даже для одного человека (геймдиза) оно того стоит.

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

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

 

 

689322_120500217

Проработка разделов и перенос их в вики

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

 

 

1_vision

Подробный вижен для команды

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

Затем, ради интереса (и если вы добрались до этого этапа), можете сравнить этот вижен и вашу первоначальную идею, с которой все начиналось.



Мысли на тему “Легкий способ написать дизайн-документ” (37)

  1. Pingback: С чего начинать разработку: с игровой вселенной или с геймплея? | Gamedis.ru

  2. Pingback: С чего начать путь гейм-дизайнера? | Gamedis.ru

  3. Pingback: Хак: как начать разработку своей собственной игры | Gamedis.ru

  4. Pingback: Об организации работы: поток сознания, пирамида Маслоу и ачивки

  5. Влад on 01.12.2013 at 12:31 дп ответил:

    А на каком этапе следует прописать сюжет и последовательность событий в целом?

    • Gamedis on 09.12.2013 at 2:18 пп ответил:

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

  6. фенрир on 09.12.2013 at 2:15 пп ответил:

    Можете привести пример ОМ в вики? Несколько фрагментов? Хочу понять, как вы связываете сущности.

  7. Михаил on 19.02.2014 at 7:41 дп ответил:

    Добрый день.

    Большое спасибо за такую интересную и познавательную статью и за ваш блог в целом — такого количества полезной информации на единицу площади экрана я давно уже не видел.

    Моя профессиональная деятельность не совсем пересекается с геймдевом, я занимаюсь сайтами. После прочтения вашей статьи возникла мысль применить дизайн-документ для разработки сайта. Разумеется, в этой области есть своя специфика, но главная идея — посетитель должен получать от сайта фан — как я считаю, присутствует. Поэтому воспринять посетителя как игрока, мне думается, для определенной категории сайтов вполне возможно и даже выигрышно. Было бы очень интересно узнать ваше мнение о таком использовании подходов из геймдева 🙂

  8. Илья on 15.09.2014 at 3:39 пп ответил:

    Доброго времени суток!

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

    Заранее благодарю.

    • Anti Danilevski on 15.09.2014 at 3:44 пп ответил:

      Наверняка есть где-то, которые не под НДА. Я помню, что лет сто назад 1С (вроде бы) публиковали пример диздока. Можно поискать, что-то найти. Но в принципе того, что есть про структуру диздока вполне достаточно для написания своего.

  9. Илья on 15.09.2014 at 5:30 пп ответил:

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

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

  11. ivan on 22.05.2015 at 12:27 пп ответил:

    День добрый. Мой опыт программирования — это бейсик в техникуме в 93м году, и написание сценариев на LUA к первому «Блицкригу». Исучать спецтерминологию Си++ для меня сейчас, на той фазе разработки нашего проекта, где она находится сейчас, мягко скажем, не совсем своевременно. Делаем браузерную пошаговую карточную онлайн PvP «Free to play» стратегию в научно-фантастическом сеттинге, на энтузиазме. Художник и программист есть.
    Если я описываю свойства контента в екселе и ворде, и членам команды всё понятно, значит ли это, что нужно всё бросить и переводить десятки уже готовых документов в Atlassian Confluence, если я его раньше в галза не видел?

    • Anti Danilevski on 22.05.2015 at 12:52 пп ответил:

      Я бы не стал, нет. Даже новую документацию по текущему проекту наверное не стал бы там писать. Может какие-то справочные материалы, нужные всем в онлайн доступе, там бы начал сохранять, и то не факт.

      • ivan on 22.05.2015 at 3:35 пп ответил:

        Но в целом спасибо, скачаю обязательно Atlassian Confluence. и Atlassian JIRA, и по мере наличия времени, освою для реализации, даст Бог, других проектов.

  12. Александр on 17.06.2015 at 12:35 пп ответил:

    А есть ли какие-то бесплатные, но не плохие вики, если можно ссылочку.

    • Anti Danilevski on 17.06.2015 at 12:41 пп ответил:

      Наверняка есть, но я для себя удобной бесплатной альтернативы не нашел (хотя в свое время я задавался такой целью и прошертсил штук 30 разных вики).

  13. Celas on 01.08.2015 at 6:26 пп ответил:

    Здравствуйте, Анти! Я без двух недель гейм-дизайнер и моя задача — написать диздок по существующей альфа-версии игры для ее дальнейшей разработки. Я стараюсь изо всех сил с самого начала писать диздок как можно правильней для всей комнады.
    Во-первых, огромное спасибо, за легко воспринимаемый и интересный материал! И все же есть пару вопросов. Не понятно, что за «вики» упоминается в разделе «Объектная модель»? Почему именно Atlassian Confluence? Я правильно понимаю, что «вики» где ОМ и сам диздок — это в итоге два отдельных документа получаются?

    Я работаю в Google docs (альтернатива MS Word, но с возможностью шарить документ для всей команды)

    • Anti Danilevski on 01.08.2015 at 6:43 пп ответил:

      Спасибо за отзыв, рад что полезно и помогло.

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

      На мой взгляд, гугл доки для диздока — это очень ограниченное и скудное решение, которое при увеличении объема контента/расширении команды сыграет плохую службу. Ни интеграции с трекером, ни удобной структуры, ни простой и быстрой установки перекрестных ссылок — в общем, я бы не стал, чтобы потом все не пришлось переделывать.

      • Celas on 01.08.2015 at 9:05 пп ответил:

        спасибо, за быстрый ответ и мнение!
        Для инди-игры возможно Гугл док достаточно будет. Да и значительная часть нашего ДД уже там написана и не уверен, что меня не «пошлют» с моей инициативой переезда куда-то. Но,Atlassian Confluence обязательно попробую, тем более там 7 дней бесплатно.
        Есть еще вопросы по составлению ОМ. Задам позже в соответсвующей теме про ОМ. Еще раз спасибо!

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

          Не за что. Конфлюенс стоит $10/месяц, по-моему это совсем не те деньги даже для инди-команды, чтобы экономить. А переносить или нет — не знаю, дело ваше. Как раз таки если объем небольшой, то перенос + структуризация ОМ как раз самое то (когда я переносил, я создал скелет ОМ, затем в ОМ заводил и описывал сущность и переносил в вики все с ней связанное, попутно актуализируя/дорабатывая переносимый материал).

  14. Celas on 01.08.2015 at 11:49 пп ответил:

    Не могу понять почему в приведенной таблице сущности Equipment нет параметра для названия экипа (например двуручный меч, рапира, кожаный доспех ), параметров для кол-ва категорий возможного экипа и названия кажой категории (например — всего кол-во 5 и названия: оружие ближнего боя, доспехи, шлемы, щиты, оружие дальнего боя)
    Или это указывается где то на верхних уровнях сущностей (родители), или это вообще не обязательно для программистов?

    P.S.
    Еще раз простите, если глупые вопросы задаю

    • Да, это было задано выше. Там же уровень, какие-то системные моменты, типа root type. Программистам знать, что у сущности есть такое поле — обязательно!

  15. Celas on 02.08.2015 at 9:52 дп ответил:

    Спасибо! А как на английском звучат все эти термины Объектная модель, игровые сущности?
    Пытаюсь еще найти материал по оформлению ОМ в диздоке, но нашел только пару блогов «наших». Или это только «наших» геймдевов ноухау? Поисковик в основном Java script выдает и всякое такое, явно не о геймдеве.

  16. Натан Дрейк (его величество) on 31.12.2015 at 11:28 дп ответил:

    интересно почему у вас монетизация на 5 месте, то есть вы игру не разработали а уже думаете за сколько будете ее продавать)) очень интересно.. кажется теперь я знаю почему все игры из России на пк все такие убогие, так как разрабов волнует только то сколько они заработают, а не искусство как игровая индустрия

    • Anti Danilevski on 25.01.2016 at 12:24 пп ответил:

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

  17. antvirgeo on 28.01.2016 at 9:26 дп ответил:

    Замечательная статья! Большое спасибо, пойдёт в копилку статей:)
    ЗЫ: Выше по поводу монетизации — большинство крупных компании ориентированных на моб.рынок только монетизацией и думают, выпуская по 10-15 ужаснейших апп на неделе) Окупается. Кого волнуется качество 🙁

  18. Bobario on 01.03.2016 at 1:34 пп ответил:

    Больное спасибо! Познавательно, вовремя прочитал и к месту.!!!!!!!!!

  19. Сергей on 23.11.2016 at 1:30 дп ответил:

    Здравствуйте! Спасибо вам за ваш блог! Делаю первые шаги в геймдизайне и ваш блог очень полезен!
    Возник вопрос по структуре. Правильно ли я понял, что в функциональной спецификации вы описываете родительские объекты, например «меч», а в контенте уже идет описание каждого меча отдельно? Если я правильно понял, то все цифры и таблички у нас будут в контенте для каждого «наследника», а в ФС что-то похожее на шаблон?

  20. faustmangos on 23.11.2016 at 1:32 дп ответил:

    Не очень удобная структура в некоторых моментах… Допустим у меня в игре есть несколько оружий и каждое слишком индивидуальное чтобы я запихивал их в контент описывая каким-то обобщенным «строительным материалом». Увы, но такая схема подходит в основном для игр где много вещей которые различаются лишь «Численными характеристиками», но если поведение каждой вещи индивидуальное в плане механики, вы рискуете нарастить себе головную боль с таким устройством диздока.

    • Anti Danilevski on 23.11.2016 at 11:33 дп ответил:

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

    • Anti Danilevski on 23.11.2016 at 11:37 дп ответил:

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

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

Навигация