Грабли начинающих разработчиков игр

На примере собственной боли.

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

Если бы я начинал разработку собственной игры (ссылка в конце прилагается) с нынешним опытом и осознанием того, как тяжело будет под конец, я бы сразу же поставил свои амбиции на место. Из 100 планируемых уровней готово жалких 49 (да, на 50-ый меня не хватило, честно). Стыдный результат и самая распространенная ошибка. Ребята, которых я знаю, собирались делать игру 4 раза (включая один раз со мной). Все эти команды в итоге были расформированы. Преимущественно из-за того, что планировались какие-то совершенно безумные идеи, которые с нашим опытом стоило бы отбросить ещё на корню. Многие идут в геймдев, чтобы сделать своего убийцу. Вы можете считать верным стремление разработчика научиться создавать игры на каком-то сложнейшем проекте с открытым миром и множеством механик, но я считаю, что обучение на относительно небольших проектах приведет к повышению у человека интереса к профессии. Более того, большие проекты тратят очень много сил, времени и денег. Все эти труды в силу вашей неопытности могут просто не окупиться. Пожалуй, единственное, что может утешить в этой ситуации — развитие в вас необходимого опыта и скепсиса.

Поучительная история: как-то в середине разработки я решил распределить резервные копии проекта по дискам. Перепутал версии, безвозвратно заменил новую версию игры старой. Да, любимое утешение школьных учителей «Не глупый, просто очень невнимательный» — мое кредо. Улетучился целый день работы. А представьте, если у вас в один прекрасный момент сгорит или иным образом выйдет из строя накопитель с проектом. Не у каждого найдутся силы восстанавливать и переделывать столько работы. Ещё перед началом проекта обязательно позаботьтесь об удаленных резервных копиях. Благодаря распространению облачных сервисов, мы можем позволить себе бесплатно использовать GitHub и его альтернативы, чтобы быстро, инкрементально (не перекачивая весь проект, но только изменённые его части) загружать свои работы в хранилище, где оно будет в большей безопасности, нежели на вашем компьютере. Это мой самый настойчивый совет в данном списке.

За что можно любить индивидуальную разработку? Конечно, за неформальный рабочий процесс, отсутствие бюрократии, возможность лепить из вашего проекта что вы хотите и как хотите. Необходимо признать, что такой подход сильно тормозит ваше развитие как разработчика. Систематизация процесса разработки имеет множество преимуществ: Можно ещё до начала реализации понять, какой объем работы необходимо выполнить; Как следствие первого, правильно рассчитать свои силы, время и настроение; Устанавливая рамки по времени реализации, можно анализировать свою продуктивность; Как следствие третьего, даже при возникновении непредвиденных проблем можно менять и перестраивать свои планы, чтобы поспевать за разумными сроками (не делать головоломку из 49 уровней год) и держать себя в творческом тонусе; Исключаются ошибки, связанные с конфликтами нескольких механик. Кроме того, существует масса методологий, позволяющих вам лучше руководить рабочим процессом. Наверное, уже каждый из вас знает об одной из них: Kanban.

Самый популярный инструмент для работы по этой методологии — Trello. Уже этого хватит для того, чтобы ощутимо увеличить вашу продуктивность, если вы подойдёте к этому со всем энтузиазмом и ответственностью. В следующей главе мы подробнее остановимся на последнем пункте.

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

На самом деле, разработка механик в вакууме — не такая сложная задача. Но если вы планируете масштабировать свою игру, добавлять в нее другие механики или просто строить новые и необычные уровни, вам необходимо много думать над архитектурой игровых механик. Ваша реализация должна исключать неожиданное поведение объектов игры в большинстве случаев. С такими системами работать — одно удовольствие, потому что вам не придется потом думать: «А я не сломаю игру, если за этой стеной окажется ещё одна? А если я буду нажимать пробел слишком часто?». Все это требует знания теории программирования и развитого логического мышления. Почему я акцентирую на этом внимание? Потому что тенденция делать механики «на ходу», то есть так, как сначала пришло в голову — ужасна. Примеры таких механик сгодятся для учебников по программированию, не более.

Я выделил главные, на мой взгляд, проблемы, с которыми сталкиваются начинающие разработчики игр. В тексте фигурировала эта игра: https://play.google.com/store/apps/detail? id=com.Animpaf.Pica Я буду рад, если вы ознакомитесь с ней. Спасибо.