Серия «Инди код»

2

Почему ограничения — это суперсила

Серия Инди код
Почему ограничения — это суперсила

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

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

Когда не можешь просто добавить нужную фичу — приходится крутиться: использовать баг как механику, адаптировать старые системы под новые идеи, обходиться тем, что имеется.

Иногда это похоже на попытку собрать космический корабль из деталей от холодильника. Но если он взлетает — ощущение совсем другое.

Может, дело как раз в том, что ограничения не мешают творчеству, а подталкивают к нему. Кто знает, может это даже интереснее, чем абсолютная свобода.

Показать полностью

Как я случайно попал в геймдев (и не пожалел)

Серия Инди код
Как я случайно попал в геймдев (и не пожалел)

В 2019 году я почти ничего не делал, кроме того, что писал небольшие истории для блога. Просто тексты — про мысли, про жизнь, без особой цели. Работу не искал. Профессии как таковой у меня не было. Умел только писать код и немного разбирался в маркетинге.

Кодинг шёл со школы — иногда подрабатывал, делал интернет-магазины, админки, в общем, типовые задачки. Даже однажды устроился на постоянную работу, но как-то не зацепило. Через 10 месяцев просто уволился — без плана, в туман.

А потом неожиданно приходит приглашение на собеседование: фулстек-разработка на Symfony и Vue. Я согласился, назначил дату и время — и… уснул перед собесом. Просыпаюсь в 17:01, смс: «Вы придёте?». Меня уже ждут в скайпе. Захожу, отвечаю на вопросы — и обратно спать. Как вы поняли, с режимом у меня тогда тоже было не очень.

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

С тех пор продолжаю работать. А в прошлом году решил попробовать сделать свою игру. Просто как эксперимент — посмотреть, как всё устроено вне бэкенда и админок, которые я обычно писал. Начал делиться опытом — про процесс, фейлы, маленькие победы. И неожиданно начали подтягиваться люди. Кто-то с проектами, кто-то с опытом, кто-то просто из интереса.

Постепенно начала складываться небольшая тусовка. И это реально круто. Спасибо, что читаете. Заглядывайте в чат где можно повисеть с коллегами👉 https://t.me/codeindiechat

Зовите коллег из гейм дева или просто всех кому интересно. Кто-то, может, захочет вкатиться в геймдев, а кто-то просто понаблюдать за движухой. Обсуждаем актуальное, делимся наработками, поддерживаем друг друга и просто болтаем.

Показать полностью
7

Книги для разработчиков игр

Серия Инди код

Хочу прочитать что-то из индустрии разработки игр. Что бы вы посоветовали? Какие книги вдохновили вас или помогли лучше понять процесс создания игр?
Поделитесь в комментариях, что сами планируете прочесть или уже прочли. Давайте вместе соберем полезную подборку книг, которые точно стоит изучить.

11

Кради как художник: вдохновение без стыда

Серия Инди код
Кради как художник: вдохновение без стыда

Более 5 лет назад я прочитал книгу Остина Клеона «Кради как художник». Она сразу меня зацепила. Спустя такое долгое время помогает и сегодня. Эта маленькая, но мощная книга открывает простую истину: вдохновение не приходит из воздуха. Всё, что нас окружает — фильмы, книги, музыка, игры — уже наполнено идеями, которые можно взять, адаптировать и сделать своими. Клеон не призывает к простому плагиату, а скорее к переработке, смешиванию и созданию чего-то уникального из того, что уже было до нас.

Идея заимствования, которую предлагает Клеон, не имеет ничего общего с простым копированием. Он говорит, что важно взять то, что тебе нравится, и добавить свой уникальный подход, переработать это, чтобы получилось что-то личное и новое.

После того, как я прочитал книгу, я перечитывал её ещё несколько раз. Каждый раз находил что-то новое, что помогало мне смотреть на творческий процесс с другой стороны. Всё, что нужно, — это убрать чувство вины за «заимствование» и просто позволить себе творить.

