Gaminator 15 :: Дефект. Реквием

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

Приветствую вновь, Гамин!
Вчера Расери попросил меня рассказать о ходе разработки «Дефекта», возникших проблемах, их решениях, ошибках и интересных находках. Прошу не кидать камнями, ибо рассказчик из меня как из тапка валенок.

История болезни:

Я уже достаточно давно сижу на гамине (уже лет пять, если не больше), но не принимал участия в конкурсах и даже не регистрировался, ибо считал, что должна быть достаточно мощная идея, чтобы сделать хорошую и интересную игру. Но как раз на последнем (15-м) гаминаторе такая идея пришла. Я быстро накатал ДизДок, сделал картинку-концепт, которая была в первом посте о «Дефекте». ДизДок я понятное дело писал не просто так, а для того чтобы собрать хорошую, годную команду. В итоге непосредственно к разработке стали причастны 2 человека.

Сюжет переписывался дважды: в первоначальном варианте «Ларру» звали «Мунси» и это не обозначало вообще ничего, кроме того она даже не умирала, выход за грань был обозначен, как просто выход за границы трудовых будней, которые сдерживали её творческий потенциал, а вся суть игры сводилась к попыткам реализации её проекта и борьбы между необходимостью есть-пить-спать-работать и желанием делать то, чего хочет она.

Ход работы:
Сначала был написан диздок, который, как я уже писал, переписывался в том числе и в ВК. Затем мы разбили геймплей на части и распределили кто и что делает. Разработка велась каскадным методом и всё шло удачно, ведь ошибка произошла раньше, в самом плане. Тем не менее игра быстро обрастала диалоговым «движком», основанным на синтаксическом анализе текстовика с последующей проекцией дерева на двумерный массив (сначала хотели сделать списками, но потом решили, что такая структура нам подойдёт больше), системой движений, анимациями и т.д.

Ошибки и их решения:

Не обкатанная команда.С этим возникало очень много проблем. Кто-то не знает того-то. То чего-то не хватает и нужно срочно куда-нибудь ехать и это покупать. (Это больше относится к музыкальным инструментам) Лучше всё-таки сначала сделать с коллективом что-нибудь, прежде чем делать... Ну да тоже что-нибудь, но уже к чему-нибудь обязывающее. Тем самым отсеются те, кто не заинтересован в проектах, да и будет видно кто на что способен. Есть вероятность, что одному работать даже проще в некотором смысле.

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

Отсутствие графика. Во-первых лучше всего знать заранее сколько часов у вас есть на разработку, поговорить с начальством, если работаете, посмотреть график обучения: кто знает, может через неделю коллоквиум, а вы что-то там гамакить собрались! Во-вторых график поможет распланировать обязанности каждого члена команды гораздо точнее, чем абстрактные «дни».

Интересные находки:

Скайп и показывание экрана-отличное дополнение к спецификации для того чтобы показать команде, что от неё требуется. Достаточно открыть пейнт, нарисовать пару кубиков и стрелочек и понимание будет.

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

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

Какие были затраты времени на обсуждение идей и сюжета, на кот, графику?

Сюжет был написан (и переписан) достаточно шустро. Тут я думаю секрет в том, что идея должна придумываться только одним человеком (В чём, собсна и суть авторской игры) Это должен быть интимный процесс, соавторы должны только оценивать, подсказывать, возможно придумывать небольшие сюжетные линии. Иначе необратимы столкновения вкусов, интересов, мнений и т.д. А это может занять много времени. Кто-то скажет, что в споре рождается истина... Это спорное утверждение, честно говоря.

Код тоже не главная проблема. Особенно при грамотном планировании, как и графика. Тут всё завит от того, что хочешь увидеть. Я вот хотел достаточно красивую графику и рисовалась она порядочно, но ведь есть пиксель-арт-прибежище лентяя)

На что может резко возрасти время во время разработки, и как мы планируем избавится от «неожиданностей».
План, только план. При грамотном планировании ни на что не может возрасти время, при неграмотном-на всё. Звучит абстрактно, но это действительно так. Сейчас, оглядываясь назад, я вижу, что проблем можно было бы избежать, если работать, как уже было сказано, с обкатанной командой, создавать игру, как и любой проект, методом top-down graph (пошаговой детализации), создать график с минимальными рисками и подсчитать количество наших часов. Я думаю это самое важное. Всему остальному можно легко научится. Не умеешь рисовать?-20 часов практики. Не знаешь языка?-ещё 20 часов. и т.д.

На этом всё. Надеюсь этот пост хоть кому-нибудь будет полезен...