Postmortem безымянной игры, или как мы не выиграли GameJam от Targem Games

Контекст? Targem Games проводили в университете УРФУ GameJam, в котором мы решили поучаствовать. Кто такие "мы"? Мы - группа из трех человек, новички в геймдеве, которые хотели попробовать свои силы в чем-то новом; мы собрались в группу только на время GameJam'а, то есть - до этого в команде не работали. GameJam проводился, по всей видимости, классический - оглашение темы на открытии, участники - команды от трех до пяти человек, 3 дня на разработку, и публикация игры на платформе itch.io.

Зачем нужен этот пост? В первую очередь, этот пост - способ осмыслить прошедший GameJam, проанализировать ошибки, возникшие на этапе разработки, которые привели к поражению, а также попытаться определить лучшие практики, ну и, конечно, записать это в каком-либо виде, чтобы лучше отложилось в памяти.

Что с концептом? На самом деле, с самим концептом не было никаких проблем: не было механик, которые невозможно реализовать при наших умениях и временных ресурсах; не было большого количества необходимого арта для того, чтобы игра выглядела достойно; не было непонятного, или сложного управления - буквально несколько кнопок. В общем, проблемы, которая преследует солидную часть новичков в геймдеве, не было. У нас не было проблемы замаха. Мы придумали простую и приземленную, но, в то же время, довольно любопытную, и легко масштабируемую идею. Для законченного результата нужно было несколько спрайтов, пару-тройку звуков, одну мелодию для главного меню, и одну - для боя, одну маленькую локацию и пару-тройку основных механик. Но что-то пошло не так...

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

Какие были внешние проблемы? Здесь всё довольно просто:
1. Расписание джема. GameJam проводился в рамках университета, то есть, по большей мере, среди студентов. Тех студентов, у кого помимо этого мероприятия есть пары, которые нужно посещать; есть задачи и зачеты, которые нужно сдавать.
Так получилось, что для нашей команды джем выпал на дни наибольшей загруженности. Скажем, он начался в четверг, и закончился вечером субботы. И именно четверг с пятницей - дни, которые мы практически полностью проводим на парах в университете. В результате, первый день джема превратился в короткий вечер обмена концептами и принятия первичного решения о том, что мы вообще будем делать; второй день стал несколькими часами разработки прототипа; и только третий день был насыщен разработкой второпях.
2. Разброс команд. Как уже упоминалось, в джеме можно было принимать участие командам от трех до пяти человек. Причем, в джеме участвовали как новички с первых курсов, для кого он был первым; так и магистры, которые... ну вы поняли. То есть, к тому, что наша команда была минимально возможного размера, добавлялся ещё и тот факт, что против нас выступали бывалые разработчики. В общем, конкуренция была серьезной.
Но это то, что от нас не зависело, поэтому - идем дальше.

Какие были внутренние проблемы?
1. Отсутствие/недостаток опыта работы в команде. Это, определенно, сыграло свою роль. Говорить за других тяжело, но лично мне было сперва трудновато влиться в поток командной работы, из-за чего итоговая эффективность, конечно же, страдала.
2. Отсутствие опыта в GameJam'ах. Ну, тут все просто - для нас это был новый опыт, и нам не сразу удалось включиться в этот специфический режим работы, где необходимо задействовать все ресурсы организма, сидеть допоздна, а иногда и вовсе - работать всю ночь.
3.1. Слишком много времени уделили концепту. Концепт мы выбрали довольно простой и понятный, но даже с учетом всех проблем с расписанием, мы потратили на него слишком много времени. Всё же GameJam - это про скоростную разработку, а не про пустое обсуждение идеи.
3.2. Уделяли внимание ненужным мелочам. Оглядываясь назад, мне кажется, что около двух часов мы потратили на то, чтобы продумать в концепте - как сбалансировать некоторые механики. К слову, весь наш труд по балансу игрок даже не заметит.
4. Не продумали архитектуру. Наша работа проходила по плану: придумали концепт - пишем код. То есть, мы не потратили время на то, чтобы обсудить и записать, а как вообще части программы должны взаимодействовать между собой. В итоге, код мы писали вслепую, вроде как "этого сейчас нет - поэтому делаем это".
5.1. Выбрали не итеративный подход в разработке. Хорошо, когда на каждом этапе есть законченная идея, прототип, в который можно поиграть; можно увидеть, что всё работает, но из запланированных механик реализованы только некоторые. У нас же всё было не так - не было разделения на, скажем, вехи - в конце каждой из которых, у нас был бы готовый вариант игры, пускай с всего несколькими механиками, зато рабочий. Так получилось, что геймплей появился только в момент публикации; до этого наша игра была лишь абстрактным набором механик, неспособных взаимодействовать друг с другом.
5.2. Сфокусировались только на коде. По большей части, это дополнение предыдущей проблемы, но ее масштаб заставляет выделить отдельный пункт. Мы работали только с кодом. Буквально. Учитывая, что в нашей команде не было дизайнера, или 2D-художника, мы не тратили время на разработку интерфейса, музыки, или графики. Мы писали код - игровые механики, в конце даже системы, с которыми более-менее удобно работать. В результате, чисто технически, у нас были готовы все игровые механики; с точки зрения кода, все работало. Но вот проблема - главное меню в игре появилось за пару часов до публикации; интерфейс - только частично, и то топорно; а звуки и музыка и вовсе не были реализованы. То есть, все наши старания игрок просто не способен заметить, потому что механики не описываются посредством интерфейса.
6. Плохой тайм-менеджмент. Даже в то время, когда мы могли работать, и работали, бывали моменты, когда один человек транслировал свой экран, а остальные наблюдали и давали какие-то комментарии. Конечно, часто это было для того, чтобы показать промежуточный результат, или спросить, как сделать лучше, столкнувшись с проблемой; в какой-то степени, это было для нас, новичков, полезно - обмениваться опытом. Но это не отменяет того факта, что время, потраченное на просмотр трансляции другого члена команды, неэффективно. Если просуммировать всё время такого "простоя", то можно было бы спокойно реализовать систему звуков и музыки, или добавить недостающего интерфейса.
*. Уверен, можно выделить ещё пару-тройку весомых проблем, но сейчас это - всё, что я заметил.

Какие выводы сделали?
Во-первых, мы поняли - GameJam'ы это здорово. Мы, определенно, будем еще участвовать в подобных мероприятиях.
Во-вторых, нужно изначально продумывать архитектуру разрабатываемой игры, разделять ее на этапы, по результатам каждого из которых, будет готов своего рода прототип с неполным, но рабочим геймплеем; необходимо равномерно уделять внимание не только коду, но и графике, звукам и музыке, и интерфейсу.
В третьих, нужно фокусироваться на основном геймплее, на своего рода силуэте кор-механик, не зацикливаясь на ограничениях баланса или прочего мусора, который никто не то что не оценит, но и вообще не заметит.