Клеон напоминает, что каждый великий художник когда-то что-то «позаимствовал». И важно не бояться этого процесса, а использовать его как инструмент для роста и творчества. Заимствование не делает нас менее оригинальными, наоборот, оно позволяет создавать нечто новое, обогатив своё восприятие мира.

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

В конце концов, вдохновение может прийти откуда угодно. И, возможно, именно в этом заимствовании и смешивании идей и рождается что-то по-настоящему уникальное. А вы чем вдохновляетесь?

Мой тг: https://t.me/codeindie

Показать полностью
7

Разработка HTML5 игр: шаги, которые приведут к идеальной (или почти идеальной) игре!

Серия Инди код
Разработка HTML5 игр: шаги, которые приведут к идеальной (или почти идеальной) игре!

Я давно заметил, что любую интеллектуальную работу можно разложить на этапы. Разработка игры — это не просто магия и вдохновение, а целый конвейер, на котором ты собираешь свою игру по кусочкам. Каждый этап — это как отдельная станция, где что-то собирается, что-то настраивается, а что-то тестируется. И на каждом шаге есть возможность что-то улучшить или автоматизировать.

Когда начинаешь смотреть на разработку игры как на конвейер, сразу понимаешь: всё можно упростить и ускорить. Всё это работает как машина — если её правильно настроить, она будет катить быстрее, а ты будешь наслаждаться процессом. А главное, в будущем это можно масштабировать, наняв людей, чтобы они занимались конкретными этапами работы, а ты с кофе в руке мог только одобрительно кивать (так почти не бывает, работать придётся всегда).

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

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

О некоторых этапах я сознательно умолчал, потому что инди-разработчику они часто не нужны. Я разбил процесс разработки игры на этапы, потому что привык систематизировать и оптимизировать всё вокруг. Это моя рабочая привычка.

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

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

Главное в создании игр, конечно же, — интересная игра.

Путь инди-разработчика: 9 этапов создания игры

1. Идея и концепция: чтобы не создать шляпу и не потерять время

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

Я всегда начинаю с того, что всё подробно описываю текстом и рисую зарисовки. Сажусь, беру ноутбук и блокнот и начинаю разжёвывать, что именно я хочу создать. Это как начальный бульон, в котором варится всё, что будет потом — только не лук и морковь, а идеи и концепции.

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

В больших студиях пишется полноценный дизайн документ к каждой конкретной особенности игры (фиче). Есть ещё этапы ревью дизайн документа — когда коллеги-геймдизайнеры, разработчики, QA и другие специалисты оценивают работу. Могут сказать: "А вот это вы вообще куда?" или "Так, это мы исправим на месте". Но я не буду углубляться в подробности работы больших команд — тут мы говорим о тех, кто пилит небольшие игры в одиночку (как я) или с небольшой командой.

Не стоит недооценивать этот этап. На нём закладывается фундамент, и нельзя начинать разработку, если не знаешь, что ты собираешься делать. Ведь потом будет поздно, а искать баги в концепции и всё переделывать — занятие ещё то!

2. Создание прототипа: от фантазии к реальности

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

Что касается меня, то я всегда начинаю с самого простого — вместо графики ставлю кружочки, квадратики и прямоугольники. Да, это выглядит не очень круто, но это помогает сосредоточиться исключительно на механике. Я как будто собираю дом, но пока только строю каркас, без окон и дверей.

Важная цель этого этапа — как можно скорее проверить, «жива» ли идея. Когда я собрал базовый прототип, первым делом тестирую основные механики: насколько удобно управлять, насколько понятно, что вообще происходит в игре. Это важный момент, ведь даже если идея в голове кажется гениальной, в игре она может выглядеть совсем по-другому. Для меня это всегда момент истины — нравится ли играть в это мне самому? Удобно ли? Интересно ли?

