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

Введение
Данный пост адресован преимущественно новичкам. Пусть вас не раздражают обобщения, если вы считаете себя опытным или информацию, доносимую тут, не относящуюся к вам.
Я не ставлю целью поучить вас чему-то, не превозношу себя и не принижаю вас разработчиков. В этой статье я лишь хочу заставить вас пересмотреть подход к своей работе, чтобы исключить популярнейшие в моей практике и наблюдениях грабли, избавиться от ненужной головной боли и получать удовольствие от хобби, а в дальнейшем, возможно, и работы. Ставьте все под сомнение и участвуйте в дискуссии, если с чем-то несогласны.
Много не откусить
Если бы я начинал разработку собственной игры (ссылка в конце прилагается) с нынешним опытом и осознанием того, как тяжело будет под конец, я бы сразу же поставил свои амбиции на место. Из 100 планируемых уровней готово жалких 49 (да, на 50-ый меня не хватило, честно). Стыдный результат и самая распространенная ошибка. Ребята, которых я знаю, собирались делать игру 4 раза (включая один раз со мной). Все эти команды в итоге были расформированы. Преимущественно из-за того, что планировались какие-то совершенно безумные идеи, которые с нашим опытом стоило бы отбросить ещё на корню. Многие идут в геймдев, чтобы сделать своего убийцу. Вы можете считать верным стремление разработчика научиться создавать игры на каком-то сложнейшем проекте с открытым миром и множеством механик, но я считаю, что обучение на относительно небольших проектах приведет к повышению у человека интереса к профессии. Более того, большие проекты тратят очень много сил, времени и денег. Все эти труды в силу вашей неопытности могут просто не окупиться. Пожалуй, единственное, что может утешить в этой ситуации - развитие в вас необходимого опыта и скепсиса.
Гит – наше все
Поучительная история: как-то в середине разработки я решил распределить резервные копии проекта по дискам. Перепутал версии, безвозвратно заменил новую версию игры старой. Да, любимое утешение школьных учителей "Не глупый, просто очень невнимательный" - мое кредо. Улетучился целый день работы. А представьте, если у вас в один прекрасный момент сгорит или иным образом выйдет из строя накопитель с проектом. Не у каждого найдутся силы восстанавливать и переделывать столько работы. Ещё перед началом проекта обязательно позаботьтесь об удаленных резервных копиях. Благодаря распространению облачных сервисов, мы можем позволить себе бесплатно использовать GitHub и его альтернативы, чтобы быстро, инкрементально (не перекачивая весь проект, но только изменённые его части) загружать свои работы в хранилище, где оно будет в большей безопасности, нежели на вашем компьютере. Это мой самый настойчивый совет в данном списке.
Планирование
За что можно любить индивидуальную разработку? Конечно, за неформальный рабочий процесс, отсутствие бюрократии, возможность лепить из вашего проекта что вы хотите и как хотите. Необходимо признать, что такой подход сильно тормозит ваше развитие как разработчика. Систематизация процесса разработки имеет множество преимуществ:
Можно ещё до начала реализации понять, какой объем работы необходимо выполнить;
Как следствие первого, правильно рассчитать свои силы, время и настроение;
Устанавливая рамки по времени реализации, можно анализировать свою продуктивность;
Как следствие третьего, даже при возникновении непредвиденных проблем можно менять и перестраивать свои планы, чтобы поспевать за разумными сроками (не делать головоломку из 49 уровней год) и держать себя в творческом тонусе;
Исключаются ошибки, связанные с конфликтами нескольких механик.
Кроме того, существует масса методологий, позволяющих вам лучше руководить рабочим процессом. Наверное, уже каждый из вас знает об одной из них: Kanban. Самый популярный инструмент для работы по этой методологии - Trello.

Уже этого хватит для того, чтобы ощутимо увеличить вашу продуктивность, если вы подойдёте к этому со всем энтузиазмом и ответственностью. В следующей главе мы подробнее остановимся на последнем пункте.
Архитектура
Что такое "костыль" в программировании? В моем понимании, костыль - решение конкретной, индивидуальной проблемы в обход глобальных ошибок целой системы.
Сложновато? Вот пример. Движение кубиков в моей игре не физично. Это значит, что только мои руки отвечают за то, как ведёт себя каждый кубик, когда вы свайпаете в разные стороны. Все было хорошо, пока я не начал делать последнюю механику: стены, через которые может пройти только блок определенного цвета. Мне пришлось обрабатывать каждый индивидуальный случай взаимного расположения блоков. Иными словами, уровни с этими стенами уровни целиком построены на костыле, потому что я недостаточно хорошо продумал механику движения блоков с учётом добавляемых приколюх.
На самом деле, разработка механик в вакууме - не такая сложная задача. Но если вы планируете масштабировать свою игру, добавлять в нее другие механики или просто строить новые и необычные уровни, вам необходимо много думать над архитектурой игровых механик. Ваша реализация должна исключать неожиданное поведение объектов игры в большинстве случаев. С такими системами работать - одно удовольствие, потому что вам не придется потом думать: "А я не сломаю игру, если за этой стеной окажется ещё одна? А если я буду нажимать пробел слишком часто?". Все это требует знания теории программирования и развитого логического мышления. Почему я акцентирую на этом внимание? Потому что тенденция делать механики "на ходу", то есть так, как сначала пришло в голову - ужасна. Примеры таких механик сгодятся для учебников по программированию, не более.
Я выделил главные, на мой взгляд, проблемы, с которыми сталкиваются начинающие разработчики игр.
В тексте фигурировала эта игра: https://play.google.com/store/apps/details?id=com.Animpaf.Pica
Я буду рад, если вы ознакомитесь с ней. Спасибо.
Смотрите также:
Комментарии
О да, "Всем привет, диск сгорел, игра не выйдет" прям классика!
Пустил ностальгирующую слезу, сам через это все прошел, хоть и не выпустил ни одной игры
Спасибо за пост и добро пожаловать в мир разработки)
<a href= http://mosros.flybb.ru/viewtopic.php?f=2&t=635>Процесс получения диплома стоматолога: реально ли это сделать быстро?</a>