Разработка игр *

Стал программистом в Контуре чтобы делать игры

Знакомьтесь: мобильный разработчик Контур.Диадока, Дима Моисеев. 😎 Уже 12 лет делает на Ютубе авторское шоу Old Hard о незаслуженно забытых играх, их переизданиях и ремейках, железяках и source-портах. А ещё — пилит собственную игрушку про мистическую техподдержку Creepy Support. 👽 Увлечению Димы мы посвятили второй выпуск «Пет проектов», где программисты гуляют по полю с собаками из приюта Хаски Екб и рассказывают о своих хобби. Выбрали для вас несколько главных тезисов из этой прогулки. 👇 

С чего всё начиналось и чем мотивировался, чтобы не бросить

Я вместе со своим другом вёл текстовый блог (он всё ещё существует, вот ссылка на него), нам понравилось, и мы решили: а что, если пойти дальше и начать снимать видео? Я тогда как раз закончил институт и пришёл работать в Контур. 

Первая игра, на которую мы сделали обзор, называлась «Подземелья Кремля». Это шутер 1995 года от первого лица — российский ответ американскому Doom. 

Сейчас на моём канале 71 тыс подписчиков. А когда начинал, то думал: если до такого-то числа наберу сотню, прекрасно — продолжаем. Если нет — видимо, это не моё, займусь чем-то другим. И вот дата икс, я смотрю, а там 101 подписчик! Это был знак 👣 идти дальше.

Сначала я поставил себе цель — выпускать ролики не реже двух раз в месяц 

Потом понял, что это начинает превращаться во вторую работу, ещё и начальник [Дима сам себе директор] требовательный. 😁Решил: буду делать в максимально комфортном темпе — появилась интересная железяка > я её неторопливо в свободное время исследую > записываю потихоньку ролик > выкладываю. Сейчас у меня около четырёх сценарных видео в год, раньше было 8-10. Иногда проскакивают и не сценарные форматы — подкасты, реже — стримы.

Где нахожу старое железо для выпусков

На барахолках. Часто попадается что-то классное, например, трёхмерный ускоритель 95-го года или джойстик под MS-DOS довиндосовских времён. А ещё — ноутбуки, звуковые карты, игровые консоли… Там много интересных штук!

Как работаю над выпусками

• Помощников у меня нет, выпуски делаю сам от начала до конца: съёмка, монтаж, публикация. Если зритель указывает на ошибку, мне не на кого её спихнуть 😁, иду исправлять. А ошибки бывают — за всем не уследишь. Но к ним отношусь спокойно и не принимаю близко к сердцу.

• Закадровый текст я обрабатываю примерно один к двум: на 20 мин черновика выходит 10 мин готового текста. 

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

Блог забрасывать не хочу: мне нравится мой сегодняшний комфортный темп, плюс остаётся время на другие проекты. Например, я ещё делаю свою видеоигру под названием Creepy Support. Суть игры: ты играешь за работника техподдержки в тайной организации, в которую обращаются люди, столкнувшиеся с чем-то паранормальным. Например, кому-то на 15-м этаже постучал в окно человек или позвонил по телефону кто-то странный. 👻 Задача игрока — уточнить детали и дать совет, что человеку делать дальше. Потом можно даже узнать, как этот совет повлиял на жизнь того человека.

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

Что дают мне пет-проекты

• Я познакомился с кучей новых людей.

• Расширил кругозор. Например, для игры Creepy Support выбрал другой язык программирования, не тот, на котором пишу в Контуре. И это здорово помогает мне отвлечься от рабочих задач. 

***

Полный выпуск про Диму, его пет-проекты и ушастую Феню, с которой бродили по зелёному полю, можно посмотреть в VK Видео, на RuTube и YouTube. Подпишись на нас на любой из площадок, чтобы не пропустить новые видосы! 😉

Мой опыт в вайб-кодинге: AI-инструменты для создания приложений и первой игры-змейки! 🚀😂

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

В мастерклассе мы работали с такими инструментами:

• Cursor: Сначала мы использовали его для базового редактирования кода с AI-подсказками. Мы создавали простые веб-страницы, описывая дизайн и функционал в чате, и Cursor генерировал HTML/CSS/JS, а потом помогал отлаживать баги. Этот инструмент больше всего используется в сочетании с моделями вроде Claude Sonnet для генерации и редактирования кода.

