Практические советы по техническому игровому дизайну. Документация (часть 1)

[vc_row][vc_column][vc_column_text]

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

 

 

 

 

[/vc_column_text][vc_column_text]

Вступление

Ну кто не любит документацию? Автоматизированные Excel таблицы, диаграммы Ганта и 40-страничные диздоки, анализирующие всю вашу игру целиком. Удивительно, не правда ли?

Я изучал игровой и левел-дизайн последние три года в Итальянской Видео Академии и очевидно, что большой пласт программы был про документацию — но в этот же период мне повезло изучать теорию за написанием диздока, практиковать это и столкнуться со всеми сопутствующими проблемами.

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

Это будет серия из 3-х статей, в которых я затрону такие темы, как:

1. Золотые правила и Правильное мышление, которое они создают, наряду с общей практикой документирования и «когда надо»;
2. Теория и практика Google докс + советы и рекомендации;
3. Теория и практика Google таблиц с акцентом на то, как сделать это менее пугающим.

Причина, по которой я отдаю предпочтение гугл доксам и гугл таблицам (а не MS Word / MS Excel) не только в том, что Google сервисы бесплатны, но они уже интегрированы в Google драйв и имеют практически все функции, что и в MS Office. Использование Google служб это win-win.[/vc_column_text][vc_column_text]

Основные правила

Я обобщу основы моего мышления в три золотых правила:

1. Показывай, не пиши: используйте картинки, видео, гифки когда это возможно;
2. Коротко и ясно: используйте маркированные списки или таблицы, избегайте стен текста;
3. И самое главное правило: документация бесполезна.

Хорошо, один из них не похож на другие. Тем, кто уже схватил факелы, вилы и круговые диаграммы для мятежа, позвольте мне поочерёдно разъяснить правила:[/vc_column_text][vc_column_text]

Правило 1: Показывай, не пиши

Пытаться объяснить что-то кому-то — тяжело. Но ещё труднее, если вы пытаетесь это сделать письменно. Даже скрупулёзно составленные вами записи, с подробным описанием каждой детали при прочтении другим человеком будут искажены, поделиться так своим виденьем — просто невозможно.

Это правило нужно использовать, когда вы описываете что-то в диздоке: вместо размышлений на тему «как это объяснить», задумайтесь лучше, «как это изобразить»?

Это не только ускорит процесс написания диздока, но и лишит читателя простора для интерпретации, сделает диздок яснее, короче для чтения и гарантирует вам, что любой поймёт, что вы имели в виду.[/vc_column_text][vc_column_text]

Правило 2: Коротко и ясно

Вы ВСЕГДА можете написать короче. Говоря об этом, мне бы хотелось процитировать итальянского поэта и писателя Джузеппе Унгаретти. В своей поэме «Солдаты», он менее чем в десяти словах описывает всю гамму эмоций, которые испытывают солдаты, сражающиеся в окопах.

Если он смог объяснить такие сложные человеческие эмоции в десяти словах, то и вы сможете что-то подобное. Следуя этим рекомендациям, вы всегда сократите текст:

• Короткие предложения, пара слов и много точек:
  • Удалите «и», «или» и «поэтому»;
  • Вам не нужны синонимы;
    • Если вы хотите написать «это оружие крутое и выглядит агрессивно», напишите конкретнее (выглядит агрессивно).
• Используйте подходящие термины и аббревиатуры:
  • Для примера: поговорим про систему чекпоинтов в Hollow Knight’s (скамейки):
    • Вместо того, чтобы писать «объект-чекпоинт позволяет игроку изменить чары, пополнить здоровье и сохраниться в этой точке» я просто пишу «Скамейка»;
    • Не забудьте объяснить, что означает «скамейка» в предыдущем абзаце или в соответствующем документе.
  • Вместо того, чтобы всё время писать «главный герой», я могу в начале написать «главный герой (гг)», и далее использовать просто «гг» для всего документа.

• Думайте о целевой аудитории вашего документа:
  • Если вы пишете для издателя, вы захотите рассказать, что означают слова вроде «агентивность» или специфические фразы, к примеру «свобода игрока».
  • Если вы пишете для других игровых дизайнеров, то предполагается, что они уже знают, что такое «агентивность». Не теряйте драгоценное слово, лишний раз объясняя это.

[/vc_column_text][vc_column_text]

Правило 3: Документация бесполезна

Давайте думать логически: какова ваша цель как разработчика? Делать игры.

Итак, допустим, ваша законченная и опубликованная игра стоит 100 баллов. В самом начале у вас 0 баллов. Будем считать, что всё, что приближает вашу игру к состоянию «завершена и опубликована» (100 баллов) — даёт +1 балл. Это может быть что угодно, от 3D модели, до скрипта перемещения вашего главного героя и до первого уровня.

Но документация к ним не относится. Документация даёт 0 баллов. Следовательно, бесполезна.

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

Это важно, поскольку заставляет вас тщательно оценивать, стоит ли задуманный документ (инвестиция) того.

И это подводит нас к четвёртому и скрытому правилу.[/vc_column_text][vc_column_text]

Правило 4: Никто никогда не будет читать ваш диздок на 100%. Никогда

Это правило подстёгивает вас думать, как минимизировать объем информации, в которой читатель затеряется или сочтёт детали неважными. Это правило резюмирует, что ваша цель как писателя документации — убедиться, что самое важное в вашем документе достигнет предполагаемого читателя. Все предыдущие правила преследуют эту цель, но их недостаточно. А ещё вам не обойтись без таких понятий: презентация (или «правильный путь» написания диздока) и тайминг (или «правильное время» для написания диздока).[/vc_column_text][vc_column_text]

Правильный путь

Помните о правилах 1 и 2: вкратце, «ваш документ должен выглядеть приятным». Избегая стен текста и добавляя изображения, вы сделаете ваш документ приятнее, но вы должны обратить внимание ещё на:

• Форматирование документа, чтобы создать иерархию и визуально разделить содержимое;
• Избегайте по возможности разноса тем на несколько страниц;
  • По-разному форматируйте текст, сокращайте предложения, уменьшайте размер картинок и тому подобное;
• НИКОГДА не разрывайте предложение между страницами

*пример заголовков, используемых для создания иерархии ㅡ подробнее об этом в моей статье о google документах

[/vc_column_text][vc_column_text]

Правильное время

А теперь, вспомните правило 3 и чему оно научило вас: документы это инвестиция. Это значит, что:

• Напишите большую часть документов на этапе препродакшена:
  • На этом этапе ваша команда должна оценить разные возможности, много прототипировать и ещё больше — отбрасывать. Это на стадии продакшена вы будете искать способ перейти от 0 баллов к 1;
  • Это идеальное время для работы с большим количеством дел на 0 баллов.
• Пишите документы, когда они нужны вам:
  • Описывайте большую часть документации, но не прям всё;
  • Бесполезно писать документ о системе прогрессии характеристик персонажа как в РПГ, если ты не знаешь, будут ли вообще в финальном продукте характеристики персонажа как в РПГ;
  • Резюме: не перемудрите.

[/vc_column_text][vc_column_text]

Выводы: что же дальше

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

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

Спасибо вам за ваше время.[/vc_column_text][vc_separator][vc_column_text]Это мой перевод статьи Симона Киккетти (итальянского независимого игрового и левел дизайнера) с блогов Gamasutra, ознакомиться с оригиналом можно тут.

Отдельная благодарность:
— за помощь в переводе Ларе;
— за редактуру — Нике.[/vc_column_text][/vc_column][/vc_row]