Цикл разработки текстовой игры, метод Некса.

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

Часто вижу, как авторы начинают игру с движка или оформления, и на этом процесс написания игры глохнет. Автор растрачивает все силы и энтузиазм на второстепенные вещи, и игра не доходит до релиза.

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

Общий принцип: метод прогрессивного джипега.

Суть метода

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

Цикл разработки игры

1. Сначала полностью реализовывается сюжетная часть. Рисуется черновая карта игры, сугубо для авторского пользования. Составляются списки персонажей, локаций, предметов. Локации и предметы наполняются описаниями. Прописываются переходы, развилки, диалоги. Никакого оформления, никакого сложного кода. Если хочется, на этом этапе можно создать локации и прописать самую простейшую логику с затычками и комментариями. То есть то, что требует не более чем работу с флажками, условиями и переменными. Ещё раз, на этом этапе не делается никакого оформления и сложного кода. То есть абсолютно. Если хоть какой-то кусочек кода требует больше, чем полторы минуты на написание, то он откладывается на потом, а вместо него ставится заглушка. Никаких картинок, цветов, скинов - всё это отжирает силы и время. Пример заглушки. Допустим там по сюжету был бой. Делаем два действия. "Победить монстра в бою", "Проиграть монстру в бою". Никаких боевых систем здесь не делается. Всё что не касается оформления и сложного кода, прописывается от начала игры до конца. У игры к завершению этого этапа разработки должны быть начало, основное повествование и концовка. Полностью готов весь сюжет. Загадки должны быть продуманы, в плане "что должен сделать игрок".
2. Прописывается весь сложный код. Вычищается одна заглушка за другой, последовательно. Здесь уже могут быть какие-то небольшие правки по тексту, но необходимо сдерживать себя и не увлекаться изменениями сюжетной части. Так как сам по себе сюжет уже в первом этапе должен стать таким, что игру будет не стыдно опубликовать. Тут пишется и движок, и всякие хитрые штуки, типа загадок с особой механикой. Имея готовый сюжет, костяк игры, легко привлечь на свой проект помощников-программистов, потому что они видят, что это не какой-то безнадёжный долгострой, а почти готовая игра. Имея готовый сюжет, требования к движку, детализации, механики становятся обоснованными, точными, аргументированными. Уже нет никаких метаний "а стоит ли делать вот такую-то механику, вдруг пригодится". По готовой сюжетной части уже видно, что "пригодится", а что лишнее. Естественно, решения здесь должны быть настолько простыми, насколько это возможно. Движок (если он вообще понадобится) должен писаться под игру, а не наоборот. Не нужно стремиться сделать что-то универсальное и сделать сверх того, что реально требуется прямо сейчас.
3. Игра оформляется графикой и музыкой. Есть сюжет, все тексты, весь код, что ещё осталось текстовой игре? Последний штрих - оформление. Картинки, фоны, скины, фоновая музыка, красивости, рюшечки и плюшечки. Оформление именно на последнем этапе, потому что в текстовой игре оформление не играет решающей роли. Если на этапе оформления у автора уже не останется сил, он всегда сможет его упростить, потратить на него поменьше усилий. Игра при этом ничего не потеряет. В крайнем случае можно и без оформления опубликовать. Ну и конечно же, имея полную расстановку по персонажам, локациям, предметам, и т.п., оформлять игру уже будет гораздо легче, чем "вслепую". Заодно и графический стиль игры можно будет сделать более согласованным, т.к. можно будет охватить взглядом всю игру.

Сложности

Если метод эффективен, почему его ещё никто не использует? Есть несколько причин.

1. Очень легко увлечься и переключиться в процессе написания игры с сюжета на код, или оформление, и "увязнуть" в них. Соблазн велик. Для того, чтобы удержаться, придётся ограничивать себя сознательно. Это возможно только, если автор осознаёт и верит в выгоду именно такого подхода.
2. "Делать всё сразу, параллельно" является совершенно естественным подходом для автора. Для испробования чего-то другого, ему нужно осознавать недостатки "параллельной" работы. А осознание возможно только после самоличного наступания на граблю. До этого момента, автор не сможет усомниться в правильности "параллельной" работы. Ему этого не позволит эффект Даннинга-Крюгера.
3. Даже если автор начинает как-то разделять этапы, то в первый этап поставит "движок" или оформление, потому что сочтёт их самыми сложными. На самом деле, именно творческая часть, текстовая, сюжет, загадки и диалоги, является самой сложной. Автор позволит своему подсознанию себя обмануть, увильнуть от творческой работы (сюжет), переключившись на механическую (код и оформление). Он будет искренне считать, что приступить к написанию сюжета ему мешает незаконченный "движок" или какой-нибудь "неоформленный экран инвентаря".

Nex Moderator 11.01.2015, 23:49 (11 years ago)