• Harvi-pro и Harvi code: Этот инструмент мы применяли для интеграции GPT-моделей в кастомные приложения. Мы строили AI-ассистентов для обработки запросов, например, простого бота для рекомендаций, задавая промпты на русском, и Harvi-pro автоматизировал backend, а Harvi code помогал с генерацией и интеграцией кода в связке. Эти инструменты больше всего используются в сочетании с ChatGPT, VS Code и Cursor для создания GPT-ассистентов.

• Lovable: Здесь фокус был на быстрой сборке мобильных приложений. Мы пробовали создавать чат-боты и простые утилиты, просто описывая UI и логику в естественном языке, и Lovable строил полноценный прототип с деплоем. Этот инструмент больше всего используется в сочетании с Cursor для прототипирования приложений и UI-дизайна.

• Bolt: С Bolt мы экспериментировали с веб-разработкой в браузере. Мы создавали динамичные сайты, как лендинги или формы, просто загружая скриншоты или описывая "виб", и он генерировал код с мгновенным превью. Этот инструмент больше всего используется в сочетании с браузером и другими AI-инструментами вроде Cursor для быстрого создания прототипов веб-приложений.

• KiloCode: В нём мы работали как в VS Code с AI-агентом. Мы автоматизировали задачи, такие как генерация скриптов для обработки данных, и KiloCode сам проверял код, запускал тесты и исправлял ошибки. Этот инструмент больше всего используется в сочетании с VS Code и JetBrains IDE для автономной разработки и автоматизации задач.

Мне больше всего понравилось создание игр — это был мой первый опыт в такой сфере (я впал в детство и создал всеми известную игру змейку, в которую добавил несколько персонажей с уровнями сложности с боссом Пэкмена и Марио 😂).

Привет, хабровчане! 😊

Недавно я копался в мире ИИ-инструментов для разработки — тех, что помогают писать код быстрее и умнее. Знаете, когда сидишь за проектом и думаешь: "А не взять ли помощника, который подхватит идеи на лету?" Решил поделиться обзором нескольких интересных вариантов на рынке. Это не глубокий разбор с бенчмарками (для этого нужны отдельные тесты), а просто описание, чтобы понять, что можно выбрать под свои нужды. Я опираюсь на личный опыт и отзывы из сообществ — вдруг кому-то пригодится для экспериментов.

Давайте по порядку:

1. Cursor — это как эволюция VS Code с встроенным ИИ. Он автокомплитит код, генерирует фрагменты по описанию, понимает контекст проекта и даже помогает с отладкой. Подходит для тех, кто любит привычный интерфейс, но хочет ускорить рутину. Работает на Windows, macOS и Linux, есть бесплатная версия, но премиум открывает больше моделей ИИ. Идеально для соло-разработчиков или команд, где нужно быстро итератировать.

2. Harvi Code — российский продукт, первый в России аналог Cursor, построенный на мощной модели Sonnet 4.5 (от Anthropic, которая славится точностью и скоростью). Это расширение для VS Code и Cursor с удобным интерфейсом, как в знакомых IDE, плюс фокус на хороших ценах (не дерут втридорога за подписку). Подходит для генерации кода, отладки и работы с проектами. Если вы в РФ и ищете локальный вариант без заморочек с платежами — стоит попробовать.

3. Lovable — здесь акцент на создание веб-приложений без глубокого кодинга. Чат с ИИ: описываешь идею на естественном языке, и он генерирует full-stack app — от фронта до бэка. Удобно для прототипов или MVP, особенно если вы не хотите копаться в деталях. Поддерживает интеграции с базами данных и API. Минус — иногда нужно дорабатывать вручную, но для стартапов или хобби-проектов это спасение.

4. Bolt (bolt.new) — браузерный инструмент для быстрого создания сайтов, приложений и прототипов. Вводишь промпт — и вуаля, он строит всё от начала до конца, включая деплой. Работает с веб, iOS и Android. Круто для тех, кто хочет экспериментировать без установки софта. Есть интеграции с Expo для мобильных apps. Подходит новичкам или когда нужно быстро проверить концепцию.

