Разберем подробнее отдельные этапы приведенного выше плана работы. Начнем с пункта "Постановка задачи".
Эта часть подразумевает полное описание того, как должна выглядеть игра с точки зрения пользователя. Конечной целью для нас здесь является составление документа, в котором будет до мелочей описан весь геймплей игры, практически все нюансы визуального и звукового ее оформления.
Критерием того, достигнута эта цель или нет, является ответ на вопрос: «Если я отдам этот документ профессиональной команде разработчиков, которые до этого и не слышали об этой игре, будет ли конечный результат в точности соответствовать моим представлениям о ней?» Если ответ на вопрос положительный (с поправкой на некоторые непринципиальные отличия в оформлении, поскольку графику и звук невозможно в точности перенести из головы на бумагу), то наша цель достигнута.
Документ, который нам нужно таким образом составить, называется дизайн-документом (или диздоком). По сути, он является «игрой на бумаге», то есть полным описанием всего геймплея и всех основных алгоритмов игровой логики посредством текста. Для программистов он является аналогом Технического Задания (ТЗ).
Помимо словесных описаний, диздок часто может содержать картинки, дающие представление о будущем визуальном облике игры — скетчи, наброски, концепт-арт... Это относится как к игровому контенту (персонажи, здания, локации), так и к игровому интерфейсу. Однако, поскольку я отнюдь не художник, то в моем диздоке рисунки если и будут, то только очень схематичные.
Объем диздока часто составляет 100 и более страниц (характерный объем для RPG и вовсе бывает около 500), так что пытаться написать его сразу - бесперспективное занятие. Поэтому начнем мы вновь издалека - прежде всего опишем общую концепцию игры, составим так называемый концепт-документ.
Его объем составляет всего несколько страниц - в среднем две, минимум одна, максимум четыре (если больше, то почти наверняка ваш концепт-документ плох). Основная задача его - давать общее представление о всей игре. Как правило, если вы говорите, что делаете игру, и вас спрашивают: "Какую?", то вы первым делом показываете в ответ концепт-документ.
Почти всегда он содержит в себе такие пункты, как жанр игры, целевую аудиторию, особенности игры (фичи), сеттинг, сюжет, технические характеристики (вроде системных требований), сроки и цену разработки. Некоторое представление о том, что должно быть в этом документе, дает оборотная сторона коробки с любым игровым диском. Главное - не забывайте, что здесь должны быть указаны только самые основные моменты. Концепт-документ должен легко и быстро читаться, и поэтому умещаться, как я уже сказал, в несколько страниц.
Постановка задачи - план
Итак, мы знаем, к чему мы должны придти на этом этапе, и какие основные стадии пройти. Теперь окончательно оформим план работ на этой стадии:
Создание общей идеи. Для начала оформим в голове примерный образ игры - жанр, характер геймплея, некоторые ключевые особенности. Пытаемся сложить из отдельных элементов более-менее цельный образ.
Составление концепт-документа. Составив в голове образ игры, выделяем ключевые моменты и переносим их на бумагу.
Составление дизайн-документа. Теперь пришло время для активной генерации идей и окончательного оформления образа игры. Продумываем по пунктам все основные моменты, делаем наброски интерфейса и игровых образов и методично все это оформляем. Можно время от времени отлавливать ничего не подозревающих друзей, знакомых и родственников и подсовывать им под нос наши наработки, дабы узнать, насколько все это доступно для понимания и достаточно ли подробно описано. В конце концов у нас должно получиться полное и окончательное описание игры, v1.0.
Не все так просто, или реальность вносит коррективы
Да, именно, версия первая. К сожалению, велика вероятность, что с момента завершения изначального варианта диздока и до явления игры миру с ее образом могут неоднократно произойти очень значительные перемены.
Причины могут быть самые разные: плохо продумали какую-то концепцию и она оказалась неработоспособной, противоречивой или просто плохо исполненной; реализация каких-то возможностей может стать неприемлемой в плане сроков или стоимости разработки; какие-то вещи могут работать не так, как ожидалось и из-за этого ухудшать играбельность и/или негативно влиять на игровой баланс в ту или иную сторону; реализация может стать принципиально невозможной в рамках имеющихся средств или заявленных ограничений; какой-то элемент может пойти под нож на пару с другим, поскольку тесно с ним связан; какие-то другие причины, которые часто оказываются частными случаями вышеуказанного.
За примерами далеко ходить не надо. Взять хотя бы Сталкера, который перекраивался огромное количество раз. Начнем с того, что изначально он был вообще не про Чернобыль, а как-то перекликался с фильмом "Звездные врата". Однако, потом было решено, что концепция космических путешествий очень вторична, а концепция Зоны гораздо лучше.
Но и чернобыльский вариант подвергался правке огромное количество раз. Полностью автономный мир без сюжетных рельс на поверку оказался плохоиграбельным, и в результате систему симуляции жизни усмирили, а игрока взяли за ручку и провели по Зоне по заранее заданному пути. Попутно было вырезано довольно много локаций, система управления транспортом (а вместе с ней - и "автомобильные" локации), некоторые монстры (например, крысы из-за своих особенностей поиска пути могли вломиться в закрытую для монстров местность и преждевременно сгрызть сюжетных персонажей), войны группировок...
Так что постоянное изменение тех или иных игровых концепций - неотъемлемая часть разработки. Работая над своим диздоком, я постараюсь различными путями минимизировать необходимость изменений. Возможно, что написание диздока отчасти (но только в той степени, в которой это будет разумно) будет идти параллельно с созданием кода. По возможности я постараюсь проводить тестирование основных концепций сразу же после их утверждения.
Более подробно про создание концепт- и дизайн-документов я расскажу уже на примере работы над ними в рамках этого проекта.