Статья с http://www.dtf.ru, мне пришлась по душе и думаю несет в себе не мало полезной информации для нас с вами. Она направлена на тех, кто хочет создавать игры для ПК. Есть конечно своя специфика, но суть ошибок встречается и в книгах-играх и даже просто в книгах.

Статья написана на основе доклада, сделанного на КРИ-2005.

Вместо вступления

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

Цель статьи – рассказать о серьезных ошибках дизайнеров при разработке игр в России, основываясь на своем непосредственном опыте, опыте коллег, общении с разработчиками на форумах и в приватной переписке. В качестве примера используются реальные случаи, без указания конкретных проектов и имен, разумеется.

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

Точка невозвращения

Кто же этот страшный зверь геймдизайнер, нахально занимающий место жизненно необходимого команде аниматора или программиста?

– Геймдизайнер – дитя свободы, мама идеи и папа концепции, страшный бич программистов, покорный раб бюджета и неизвестный герой толпы
– Геймдизайнер создает путь игры от туманной идеи до жестко детализированного списка всех возможностей всех элементов игры
– Геймдизайнер – первый бетатестер проекта, когда тот существует только в его голове
– Геймдизайнер – незримый стержень и душа проекта
– Геймдизайнер – носитель Идеи и ее архивариус

Некоторые могут не согласиться с приведенными определениями, но общая идея совершенно понятна. Времена, когда игры создавались фанатиками-одиночками, прошли. А значит, недостаточно идею придумать, ее надо передать, объяснить, обосновать, расписать (и продать). Родной язык и четкая логика – вот два инструмента геймдизайнера. В принципе это все, что требуется геймдизайнеру. Но не помешают, конечно, богатая фантазия и большой игровой опыт.

Что делает геймдизайнер? Вкратце – он видит, слышит и чувствует игру в своем воображении. Он может "поиграть" в нее еще до написания первой строки кода, без моделей, без интерфейса и вообще без наличия компьютера или консоли. "Поиграв", он оценивает интересность, реализуемость и востребованность идей, витающих в его сознании. Дальше он садится и документирует Идею. Для себя – чтобы не забыть, не упустить чего-то важного, увидеть возможные проблемы и нестыковки с другими идеями. Для команды – чтобы они делали одну и ту же игру, а не каждый свою (и чтобы они вообще делали игру, а не занимались исследованиями или страдали фигней). Для заказчика/издателя – чтобы он не пугался неизвестности, верил в доброе и вечное и не зажимал финансовые средства.

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

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

Ошибка номер раз

Анамнез: Отсутствие целостного видения игры, понимания общей идеи и всей вертикали замысла до самых низов. Отсутствуют: Концепт, Feature list, Vision

Решение: Написать концепт, Feature List и Vision.

Самая распространенная проблема – отсутствие понимания сути происходящего. Делали стелс-шутер – получилась RPG от третьего лица. Делали пошаговый варгейм – вышла RTS. И хорошо, если вообще что-то получилось. А то очень часто бывает, что художники и программисты дружно отчитываются о проделанной работе за истекший период, все идет по плану, сдаются майлстоуны и промежуточные версии – но играбельного ничего нету. А если оно и играбельно, то слабо похоже на конкурентоспособный продукт.

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

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

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

Ошибка номер два

Анамнез: Дизайн "снизу вверх" убивает время и ресурсы. "Концепция изменилась" – и все детали надо писать заново.

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

Решение: Принятый порядок в геймдеве – от идеи через концепт к диздоку и детальному описанию.

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

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

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

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

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

Ошибка номер три

Анамнез: – Мы подумали и решили, что пора сделать фичакат... – Тогда вы останетесь без геймдизайнера!

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

Решение: Фичакат – друг наш, а не враг. Идеально структурированный дизайн допускает страшное надругательство над собой без потери целостности игры и необходимости полного редизайна.