5. Roo Code — это расширение для VS Code и Cursor, как целая команда ИИ-агентов прямо в вашем редакторе. Он анализирует весь проект, предлагает мульти-шаговые решения, ускоряет редактирование в 10 раз. Поддерживает разные модели ИИ (Anthropic, OpenAI), есть инструменты для автоматизации задач. Хорош для сложных проектов, где нужен глубокий контекст — не просто автокомплит, а умный помощник.

6. Kilo Code — открытый ИИ-агент в виде расширения для VS Code, JetBrains и Cursor. Генерирует код, автоматизирует задачи, предлагает рефакторинг. Есть система инструментов для взаимодействия с окружением (безопасно, с контролем). Бесплатный, с опцией кастомизации. Идеален для тех, кто предпочитает open-source и хочет интегрировать в свой workflow без лишних зависимостей.

В общем, выбор зависит от вашего стиля: если любите браузер — Bolt или Lovable; если вглубь кода — Cursor, Harvi, Roo или Kilo. Я пробовал пару из них на пет-проектах, и реально сэкономил время. Что вы думаете? Пользовались кем-то из списка? Делитесь в комментах, может, вместе разберёмся, какой подойдёт под разные языки или фреймворки. Буду рад обсуждению! 🚀

Ссылки для удобства:

• Cursor

• Harvi Code

• Lovable

• Bolt

• Roo Code

• Kilo Code

Делимся цифрами Next Fest: смотрите динамику и делайте выводы для своей игры

Я и еще два человека решили открыть данные игры на время Steam Next Fest. Мы отслеживаем:

1. Количество вишлистов

2. Количество уникальных игроков (сколько людей реально запустило игру)

3. Количество показов банера демо версии

4. Пик игроков за день

Интересно посмотреть на динамику этих показателей - как отработают алгоритмы Steam во время фестиваля. Если интересно мониторить, то вот ссылка на Google Sheets. Мы решили сделать для себя, но вдруг кому будет полезно.

Через пару дней после фестиваля документ закроем скорее всего.

П.С. На графике выводятся не абсолютные значения, а разница день ко дню.

Ты ему слово, а он тебе $: в ответ. Мой первый взгляд на Svelte

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

Игра представляла собой виджет, поставляемый в виде npm пакета и монтируемый прямо на сайт.

Я решил экономить по крупному и не затаскивать никаких библиотек или фреймворков. Хотел обойтись штатными средствами языка, без лишнего бойлерплейта. Основную бизнес логику написал быстро: баланс, механизм определения победителя, историю ставок. Но веселье началось, когда дошел до UI.

Чтоб все свистело и пердело, нужно было много динамических компонентов. Делать это нативными средствами оказалось мучением, и код быстро превратился в нечитаемое адище. В итоге пришлось пойти на компромисс: либо писать свой мини фреймворк под этот виджет, либо взять что-то из готового Vue или React.

Честно, не улыбался ни один из этих вариантов. Под мою задачу они оба казались слишком тяжелыми и избыточными. Мне хотелось взять всё лучшее от этих двух красавцев.

На помощь пришел Svelte, который я когда то отмел из-за избытка магии и слишком минималистичного синтаксиса. Решил дать ему новый шанс и не пожалел. Он похож на Vue и React одновременно: гибкость как у React, шаблонность и директивы как у Vue. При этом порог входа ниже.

Svelte не использует Virtual Dom, а точечно обновляет реальный, что делает его значительно легче. А вишенкой на торте стала концепция реактивных блоков.

Если проще, то все главные фишки Vue и React: computed, watch, React hooks лаконично объединены в одном операторе $:.

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

Svelte показался мне отличным решением из разряда “здесь и сейчас, быстро и дешево”. Минимум настроек, реактивность из коробки, и почти нулевая боль с состоянием. Для виджетов, прототипов или интерфейсов, идеально.

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

Студия Owlcat Games, известная по серии Pathfinder и Warhammer 40,000: Rogue Trader, запустила бесплатный справочник ресурсов для разработчиков игр. Проект реализован совместно с издателями Midwest Games и Fireshine Games, а также студиями Gaijin Entertainment (War Thunder) и 11 Bit Studios (Frostpunk, The Alters).