После этого я обычно даю прототип друзьям или родственникам, чтобы получить обратную связь. Это, конечно, может быть немного волнительно, потому что их мнение не всегда совпадает с моим (и порой очень сильно отличается от того, как мне кажется). Но именно на этом этапе очень важно увидеть, что людям нравится, а что вызывает недоумение. Иногда они говорят: «О, прикольно!» — и я чувствую, что на правильном пути, а иногда что-то вроде: «Эм, а что тут делать?» и тут уже начинаешь понимать, что что-то пошло не так.

Так что для меня этот этап — это не только тестирование, но и отличная возможность быстро получить обратную связь и понять, стоит ли продолжать двигаться в том направлении, в котором я начал.

3. Графика, интерфейс, звук: чтобы игрок не сбежал сразу

Это подготовительный этап, чтобы игра обрела потом визуальную и звуковую оболочку. Персонажи, интерфейсы, анимации, звуки, музыка — всё должно быть не только функциональным, но и приятным. Как-то гармонировать между собой. Потому что как только игроки соприкоснуться с тем, что на экране, — они либо останутся, либо уйдут в поисках более приятной для них игры. Причем момент настолько тонкий, что игроку может быть не сразу понятно почему не нравится игра, а дело в том, что звуки режут слух или визуал отталкивает.

Звуки и музыка важная часть. У меня есть кое какой опыт в аудиопродакшне. Есть даже релизы на разных лейблах в разных музыкальных стилях. Но имея опыт, я не берусь создавать музыку и звуки окружения. Это отдельный и трудоемкий процесс. Я считаю, что он необходим когда понимаешь, что игра стоящая.

Поэтому на этом этапе я ограничиваюсь приятной фоновой музыкой от нейросети и скачанными звуковыми эффектами. Просто подбираю подходящее к игре.

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

Вообще работу с графикой я часто рассматриваю как первый кандидат на делегирование в будущем.

Здесь, как и на предыдущих этапах, мне помогает понимание, какую работу я уже проделал. Игра начинает обретать форму, и становится понятно, какие именно графические и аудио элементы вообще нужны. Так что перед тем, как взяться за создание, я всегда стараюсь всё заранее описать: сколько элементов интерфейса мне потребуется, какие персонажи должны быть, и какая анимация для них требуется. Какие звуковые эффекты нужны.

Это как с покупкой мебели. Если ты заранее измерил пространство, продумал, что где будет стоять и каких размеров, то потом будет легче понять, как всё будет выглядеть в интерьере. Примерно то же самое и с графикой и звуками — всё надо продумывать заранее, чтобы потом быстро найти или создать только нужное.

4. Кодинг и детали: генерируем баги, чтобы потом их чинить

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

Код — это как суперсила, но вместо того, чтобы создавать заклинания, ты заставляешь объекты двигаться, а кнопки работать. Кто-то пишет на чистом языке программирования, кто-то использует готовые библиотеки и движки. Всё зависит от того, насколько ты хочешь потерять свою душу в этом процессе.

Лично я пишу на TypeScript и использую Construct 3 как движок. Он отличный — даже без глубоких знаний программирования можно собрать игру. В нём есть удобная таблица событий, а визуальный редактор позволяет с минимальными усилиями создать нечто, что можно с гордостью назвать игрой. Но я выбрал хардкор — сейчас перепиливаю свои игры без использования эвент-таблиц, что добавляет к процессу не только сложности, но и новые поводы для чесания головы. Иногда кажется, что если бы у меня были волосы, я бы лысел гораздо быстрее.

Но, как я сказал, здесь начинается настоящая борьба с багами. Вот где я часто использую фразу: «Ну не может быть, что это не работает!» Бывает момент, когда ты садишься за компьютер в 9 утра, а выходишь из него в 3 ночи, моргнул — и всё ещё не веришь, что кнопка "Старт" не работает после очередного «незатейливого» рефакторинга.

