Быть инди значит быть слепым

Что значит быть инди разработчиком глазами инди разработчика. Полезно для всех, кто занимается или хочет заняться инди разработкой.

Качество кода всегда будет горячей темой в любой дискуссии о разработке. Это один из камней преткновения на пути любого инди разработчика. Дилемма между "высокодуховным" кодом и накиданными в скорости "записульками" стоит перед каждым из нас и наступают моменты когда мы думаем "Ну это точно нужно переписывать"...

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

Знакома ситуация когда вы рассказываете кому-либо идею своей игры в ответ вам говорят "Это будет не интересно"? Вы рассказываете кому-то другому, но реакция особо не изменилась. Начинают опускаться руки, не правда ли? Это типичная проблема первопроходцев. Основная масса людей слишком консервативна и не обладает нужной фантазией чтобы осмыслить и представить вашу идею у себя в голове.

Если вы придумали какой-либо концепт и считаете, что он достаточно интересен - творите! Просто слепо следуйте своей вере в это и не слушайте никого. Да, это сложно. Да, люди будут вас отговаривать. Да, даже ваши близкие будут против вас. Но такой путь инди и его нужно проходить. Раз за разом, релиз за релизом.

Есть такой термин "Premature Optimization" (преждевременная оптимизация). Об этой проблеме написано много статей, много говорится в разных книгах и с этим термином должен быть знаком каждый программист. Если выразиться кратко, то преждевременная оптимизация это попытка решить какую-либо проблему до её наступления.

Например, вы разрабатываете игру и перед вами дилемма между "написать код под все платформы за месяц" или "написать код под одну платформу за день". У вас долгоиграющие планы, вы хотите релизить игру на все платформы. Какой путь вы выберите? Первый вариант кажется правильным, но на самом деле это не так. Правильным решением будет сделать быстро (1 день вместо месяца), релизнуть на одну платформу и постепенно подключать остальные платформы. Если бы вы работали в компании, то правильным путём был бы первый вариант, но вы инди и ваши приоритеты отличаются от приоритетов геймдев компаний.

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

Умение использовать свои сильные и скрывать свои слабые стороны нужно всем по жизни. Практически невозможно быть отличным швецом, таким же жнецом и не менее замечательным на дуде игрецом. Даже если вы отточите все свои навыки до идеала, один ресурс останется не подвластным вам: это время.

Используйте свои сильные стороны при разработке и старайтесь ими компенсировать свои слабые стороны. Например, если у вас прекрасно получается рисовать, то максимизируйте импакт от этого навыка в вашей игре. Если вы не умеете что-то делать, то лучше не делайте "тяп-ляп". Это испортит внешний вид вашего продукта и значительно снизит общее впечатление от него.

Провал не означает смерть. Если вы потерпели неудачу, то это не означает, что вы ничтожество. Мне довелось крутиться в среде стартаперов в конце первого десятка нулевых (imo самый пик популярности культуры стартаперов) и благодаря этому я усвоил один важный урок: потерпеть неудачу намного полезнее чем просто выстрелить. Выстрелив, вы можете не обуздать эту волну хайпа и перенести неудачу будет намного сложнее чем если вы вначале набьёте шишки на коленях провалами и потом с точностью швецарских часов выстрелите, став машинистом хайп-трейна.

Если ваше творение не завоевало аудиторию, не выполнило поставленные вами цели, то это не значит, что пора идти на завод. Проведите ретроспективу, проанализируйте ваши ошибки, посмотрите на конкурентов и пробуйте ещё.