База данных размещена на отдельной странице сайта Owlcat и содержит более 350 обучающих материалов. Ресурсы охватывают геймдизайн, программирование, нарративный дизайн, управление проектами и другие направления. В коллекцию входят рекомендации по софту, туториалы, онлайн‑курсы и прочие справочные материалы.

Владимир Ликич — автор книги «Understanding Linux: The Kernel Perspective», обладатель учёной степени в области биоинформатики и просто энтузиаст Unix-подобных операционных систем. В своём микроблоге он иногда публикует различные факты про историю развития этой известнейшей операционной системы. К примеру, 9 октября он написал небольшой (192 слова) пост про терминал DEC VT100.

В ответ на твит оживился другой известный энтузиаст истории компьютерных технологий — Дейв Пламмер, ветеран Microsoft, зарекомендовавший себя в Вебе как автор первых версий «Диспетчера задач» Windows, порта 3D Pinball: Space Cadet на Windows NT и механизма активации Windows XP. Пламмер уже давно ушёл на покой и занимается травлей баек в личных блогах, но не отказывает себе в удовольствии покупать старые компьютеры и мини-ЭВМ.

Пламмер показал собственный экземпляр DEC VT100. Терминал подключён к PDP-11/34, на которой крутится 29BSD.

Конечно, читатель сразу обратит внимание на другое, куда более интересное устройство в кадре. Это игровой автомат в формате мини (так называемый cabaret) известнейшей Tempest. В комментариях у Пламмера на игровой автомат сразу же указал стример Кевин Гриффин.

Tempest — видеоигра 1981 года компании Atari, и её жанр безошибочно определяется как shoot'em up. Более продвинутый геймер даже укажет, что это тоннельный шутер, и будет полностью прав. Напомнить нужно лишь о том, что Tempest — первый представитель данного поджанра, именно здесь были заложены правила и нормы. За Tempest последовали Gyruss (1983) компании Konami и продолжения Tempest 2000, 3000 и 4000 руки Джеффа Минтера. Также Минтер вдохновлялся Tempest, когда разрабатывал TxK (2014).

В Tempest игрок управляет космическим кораблём, который передвигается по игровому полю в виде трубы сложной формы. Игра полагается на векторную графику, которая выводится на экран Quadrascan производства Wells-Gardner. Элементы игры рисуются не пикселями, а острыми светящимися линиями.

Этот экземпляр игрового автомата — уникальный. Как в ответе Гриффину пояснил Пламмер, у него в коллекции есть все три форм-фактора автоматов Tempest (стандартный вертикальный, горизонтальный, мини), но конкретно на этом Дейв никогда не играет. Тому есть очень интересная причина.

Автомат был получен от семьи бывшего сотрудника Atari. Как видно на фотографии, в памяти автомата остались рекорды некоего DFT. Их в начале восьмидесятых на рождественском корпоративе Atari поставил не кто иной, как Дейв Тьюрер, сам автор Tempest. Пламмер не хочет случайно перезаписать этот «автограф» создателя игры.

Гипер Шары теперь умеют играть не только в Линии, но и в Шахматы. Всё началось с идеи - а могут ли шары своими физиономиями подсказывать как они ходят? Оказалось, что очень даже могут. Их мнемоничность позволяет быстро освоить правила игры, даже совсем новичкам в шахматах.

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

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

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

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

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

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

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

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

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

Есть ли у нас тут мастера шах-фу, которые покажут этому примитивному автоботу, кто тут настоящий интеллект?

Посиделки с инди #5: The King is Watching и путь к 300к копиям. Много говорили про геймджемы. Профакапился с тем, что про управление командой мало расспросил, но даже без этого 2 часа вышло 😅

Немало поговорили про подход и мировоззрение, курсы и способы/пути обучения.

Где можно послушать/посмотреть:

• Ютубчик

• Spotify

• Apple Podcasts

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

Размышления визионера про идеи, задачи и реализацию:

Сначала появляется задача, запрос.

Затем появляется идея как эту задачу реализовать, ответ, наводка, подсвеченное решение.

Реализация идеи - это уже другая задача.

