Как добиться эффективной работы на хакатоне (Наш опыт)

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

Если вы только решили хакатонить, то советую прочесть эту статью.

Проблема: Во время своего первого хакатона, я работал с художником, мы решили, что я буду работать в движке, а он просто нарисует всё необходимое.

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

Решение: Художник и геймдизайнер должны работать в редакторе.

Для распространенных движков есть много видео на ютубе. Достаточно будет потратить 2 часа и вы сможете освоится и сразу видеть и тестировать результат работы.

Вот примеры:

Unity — https://www.youtube.com/watc? v=HcsKUEUijVM

Unreal — https://www.youtube.com/watc? v=hoxt5sCmGc0

Godot — https://www.youtube.com/watc? v=uTowsIazKgw

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

Решение: Git. Если для вас эта проблема оказалась актуальной, то стоит задуматься и об эффективным способе связать все ваши данные. Здесь на помощь придет система контроля версий.

Отличным вариантом будет GitHub он даст возможность обмениваться наработками бесплатно с любым количеством участников. Кстати, GitHub Desktop позволит работать не с консолью, а с приятным интерфейсом.

Как правило, если у вас есть программист, он возьмет на себя обязанность проследить за репозиторием вашего проекта. В противном случае придется изучать ютуб для базового понимания достаточно потратить около 2-3 часов. Как минимум один раз перед хакатоном, вы должны поработать в таком формате.

(Совет: старайтесь не редактировать сцены и картинки одновременно, в противном случае придется принять только одну из версий)

Проблема: Изменение параметров может существенно менять геймплей, но субъективная оценка не может дать ответ, что из двух вариантов лучше.

Решение: Нужно сделать оба варианта. Всегда можно дать поиграть друзьям, родственникам и услышать их мнение, так можно оценить какой вариант лучше.
Подробнее об A/B тестах можно почитать здесь.

Проблема: Даже после длительных разговоров может сложится неправильное представление и команда начнет делать разные игры. Такое происходит если нет возможности посмотреть или обсудить задачу.

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

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