О чем должен помнить каждый разработчик игр
На примере собственной боли
Введение
Я не ставлю целью поучить вас чему-то, не превозношу себя и не принижаю вас разработчиков. В этой статье я лишь хочу заставить вас пересмотреть подход к своей работе, чтобы исключить популярнейшие в моей практике и наблюдениях грабли, избавиться от ненужной головной боли и получать удовольствие от хобби, а в дальнейшем, возможно, и работы. Ставьте все под сомнение и участвуйте в дискуссии, если с чем-то несогласны.
Много не откусить.
Если бы я начинал разработку собственной игры (ссылка в конце прилагается) с нынешним опытом и осознанием того, как тяжело будет под конец, я бы сразу же поставил свои амбиции на место. Из 100 планируемых уровней готово жалких 49 (да, на 50-ый меня не хватило, честно). Стыдный результат и самая распространенная ошибка. Ребята, которых я знаю, собирались делать игру 4 раза (включая один раз со мной). Все эти команды в итоге были расформированы. Преимущественно из-за того, что планировались какие-то совершенно безумные идеи, которые с нашим опытом стоило бы отбросить ещё на корню. Многие идут в геймдев, чтобы сделать своего убийцу. Вы можете считать верным стремление разработчика научиться создавать игры на каком-то сложнейшем проекте с открытым миром и множеством механик, но я считаю, что обучение на относительно небольших проектах приведет к повышению у человека интереса к профессии. Более того, большие проекты тратят очень много сил, времени и денег. Все эти труды в силу вашей неопытности могут просто не окупиться. Пожалуй, единственное, что может утешить в этой ситуации - развитие в вас необходимого опыта и скепсиса.
Планирование.
За что можно любить индивидуальную разработку? Конечно, за неформальный рабочий процесс, отсутствие бюрократии, возможность лепить из вашего проекта что вы хотите и как хотите. Необходимо признать, что такой подход сильно тормозит ваше развитие как разработчика. Систематизация процесса разработки имеет множество преимуществ:
Можно ещё до начала реализации понять, какой объем работы необходимо выполнить;
Как следствие первого, правильно рассчитать свои силы, время и настроение;
Устанавливая рамки по времени реализации, можно анализировать свою продуктивность;
Как следствие третьего, даже при возникновении непредвиденных проблем можно менять и перестраивать свои планы, чтобы поспевать за разумными сроками (не делать головоломку из 49 уровней год) и держать себя в творческом тонусе;
Исключаются ошибки, связанные с конфликтами нескольких механик.
Кроме того, существует масса методологий, позволяющих вам лучше руководить рабочим процессом. Наверное, уже каждый из вас знает об одной из них: Kanban. Самый популярный инструмент для работы по этой методологии - Trello. Уже этого хватит для того, чтобы ощутимо увеличить вашу продуктивность, если вы подойдёте к этому со всем энтузиазмом и ответственностью.
В следующей главе мы подробнее остановимся на последнем пункте.
Kanban доска представляет собой стикеры с задачами
Архитектура
Что такое "костыль" в программировании? В моем понимании, костыль - решение конкретной, индивидуальной проблемы в обход глобальных ошибок целой системы.
Сложновато? Вот пример. Движение кубиков в моей игре не физично. Это значит, что только мои руки отвечают за то, как ведёт себя каждый кубик, когда вы свайпаете в разные стороны. Все было хорошо, пока я не начал делать последнюю механику: стены, через которые может пройти только блок определенного цвета. Мне пришлось обрабатывать каждый индивидуальный случай взаимного расположения блоков. Иными словами, уровни с этими стенами уровни целиком построены на костыле, потому что я недостаточно хорошо продумал механику движения блоков с учётом добавляемых приколюх.
Примеры уровней с такими стенами
Я выделил главные, на мой взгляд, проблемы, с которыми сталкиваются разработчики игр.
В тексте фигурировала эта игра: https://play.google.com/store/apps/details?id=com.Animpaf.Pi...
Она абсолютно бесплатна, я буду благодарен, если вы ознакомитесь с ней. Спасибо.