Т.к. запрос ставится обычно на конечное, сформированное решение, то в ответе тоже показывается сформированное решение.

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

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

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

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

P.S. можно потренироваться на поисковых запросах, промтах к нейронкам и на задачах людям 😁

Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)

Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.

Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:

(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )

1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.

2. "Strategy" - когда ты описываешь объекты как будто смотришь на описываемую систему снаружи (вид сверху), фокус на процессы взаимодействия всех объектов в жизненном цикле приложения, моделируются в первую очередь процессы и упускаются сущности.

3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)

И так же я пришел к тому что есть несколько слоев моделирования\проектирования:

(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)

1. Уровень реальности в которой есть человек пользователь, используемый девайс (десктоп, ноутбук, смартфон, и т.п.), сервер с бэкендом; правила их взаимодействия (интерфейсы, протоколы, договоренности); и процессы в которых это взаимодействие происходит (циклы, цепочки событий, потоки данных)

2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие

3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие

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

На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.

К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.

Такие дела :)

Я по прежнему считаю что ООП рулит! 😁

А что думаешь ты про ООП, архитектуру и чистый код?

Делись своим опытом в комментариях, или нет..

Ковырялся со старыми железками и на одной из них запустил комплектный OpenTTD в Линуксе. Чуть позже захотелось поиграть на основной машине из Steam. И вот играючи мне пришла в голову мысль (да-да, я частенько изобретаю велосипеды), что для подобной игры наверное было бы разумно делать наложение графики слоями, но не в лоб "слой1+слой2+слой3+слой4" и т.д., а хешировать уже созданные спрайты. Тогда процесс рисования выглядел бы не как "слой1+слой2+слой3+слой4", а "смотреть в хеш-таблицу", если совпадение, то "слой из хеша+слой4" (слой4 это например надписи), если мимо, то "слой1+слой2+слой3+слой4+записать в хеш-таблицу".

Если вернуться к OpenTTD, то слоями будут:

1. грунт/станции в нескольких ориентациях + уклоны + вода

2. несколько положений ж/д путей и автодорог, включая их пересечения

3. окультуривание готовых путей - заборчики

Финальные наложения например деревьев (включая их полупрозрачный вариант) в хеш не записывать например. Как и последний слой с надписями.

Если кто-то так делал, то напишите был ли эффект от этого?

Как вы справляетесь с усталостью при разработке игр и не только?

Привет, пользователи Хабр. Я одиночный разработчик, который временами выкладывает проекты на GitHub и itch.io. Несмотря на годы попыток, уровень моих скиллов остаётся низким: простое — на несколько сотен строк — я ещё делаю, но как только проект становится серьёзнее, я быстро выгораю. И всё же продолжаю (не без помощи ИИ).

Усталость, которая не лечится отдыхом

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

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

Это не только про код

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

Цикл один и тот же: выгораю, бросаю, возвращаюсь. Зачем? Может, ради людей, чтобы они что-то осознавали и отпускали. Может, ради себя и своего эго. Ответа у меня нет.

Вечный поиск «лучшей технологии»

Последние две игры я делал через выгорание. Вчера понимал логику — сегодня забыл. Дневники только запутывают сильнее.

В итоге это превратилось в бесконечную гонку за «лучшей» технологией. Я прыгал между Linux и Windows, изучал десятки языков. Был даже ассемблер (FASM) и попытка собрать вычислительный механизм в Minecraft. Всё частично работало, но только выматывало.

Советы не помогают

Фразы вроде «опирайся на то, что тебе нравится» — не работают. У меня небольшой прогресс есть в разных областях, но явного предпочтения нет.

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

Вопрос к сообществу Хабра

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

Очень прошу: без споров про ОС или ЯП. Это выматывает ещё сильнее.

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

Спасибо, что дочитали. Мне нужно было высказаться. Надеюсь, однажды каждый из нас найдёт свой ответ.

Разработчики ролевого MMO‑шутера Pioner показали одного из боссов игры — это Заводской Аннигилятор Явных Целей — сокращённо З.А.Я.Ц. (отсылка к механическому зайцу из «Ну, погоди!»).

Динамическое отражение в воде из текстовых символов