Здесь уже не обойтись без детальной отладки и долгих часов мучений, но если всё сделать правильно, игра начинает набирать свою настоящую форму. И это, пожалуй, самый кайф в процессе — когда ты наконец-то видишь, как твоя задумка превращается в нечто настоящее, а не просто в бесконечные строки текста и папки с графикой и звуками.

5. Интеграция с платформами: соблюдаем правила, иначе провал

Когда игра готова, наступает самое интересное: её нужно куда-то пристроить! Тут важно подумать об этом заранее, ещё на этапе диздока. Определить, на каких платформах она будет жить, потому что каждый сервис требует своих танцев с бубном. На этом этапе предстоит подключение SDK платформы и выполнение всех её требований для публикации. Всё как в хорошем рецепте: у каждой платформы свои ингредиенты, и если что-то не так, то блюдо не получится вкусным.

Для меня это не самый сложный этап, так как сейчас я в основном выпускаю игры на Яндекс. Игры. У меня уже готовы шаблоны кода для работы с их API, поэтому этот процесс проходит довольно быстро и, можно сказать, безболезненно. Но, конечно, каждый раз я немного переживаю, когда выпускаю новый билд — никогда не знаешь, что выкинет система в этот раз. Я, конечно, надеюсь, что всё пройдет гладко, но внутренне всегда готов к сюрпризам. Это как когда сдаёшь курсовую, и надеешься, что преподаватель не заметит малюсенькую ошибку.

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

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

6. Оптимизация и тестирование: чтобы не тормозило, а работало

Оптимизация — это вообще святая вещь! Если игра зависает или долго грузится, то, поверьте, в неё никто не захочет играть. Лучше уж сжать изображение, чем заставить игроков сидеть минуту, ожидая, когда откроется меню. В конце концов, терпение у игроков не бесконечно.

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

При тестировании важно проверить игру на разных устройствах и в разных браузерах. Это не просто мелочь — это жизненно важный момент, чтобы потом не переживать, что кто-то не может поиграть. И если игра локализована на другие языки, то обязательно надо убедиться, что язык определяется корректно, потому что, например, западным игрокам будет сложно найти переключатель языка в русском интерфейсе.

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

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

7. Релиз и маркетинг: чтобы в игру поиграла не только мама

Сам релиз — это, по сути, просто раздача финального билда пользователям. Так сказать, открытие дверей для публики. Это подходит как для маленьких, так и для больших игр.

Релиз всегда сопровождается различными промо-материалами. Минимум — это название игры, описание, графические материалы (не обязательно скриншоты, можно и концепт-арт), и, конечно, желательно видео геймплея. Эти материалы делятся на два типа: внутренние — для самой платформы, где релизится игра, и внешние — для маркетинга.

Но на этапе предрелиза я всегда понимаю, что это только начало. Даже если игра — супер-хит, без маркетинга она так и останется коробкой с подарком в шкафу. Очень многие надеются, что релиз — это момент, когда все начнут восхищаться и делиться игрой с друзьями, а на деле… ну, не совсем так. Реальность бывает жестока, как неожиданный баг на релизе.

Рекламные кампании бывают самые разные. Можно продвигаться через потоковые рекламные каналы: таргетинг (vk, mytarget и др.), тизерные сети, контекстную рекламу (яндекс директ, google ads). Можно делать закупки рекламных интеграций у стримеров, покупать посты в соцсетях или запускать рассылки по СМИ. И, как это ни странно, на успех влияет всё: как ты описал игру, какие материалы используешь, у кого рекламируешь и на какой площадке, а также куда впоследствии попадает пользователь с рекламы. В маркетинге столько переменных, что кажется, будто ты играешь в шахматы с высокорейтинговым соперником. Постоянно думаешь как бы не зевнуть фигуру (бюджет). Все эти эксперименты требуют денег. И, если честно, достаточно серьёзных.

