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

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

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

Писать код для игроков, а не для программистов

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

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

Верить себе

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

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

Решать проблемы по мере их поступления

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

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

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

Знать свои сильные\слабые стороны и использовать их

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

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

Уметь проигрывать

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

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

Быть инди значит слепо писать код, который работает, а не академический идеальный код.

Быть инди значит слепо верить в свои идеи даже если все вокруг против тебя.

Быть инди значит слепо игнорировать проблемы пока они не остановят работу.

Быть инди значит слепо делать то, что умеешь делать хорошо.

Быть инди значит слепо верить в успех, даже если впереди только провал.

7070
89 комментариев

Комментарий недоступен

51
Ответить

Как боженька смолвил

3
Ответить

Отличный пост вместо ОП.
Но его стоит похвалить в одном (и тут не поругали за это) - абзац про сильные и слабые стороны в целом правильный. Правда, актуален только для соло-разрабов.

2
Ответить

Вы свои проекты делали или outsource?

Ответить

Спасибо

Ответить

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

Правильным решением будет сделать быстро (1 день вместо месяца), релизнуть на одну платформу и постепенно подключать остальные платформы.А потом 6 месяцев переделывать, т.к. изначально не заложил в архитектуру то, что игра будет мультиплатформой.

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

Советы выглядят как от человека, у которого не было проектов, работа над которыми длилась более месяца (поправьте меня, если я ошибаюсь). В более-менее крупных проектах препродакш/план/оценка и т.п. обязательны и занимают не мало времени.

28
Ответить

Комментарий недоступен

7
Ответить