Обычно предложения "выкинуть и вырезать" встречаются разработчиками в штыки. Как же так, кромсать их любимое детище, мегапроект тысячелетия, надругаться над идеалом и самым прекрасным! Не позволим! Лучше мы по чуть-чуть, но всего сделаем! Иначе получится клон!

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

Второе частое заблуждение – лучше больше, но по чуть-чуть. Как же так, резать наши замечательные идеи! Мы их обязательно доделаем, в сиквеле, но без них совершенно никуда, проект просто не будет жить, мы же всем обещали – журналистам, фанатам, мамам и папам! И что о нас подумают люди? Правильный ответ: если в игру будет интересно играть – люди подумают хорошо. И точка.

Третье заблуждение – ах, как же так, если вырезать нашу гениальную фичу, то рухнет все, придется полностью переделывать! Ну, для начала, никто в здравом уме основополагающую фичу вырезать не будет, – например, вряд ли кто-то всерьез решит сделать из трехмерного шутера плоский квест. А вот индикатор здоровья, к примеру, из 3D-экшена выкинуть – запросто. Ну и что, что у всех есть – а в данном проекте какая его функциональная роль? Никакой? Ну и под нож его, вместе с аптечками.

Фичакат помогает:

– Закончить игру
– Сделать это в заданный срок и бюджет
– Уточнить позиционирование игры

В целом – если дизайн проекта построен правильно, пирамидально, то можно отрезать целые ветки фичей без потери общей играбельности. Из RTS убирать воздушные и подводные юниты, из RPG – щиты и скилл воровства, и при этом проект останется играбельным. Если все фичи представляют собой дерево, то отрезание отдельных веток оно переживает хорошо.

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

Ошибка номер четыре

Анамнез: Все знают, что Fallout – это мегакруто. Мы сделаем также.

Признаки: Нездоровый блеск в глазах, послужной список от начала времен и Atari 2600, наличие железобетонного мнения о том, чего хотят игроки. В лице друзей, разумеется.

Решение: Краеугольный камень всего геймдизайна – поиск фана. Фан – единственный критерий оценки геймплея. Игра Нашей Мечты(tm) – вселенское зло.

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

Почему-то большинство дизайнеров вопрос "А чем именно все это будет интересно игроку?" воспринимают как плевок в лицо и личное оскорбление. И не способны внятно и адекватно объяснить, почему вот эта крутейшая фича вызовет интерес и улучшит геймплей. Ну как же так, это же очевидно, что будет мегакруто.

Беда многих геймдизайнеров и команд в целом – они делают игру для себя, Игру Их Мечты(tm), не задумываясь о предполагаемой аудитории и интересности геймплея. Игнорируя мнения издателя, они куют свою прррелесссть. Часто – с плачевным результатом.

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

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

Ошибка номер пять

Анамнез: Дизайнер-программисту: – Нам нужен поиск путей. Сделаешь? – Да, за недельку.

Признаки: Неумение выдавать функциональное ТЗ остальным членам команды.

Решение: Программист всегда дизайнит неправильно. Это аксиома. Дизайном занимается геймдизайнер.

Рассмотрим две чисто теоретических ситуации. Первая: лид-дизайнер сообщает главному программисту: "Нам нужен поиск пути". Вторая: тот же дизайнер говорит: "Нам Нужен асинхронный поиск пути с учетом карты проходимости и разницы высот, с выдачей принципиальной возможности проходимости не более чем за 50мс и поиском пути между любыми точками трех тестовых карт не более чем за 300мс. Учитываются геометрические размеры объекта и коллизии. Учитывается возможность и радиус поворота юнита".

Внимание, вопрос – в каком из этих двух случаев получится более играбельный результат?

Аксиома о программистах: Программист всегда дизайнит неправильно.

Не перекладывайте свою работу на чужие плечи. Функционально задачу ставит геймдизайнер, а программист ее реализует. И это правильное разделение труда. Помните – программист думает абстракциями – алгоритмами, методами, фишками и пальцАми на RSDN. Задача геймдизайнера – поставить ему функционально четкую, определенную, проверяемую задачу.

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