Я же на этом этапе ограничиваюсь только релизом на платформе. Заполняю карточку игры как следует, загружаю материалы и выделяю небольшой бюджет на таргетинг и контекст, чтобы привлечь пару сотен игроков и увидеть, как игра воспринимается. Для меня самое важное — собрать метрики, получить обратную связь и двигаться дальше. Ведь каждый отзыв — как драгоценное золото. Такой подход является частью методологии R&D (Research and Development).

Я не так давно начал свой инди-путь. Даже с огромным опытом в геймдеве, разработке и маркетинге, создать хорошую игру всё равно непросто. Я объективен к своим играм. А игровые метрики ещё более объективны. Нет смысла вкладываться в продвижение, если люди не играют в игру. Некоторые платформы могут подкинуть органический трафик, и если что-то не так, это сразу становится очевидно. Когда ты смотришь на метрики и видишь, что “игроки уходят через 30 секунд” — это больно, но полезно. Понимание, что нужно улучшать, приходит именно тогда.

8. Обновления и поддержка: продолжаем улучшать, не сбавляя темпа

Этот этап — один из самых важных в жизни игры. Сбор обратной связи, фиксация багов, анализ метрик и выдвижение новых гипотез для улучшения игры — здесь и открывается вся правда о том, как игра воспринимается на рынке.

Метрики могут рассказать много интересного: если плейтайм слишком короткий, или если игра получает больше негатива, чем похвалы. А иногда, что ещё хуже, отзывов нет вообще. Да, та самая пустая тишина. И вот это не всегда хорошо. Статистика очень точно отображает, как игра чувствует себя на рынке и, скажем так, насколько она успешна среди игроков. Потому что тишина — это тоже своего рода сигнал.

Я уделяю этому этапу много внимания. Как начинающему инди-разработчику, мне важно понять, насколько я адекватен в восприятии своей игры по отношению к рынку. Игроки — главные судьи. Они решат, хорошая ли это игра, или просто неудачный эксперимент. И метрики, и обратная связь — вот те индикаторы, которые покажут, на каком уровне находятся твои идеи. Не стоит игнорировать критику, а лучше взять её на вооружение.

Очень важно быстро реагировать и вносить изменения, если что-то пошло не так. Чем быстрее решается проблема, тем быстрее игра будет двигаться в нужном направлении. Быстрая фиксация багов и улучшение UX/UI после отзывов — это то, что должно стать нормой.

Разработка игры — это марафонская дистанция, а не спринт. Это длинный путь, который не заканчивается релизом. Обновления и поддержка — это как забота о растении: поливать и ухаживать нужно постоянно, если хочется, чтобы оно росло и процветало. Если кажется, что работа с игрой заканчивается на релизе, то это только иллюзия. На самом деле, игра только начинает свою жизнь.

9. Осмысление работы: улучшение процессов и поиск новых подходов

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

Часто не удаётся осмыслить всё прямо в моменте, особенно когда ты зациклен на какой-то проблеме или, скажем, пьёшь чай. В такие моменты лучший способ — просто дать себе время и передохнуть. Уходит вся эта рабочая суета, мысли о проблемах, и ты возвращаешься к проекту с чистым, свежим взглядом. Иногда достаточно недели отдыха, чтобы снова «войти в игру» и понять, что нужно исправить.

Иногда я практикую такой подход: даю проекту «отлежаться» несколько дней до релиза, а потом пробегаюсь снова и оцениваю, все ли как надо для текущей итерации.

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

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

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

Эта рефлексия — важный этап, даже если она не прописана в официальных чек-листах. Без неё можно зациклиться на одних и тех же ошибках, забывая, что можно сделать лучше. А иногда, чтобы действительно понять, как двигаться дальше, нужно просто сделать паузу, отдохнуть и взглянуть на свою работу с новой перспективы.

