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

 

 

 

 

Вступление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо вам за ваше время.

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

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