Сделал новый фон для боевых локаций: динамические отражения в воде из одних только ASCII-символов. Думаю использовать эту визуальную фичу в нескольких локациях. Как обычно, кроме текстовых символов (которые есть на любой клавиатуре) ничего не используется. Символы не масштабируются и не вращаются. Почти текстовый режим)) Алгоритм волн - упрощенный алгоритм Герстнера с двумя трохоидальными волнами. Чтобы считалось порезвее. Если вам нравится стиль, заходите на страничку игры в Стиме!

Исходный код был предоставлен одним из разработчиков игры, Святославом "Suavik" Образцовым, под лицензией правообладателя:

Все оригинальные файлы разработаны и предоставлены компанией Logos.

Лицензия позволяет публикацию и использование исходных текстов программ и данных с любыми изменениями при обязательном указании, что оригинальные файлы были разработаны компанией Logos.

All original files are developed and provided by Logos.

The license allows publication and use of source code of programs and data with any changes, provided that the original files were developed by Logos.

Ссылка на оригинальные исходники: https://archive.org/details/license_202509

Репозиторий Github с кодом: https://github.com/Marisa-Chan/rr2nw

Список инструментов low-code/no-code разработки и вайбкодинга для диплома

Всем привет. Я учусь в магистратуре ИТ-юрист и планирую писать диплом с рабочей темой "Правовые основы low-code/no-code разработки и вайбкодинга". Прошу накидать инструментов для анализа )

Основная цель работы простым языком - понять, если я разрабатываю продукт с использованием сервисов low-code/no-code (или ИИ-агентов в случае вайбкодинга), могу ли я его считать полностью своим или нет.

С правовой точки зрения задачи работы понятны - я буду анализировать лицензии, смотреть, как сервисы передают исключительные права пользователям, как обстоит ситуация с персональными данными в случае, если сервис иностранный.

Теперь передо мной стоит задача подготовить список подобных сервисов для дальнейшего анализа. Я сделала небольшую подборку и буду очень благодарна, если вы мне в комментариях подскажете еще подобные популярные платформы, которые позволяют вести разработку при отсутствии навыков программирования/либо минимальных навыках. Есть ли что-то подобное для разработки видеоигр?

• Разработка сайтов: tilda, wix, carrd, Collabza (личные кабинеты), Webflow, Craftum, Flexbe, Creatium, LPgenerator

• Автоматизация бизнес-процессов: битрикс24 (роботы), NBT, BPMSoft, ROBIN (российские решения), zapier, albato, Бипиум, Nodul, APInita

• Разработка приложений: bubble, glide, appmaster, adalo, appsfera, Stacker, QuintaDB, Directual, Bravo Studio, Thunkable, Voiceflow

• Вайб-кодинг: Cursor, Windsurf, Replit, Devin, Claude Code, Cline, GigaStudio (рус)

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

Представлен DOOM, где можно вырезать, копировать и вставлять противников. Грег Текнолоджи (он же Грег Садецки) на YouTube показал версию Chocolate Doom, в которой противников можно вырезать, копировать и вставлять по желанию, чтобы сделать игру немного интереснее. Очевидно, это означает, что вы можете вставлять своих нападающих несколько раз. («Они, конечно, не очень-то рады этому...» — говорит Грег в какой-то момент видео. «Но ведь их можно вырезать... как будто пылесосом вычищать».) В ответ на комментарий на YouTube Садецки объяснил: «Он хранит ссылку на тип монстра (у каждого монстра есть уникальный номер типа). «Так что да, их можно вставлять между играми!»

Глава Valve Гейб Ньюэлл считает, что нейросети всё активнее используются в игровой индустрии, а разработчикам нужно приспосабливаться к новым условиям.

Он рассказал, что разбирающиеся в ИИ разработчики очень скоро станут более ценными специалистами, чем программисты, которые работают по старинке. Касается это не только игровой индустрии, но и IT‑сферы в целом. «Люди, которые не умеют программировать, станут более эффективными разработчиками, чем те, кто занимается программированием уже десять лет», — заявил Ньюэлл.

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

Ньюэлл также утверждает, что искусственный интеллект станет неотъемлемой частью игровой индустрии и приведёт к росту игр с генеративным контентом.