Итоги пути инди разработчика

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

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

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

Показать полностью
8

Правила рефакторинга для новичков: как не сойти с ума, улучшая код

Серия Инди код
Правила рефакторинга для новичков: как не сойти с ума, улучшая код

Когда я только начинал программировать, рефакторинг казался мне чем-то вроде древнего заклинания, произнести которое мог только магистр кода. Оно было каким-то мифическим, непостижимым… и абсолютно ненужным. Я думал: «Если код работает, зачем его трогать?» Реально, кто захочет искать баги в том, что и так делает свою работу?

В голове крутились мысли вроде: «Рефакторинг — это для тех, кто пишет код на уровне искусства, а я тут сижу, пытаюсь заставить свой код хотя бы не падать в обморок».


Но потом я столкнулся с реальностью. Оказавшись в проекте, где код был не просто кривым, а скорее лабиринтом без выходов, я понял, что рефакторинг — это не какое-то волшебство, а необходимость. Это как уборка в доме: если долго не заниматься, начнётся настоящий хаос, и ты будешь искать ключи от квартиры в куче старых газет. А потом понимаешь, что чистота и порядок не такие уж страшные вещи.

Как я научился рефакторить

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

1. Изменяйте код маленькими шагами

Раньше я пытался переделать всё сразу, как будто хотел построить идеальный дом за один день. Это, как ни странно, приводило только к строительному хаосу. Теперь я рефакторю маленькими шагами — каждый кирпич важен. Я часто останавливаюсь, проверяю, что изменилось, и только потом двигаюсь дальше. Это помогает избежать ошибок и не запутаться в процессе.

2. Тестируйте сразу каждое изменение

Хорошо, если у вас есть возможность написать автоматизированные тесты до начала рефакторинга. Но если такой роскоши нет, не переживайте. Главное — помните, что каждое изменение нужно тестировать. Иначе код превращается в комок неработающих функций, которые будут вам мстить в самых неожиданных местах.

3. Не бойтесь удалять код

Когда я научился не бояться удалять старый, неиспользуемый код, жизнь стала проще. Это как с ненужными вещами в доме: ты не понимаешь, сколько мусора накопилось, пока не решишься выкинуть его. Уберите то, что не нужно, и проект задышит легче. Ваш код тоже.

4. Чистый код — это понятный код

Когда пишу код, я всегда думаю о том, как его будет читать кто-то другой — или даже я сам через пару месяцев. Комментарии в коде помогают, и не нужно их бояться, но гораздо важнее делать так, чтобы код был очевиден сам по себе. Группируйте код по функционалу, используйте говорящие имена переменных и избегайте слишком длинных функций. Код должен быть как книга, в которой легко ориентироваться.

5. Не стремитесь к идеалу с первого раза

Рефакторинг — это не процесс одного дня. Я научился улучшать код постепенно. Идеалов не существует. Важно делать шаги по улучшению, а не пытаться всё переделать сразу. Качество кода растёт со временем. Так же, как и вы.

Как рефакторинг помог мне

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

Рефакторинг — это не про то, чтобы переписать всё с нуля. Это про то, чтобы делать свой код чуточку лучше каждый день. И как бы не было тяжело на старте, со временем это становится привычкой. Рефакторинг — это не бремя, а путь к созданию кода, которым можно гордиться.

А как у вас обстоят дела с рефакторингом?

Есть ли свои секреты или правила, которые помогают вам не свихнуться, улучшая код?