Я много раз слышал фразу: "Ну откуда я знаю, как программисты сделают? Как сделают, так и будет работать". Как будет – понятно, см. аксиому. Такое заявление – роспись в собственной некомпетентности. Работа геймдизайнера и состоит в том, что он создает образ игры в голове, образ настолько красочный и звучный, что можно почувствовать все взаимосвязи, задачи и тонкости проекта. И сформулировать в диздоке словами все необходимые компоненты этого пока виртуального шедевра.

Детализация проектной документации должна быть выполнена минимум до такого уровня, как указано в примере. По этим граблям прошлись десятки, а может быть, сотни команд – сэкономленный на дизайне месяц стоит десяти на этапе массового производства.

Ошибка номер шесть

Анамнез: Концепт-документ проекта напоминает рекламную паузу на телевидении.

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

Решение: Мы не в пустыне, нам вода не нужна. Проблема необходимости функционального, а не художественного описания игры.

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

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

Диздок – не художественный документ, а логически-описательный. Тем более это верно для концепта, предназначенного для широкого круга читателей, обычно деловых и занятых. Не надо заливать их словесной... водой.

Ошибка номер семь

Анамнез: Дома в ящике стола у дизайнера лежит незаконченный роман о вторжении инопланетян, четыре рассказа по мотивам Фоллаута и восемь зарисовок о сражениях с драконами. О своих художественных способностях отзывается скромно: пишу для себя, не публикуюсь.

Признаки: Подмена функционального интереса художественно-описательным.

Решение: Сценарий – обертка функционала. Оркогоблины, мамонт-танки, истребители – это скины для "управляемого юнита". Обертывание голой функциональности игры конкретными сеттингами (или лицензиями) – не проблема, если ключевой геймплей интересный и продаваемый.

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

В чем ошибка? Предполагается, что игроку интересен Михалыч и его тайваньский босс, а не трехмерный шутер с аркадными элементами. Функционал и художественность, диздок и сценарий – вот в чем разница. Это два различных документа, не надо их смешивать.

Концепция может легко измениться. Вот представьте, приносите вы издателю демку, а вам говорят "геймплей клевый, но только орков надо заменить на пехотинцев, слонов на танки, а главным героем сделать не эту ушастую тварь, а Адольфа Гитлера. Такую игру мы продадим". Это если у вас есть интересный геймплей. А если у вас есть только второсортная фантастика про нашествие зомбимутантов из соседней галактики... Увы и ах, но вы самое слабое звено, прощайте.

Рассматривайте геймплей абстрактно. Если игроку может быть интересно манипулировать условными квадратиками, единицами товара, врагами под номером 1, 2 и 3 – то, обернув этот функционал сценарием, можно сделать только лучше. Если вы делаете ставку на сценарий – будьте готовы понять простую истину: игрокам больше нравится геймплей, а не сторилайн. Да, есть исключения, но они лишь подтверждают правила.

Например, по моему личному мнению, Planescape: Torment – геймплейно-заурядная RPG, да еще по нудным D&D-шным правилам. Но сюжет и сценарий – сказка!

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

Ошибка номер восемь

Анамнез: 800-страничный диздок.

Признаки: Проблема планирования дизайна GUI и связанная с ним проблема изготовления ресурсов игры. Интерфейс перерисовывается по пять-десять раз по ходу проекта.

Решение: Некоторые элементы игры, например GUI, трудно задизайнить в финальном качестве до наличия хорошей игровой демо-версии, и это нормально. Просто запланируйте работы по дошлифовке.

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

Так вот, развенчиваю мифы. Издатель тоже ориентируется по уже упомянутой мною (и неспроста!) пирамидальной структуре разработки игры. Ему не нужно сразу описание ВСЕГО до последней иконки. Более того, издателю оно может не понадобиться вообще. Это вопрос политики, опыта и доверия команде, в которые я лезть не буду, но отмечу другое – концепция может измениться.

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

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

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

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

Резюме: Не надо паниковать и впадать в крайность описания ВСЕГО и сразу.

Топик номер девять

Мысль вслух: Что лучше – набросок кучи мегаидей или детальная документация на типичный клон?

Особенности: "Клон или Ррреволюция – holy war go on!"

Ближе к концу статьи я подхожу к философским вопросам, не являющимся такими уж строгими ошибками. Это, скорее, поводы для размышлений. Один из таких вопросов – противопоставление креатива и педантичной детализации. Что лучше – пара звучных, революционных идей с туманными перспективами, или детальное описание опробованных и работающих методов?

Что вообще лучше, Клон или Ррреволюция? Не вдаваясь в разжигание девелоперско-издательской вражды, отмечу – а многие ли из желающих сделать что-то новое действительно могут это сделать? Не авторско-элитарное произведение "для себя", с налетом богемности и немассовости, а действительно интересный миллионам игроков инновационный продукт? А ведь даже у маститых геймдизайнеров вроде Питера Молинье не всегда получается порождать жанры и ломать устои...

Я еще раз хочу обратить внимание на четвертую ошибку, в которой говорилось о поиске фана. Большинство ррреволюций, с которыми сталкивался я, были основаны ровно на одном принципе – "этого еще нигде не было, и поэтому будет круто!" Вот не было еще нигде 50 видов ресурсов – а у нас будет! Вопрос, почему это интересно игроку, вызывает ступор и обиду. Ну как же, это же круто, этого нигде не было, ты что, мальчик, не слышишь очевидного? Увы, это ситуация, близкая к реальности.

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

Топик номер десять

Некоторые субъективные мысли о заблуждениях насчет качества игр, казуальности, отсутствия инноваций и о том, "как тяжело стало жить".

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

Казуально – не означает "только для идиотов". Казуально – это так просто, что будет понятно всем, в том числе и "идиотам". И сделать сложные вещи простыми, легко управляемыми, элементарно понимаемыми – задачка не для средних умов. Это как написать ознакомительный курс ядерной физики для домохозяек.

Понятно, что раньше и пиво было крепче, и травка зеленее. И игр было меньше, конкуренция слабее, аудитория умнее и бюджеты скромнее. И вообще, в наше время туго живется нашему брату геймдевелоперу. Но можно посмотреть на эту ситуацию как на естественный отбор. Планка качества и востребованности проектов растет, и вместе с ней неизбежно отсеиваются слабые звенья. Можно ведь трезво и честно взглянуть на ситуацию, и попытаться понять – может быть, дело не в глобальном заговоре Electronic Arts дело, а в собственном непрофессионализме, непомерных амбициях, неорганизованности? Даже если вы смотрите на свое дело свысока, с позиции "пипл хавает", все равно же хочется, чтобы хавали вашу игру, а не продукцию конкурентов.

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

2) Дизайн документ (англ. Game Design Document) — это детальное описание разрабатываемой компьютерной игры. Диз. док. создается и редактируется командой разработчиков и в основном используется в индустрии видеоигр для организации работы разработчиков. Документ создается в результате сотрудничества между дизайнерами, художниками и программистами как руководство, которое используется в процессе разработки. Когда издатель поручает создание игры разработчикам, команда разработчиков должна создать документ, который часто связан с соглашением между издателем и разработчиком; разработчики должны придерживаться дизайн документа во время процесса формирования игры.
По сути, это подробное описание того, что должно получится на выходе. Чем менее подробный диз.док, тем больше свободы у художников, программистов и др. Как следствие игра может получится совсем не такой, как ее планировали.

Графческий интерфйс пльзователя(англ. Graphical user interface, GUI) — разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений. Ясное дело, что для книг-игр использовать термин GUI в чистом вине не правильно. Но удобный лист персонажа, не обременительное количество параметров и боевая система не требующая 24 бросков кубика и подсчетов корня квадратного из суммы четырех параметров – это хороший GUI в нашем случае.

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