P.S. Буду рад обсудить в моем телеграм канале. (https://t.me/codeindie)

Показать полностью
13

Как я перестал переживать из-за непродуктивных дней

Серия Инди код
Как я перестал переживать из-за непродуктивных дней

Когда я был моложе, каждый день без работы воспринимался как катастрофа. Казалось, что если я хоть один день не буду продуктивным, то теряю всё. В голове крутилось: «Вот, всё пропало, если не сделаю хоть что-то сегодня, я просто обречен». Я был полон энергии, но в своём стремлении работать без передышки, часто перегружал себя настолько, что буквально сгорал.

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

Как я изменил подход

Сейчас я с собой так не поступаю. Я понял, что работать на износ — это не значит «стремиться к успеху», а просто сжигать все силы на пустую гонку. Я научился работать с тем ритмом, который мне комфортен. Работаю ровно столько, сколько работается. Это так просто. Если не могу что-то сделать сегодня — ну и ладно. Я не начинаю себя корить. Это не конец мира. Это не значит, что я стал ленивым или потерял свой настрой. Это просто нормальный день, когда силы для работы не находятся. Завтра силы вернутся. Или через неделю. Не каждый день должен быть продуктивным.

Что я делал последние 12 дней

Последние 12 дней я не работал над играми и блогом. Часть времени провел в дороге в поезде, навестил родню, на обратном пути погулял в Екатеринбурге и Тюмени. Прочитал две книги: "Доктор Живаго" Бориса Пастернака и "Искусство лёгких касаний" Виктора Пелевина. Также успел прочитать половину "Тайных видов на гору Фудзи" того же автора. Пересмотрел "Мстителей: Война Бесконечности" и "Финал". Хорошо отдохнул и подзарядился.

Отдых — это часть процесса

Я не переживал из-за этого времени. Я дал себе эту паузу. Вместо того чтобы ломать себя, я понял: когда ты осознанно отдыхаешь, ты даёшь своему мозгу и телу время на восстановление, а не загоняешь их в спираль выгорания. И это нормально.

А что у вас нового за последние 2 недели?

Показать полностью
12

Нейросети для инди-разработчика: как они могут ускорить вашу работу

Серия Инди код
Нейросети для инди-разработчика: как они могут ускорить вашу работу

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

В итоге я передумал и решил использовать готовые ресурсы. Скачал бесплатные графические ассеты, тайлмапы для уровня и звуки с интернета. Так родилась моя первая игра. Однако я понимал, что нужен более быстрый подход, и начал работать с нейросетями.

И вот что я понял: нейросети — это не просто круто, это реально ускоряет процесс разработки. Не знаю, почему я не начал работать с ними раньше, но если вы такой же мечтатель и фантазер, как я, и хотите ускорить свою работу, вот что точно вам поможет:

Для работы с идеями и смыслами:

https://chatgpt.com/ — отличный инструмент для генерации идей для игры, обсуждения механик, поисковые запросы "Как сделать что-то в программе" (например, Construct 3). Также ChatGPT можно попросить составить запросы для других ИИ, генерирующих графику или звуки.

Для графики:

https://www.recraft.ai/ — с этим сервисом я генерирую основную графику и получаю идеи для интерфейсов, подходящих для моей игры. Затем немного дорабатываю в фотошопе.

https://playground.com/ — тут можно работать с уже готовыми картинками: например, добавить элементы или изменить их, чтобы получить больше вариантов.

Для звуков:

https://elevenlabs.io/ — генерирует звуковые эффекты и звуки интерфейса. Конечно, требуется небольшая пост-обработка, как минимум вырезать нужные фрагменты.

Для написания кода:

https://chatgpt.com/ — может помочь с генерацией кода, если нужно. Я пока пользуюсь им, но в планах внедрить в саму IDE еще другие две или одну из:

https://github.com/features/copilot — помогает автоматически генерировать код, предлагая полезные решения для программирования.

https://www.cursor.com/ — ещё один мощный инструмент для ускорения написания кода.

В урезанных бесплатных версиях всегда установлены лимиты. Если вам их не хватает, то просто заведите себе несколько почтовых ящиков в гугл почте и переключайтесь на другой аккаунт, когда на одном лимиты закончились. Из минусов: без VPN этими ресурсами пользоваться невозможно.

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

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

Показать полностью
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества