У каждого разработчика есть тихая мечта сделать свою игру. У меня - точно есть.
Не обязательно Death Stranding с голливудскими актёрами, музыкой и бюджетом уровня "давайте просто построим новую студию".
Хотя бы маленькую. Но такую, где механика, мир и ощущение в руках складываются во что-то большее, чем набор кода и тасок.
Сегодня Хидео Кодзиме - 63.
Кодзима - автор Metal Gear Solid, культовой серии стелс-игр. Почти 30 лет он работал с Konami - японским издателем игр. После расставания с компанией основал Kojima Productions и выпустил Death Stranding игру про курьера в разрушенном мире, которая каким-то образом превратила доставку грузов в культурное явление. Собрал четыре его урока, которые я бы утащил в разработку, продукт и работу с командами.
1.Имя: актив, который нельзя отжать Когда Кодзима уходил из Konami, компания убрала его имя с обложки Metal Gear Solid V. Потом не пустила его получать награду за игру, которую он, вообще-то, сделал. Казалось бы: тебя вычеркнули из главного проекта жизни. Но Кодзима ушёл, собрал новую студию и выпустил Death Stranding. Люди пришли не в Konami. Люди пришли на фамилию. Компания владеет репозиторием, доменом, презентациями и продуктом. Но не репутацией человека. Мне нравится мысль, что личный актив строится параллельно с корпоративной карьерой.
2. Дорогие идеи надо проверять дёшево У ранней Kojima Productions не было нормальных павильонов и съёмочных площадок. Поэтому команда разыгрывала сцены будущей Death Stranding в пустой комнате. Зонты были оружием, сотрудники - персонажами, а съёмка способом понять: сцена вообще работает или команда очень дорого верит в ерунду. Мне кажется, это хорошее правило и для продукта. Если ядро продукта нельзя проверить прототипом, схемой на доске или одним абзацем текста возможно, ядра пока нет.
3. Не отдавать машине поиск смысла Кодзима говорит, что ИИ полезен в творческой рутине. Но саму идею, замысел и искусство он оставляет человеку.
ИИ отлично помогает разобрать хаос, написать черновик, накидать варианты, сэкономить часы на скучной работе и найти дырку в логике. Но он не отвечает на главный вопрос: зачем это вообще должно появиться в мире?
4. Случайности не случайны Кодзима критикует удалёнку (не из любви к офисным турникетам). Его мысль в другом: в удалённой работе становится меньше случайных столкновений людей. Разговоров у доски. Споров, начавшихся с ерунды. Фраз вроде: "А мы похожую проблему уже решали вот так". Из таких штук иногда рождаются лучшие решения. Хорошая случайность это среда, где у людей есть шанс наткнуться на чужую мысль раньше, чем она исчезнет в личных заметках.
Я всегда восхищался геймдизайном как отдельным видом искусства. Игра это продукт. Только требования к ней жёстче: мало, чтобы она работала и в ней не было багов. Нужно ещё, чтобы человек захотел остаться в этом мире хотя бы на один заход дольше, чем планировал. Наверное, поэтому геймдизайн мне так нравится: это инженерия, продукт, психология, искусство и немного магии в одном месте. И да. Когда-нибудь я всё-таки сделаю свою игру.
Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.
Кроме того, у панели было предусмотрено несколько настраиваемых режимов работы, которые переключались по запросу пользователя, что требовало массового управления маршрутами потоков данных внутри системы.
В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.
В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.
И что, получилась просто еще одна реактивная библиотека?
Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.
Каждый узел в графе потоков распространения данных явно декларирует свои способности: может ли он принимать данные через push, отдавать через pull, распространять полученный сигнал подписчикам, опрашивать источник, фильтровать, блокировать поток и т.д.
Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.
Ключевая идея: поведение системы описывается как композиция независимых возможностей, которые одновременно определяют тип, реализацию и правила взаимодействия.
Transferum предоставляет четыре слоя абстракции:
Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.
Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.
Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:
Определяют TypeScript-интерфейс трансфера на этапе компиляции.
Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
Обеспечивают совместимость в билдерах без приведений типов.
Один набор флагов — три потребителя. Это единый источник истины для всей системы.
Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:
Transfer
// гомогенный трансфер: T -> [ Transfer ] -> T
Или вот так:
Transfer
// гетерогенный трансфер: TInput -> [ Transfer ] -> TOutput
Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:
const pushChannel: Transfer;
const converter: Transfer;
// содержат методы push(), subscribe()
const manualBuffer: Transfer;
// содержит методы push(), pull(), trigger()
// trigger() в данном случае нужен, чтобы сделать запушенное значение
// доступным для чтения через pull()
const pollingProxy: Transfer
// содержит методы pull(), subscribe(), trigger(), activate(), deactivate(), toggle()
// может быть связан с pullable-источником благодаря поддержке поллинга
Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:
Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.
2. Мосты не знают конкретных реализаций
Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.
3. Значение undefined никогда не распространяется
В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.
Связывание трансферов
Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:
Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.
Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».
Поддержка backpressure
Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.
Локальная обработка ошибок
Transferum использует единую модель обработки ошибок для всех трансферов. Каждый трансфер, который может столкнуться с runtime-ошибкой, принимает опциональный onError-хэндлер в своей конфигурации.
А теперь — к примерам использования
Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:
А вот как можно организовать динамический роутинг:
import {
createPushStoredChannelTransfer,
createBridgeMultiSelector,
createBridgeSelector,
createPassBridge,
} from 'transferum';
// Вариант 1. Выбор одного реципиента
const commandRouter = createBridgeSelector({
bridges: {
light: createPassBridge({ source: commandChannel, target: lightController, activated: false }),
thermostat: createPassBridge({ source: commandChannel, target: thermostatController, activated: false }),
lock: createPassBridge({ source: commandChannel, target: lockController, activated: false }),
},
initialKey: 'thermostat', // выбор по умолчанию
activated: true,
owned: true,
});
commandRouter.select('lock'); // выберем другой вариант
// Вариант 2. Выбор нескольких реципиентов
const loggersRouter = createBridgeMultiSelector({
bridges: {
prometheus: createPassBridge({ source: metricsChannel, target: prometheusWriter, activated: false }),
elk: createPassBridge({ source: metricsChannel, target: elkWriter, activated: false }),
sentry: createPassBridge({ source: metricsChannel, target: sentryWriter, activated: false }),
},
initialKeys: ['prometheus', 'elk'], // будут активированы по умолчанию
activated: true,
owned: true,
});
loggersRouter.check('elk'); // теперь выбраны все три
loggersRouter.uncheck('prometheus'); // выбраны elk, sentry
loggersRouter.select(['prometheus', 'sentry']); // выбраны prometheus, sentry
А вот пример c организацией игровой механики:
import {
createDebounceTransfer,
createConvertTransfer,
createMapOperator,
createBridgeSelector,
createPassBridge,
linkTransfers,
} from 'transferum';
// Источник: debounce нажатий клавиш (16ms ~ 1 кадр при 60 FPS)
const rawInputSource = createDebounceTransfer({ delay: 16 });
// Конвертер: KeyboardEvent -> код клавиши
const inputConverter = createConvertTransfer({
operator: createMapOperator((event) => event.code),
});
// Целевые системы-потребители пользовательских событий
const carSystem = { push: (cmd: string) => console.log(🚗 Car executing: ${cmd}) };
const planeSystem = { push: (cmd: string) => console.log(✈️ Plane executing: ${cmd}) };
const menuSystem = { push: (cmd: string) => console.log(📋 Menu processing: ${cmd}) };
// Роутер: динамическое переключение между игровыми контекстами
const gameplayRouter = createBridgeSelector({
bridges: {
driving: createPassBridge({ source: inputConverter, target: carSystem }),
flying: createPassBridge({ source: inputConverter, target: planeSystem }),
ui: createPassBridge({ source: inputConverter, target: menuSystem }),
},
initialKey: 'driving', // игрок начинает в машине
activated: true,
});
// Связывание источника с конвертером с автовыбором стратегии
linkTransfers(rawInputSource, inputConverter);
// Демонстрация:
// Игрок в машине нажимает "W"
rawInputSource.push(new KeyboardEvent('keydown', { code: 'KeyW' }));
// Через 16ms: 🚗 Car: KeyW
// ==================
// Переключаемся на самолёт
gameplayRouter.select('flying');
// Та же клавиша теперь управляет самолётом
rawInputSource.push(new KeyboardEvent('keydown', { code: 'KeyW' }));
// Через 16ms: ✈️ Plane: KeyW
Когда имеет смысл попробовать Transferum
Библиотека подойдет для:
TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.
Результаты и планы
Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.
Буду рад, если вы заглянете в репозиторий, попробуете библиотеку в деле и поделитесь замечаниями — обратная связь поможет сделать Transferum лучше.
P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.
Уже давно есть коптеры, способные не только летать, но и плавать под водой. Летают быстро, плавают медленно. Используются в основном для обследования подводных сооружений и коммуникаций. Опоры мостов, состояние шлюзов, состояние кабелей, проложенных по дну водоёма. Прилетели, нырнули, поплавали, вынырнули прилетели обратно. Очень удобная и эффективная вещь.
GIF
Эта разработка Ратгерского унивеситета в Нью-Джерси датируется 2017м годом
Но тут швейцарские и американские инженеры разработали орнитоптер. Хрень, которая механически уподобляется птицам. И научили его как летать так и плавать. С одной стороны доказали, что в ныряющих птицах нет никакого чуда и получили весьма интересный опыт. А с другой стороны - как применять его на практике, ведь те же водоплавующие коптеры справляются с задачей лучше?
Кому интересно - можете глянуть на ютубе уже с переводом. Я не додумался как слить видос с русскими субтитрами https://www.youtube.com/watch?v=9XJhrKpcBGI
Судя по описанию под видосом, делали они это как раз для изучения механики ныряющих птиц, но с большим допущением - птицы крылья складывают сами, а тут каркас крыльев сделан деформирующимся, т.е. это не точная механическая копия птичек. Хотя, может всё ещё впереди…
Кстати, до недавнего времени и Вомбат использовал EditorJS. 😏
А ещё это был мой первый коммит, когда я не знал по сути ни Vue, ни Kapibara API. Да и TS был для меня чем-то новым. А матюки были до моих лапок.
Нынче матюков не осталось, а "//@ts-ignore" и прочие костыли, чтобы проверку пройти, сведены к минимуму.
Причём поиск пользователей был реализован до уведомлений. То есть, подсказку завезли, а уведомления - позже. Некоторые пользователи Капибары даже шутили, что колёса завезли, а телегу нет. 😏
P.S. да, да, сам себя не похвалишь - никто и не узнает.
P.P.S. так-то я сишник и ближе к таким пользователям как @IvanKr08 и @lovefst , но как и первый, я не зассал и сделал 😎
Недавно я рассказывал про хакатон, где мы пилили аналог NotebookLM для корпоратов (и, кстати, выиграли его). После этого мне захотелось принести эту идею домой.
Если вы вдруг пропустили этот хайп: NotebookLM - это гугловский сервис, куда ты закидываешь свои PDF, заметки или ссылки, и нейронка превращается в эксперта конкретно по твоим файлам. Можно чатиться со своими доками, вытягивать инсайты и даже генерить из сухих текстов аудио-подкасты. Надеюсь, кстати, что благодаря этой апке на Яндекс Музыке и VK теперь будут больше выпусками моих выпусков.
Open Notebook - это отличный open-source клон этой штуки. Это особенно актуально, учитывая, что с доступом к гугловскому оригиналу из РФ сейчас та ещё возня. К тому же мне хотелось забрать этот инструмент себе, чтобы скармливать доки локально и не сливать данные в чужие облака. (+ на русском не делает подкасты).
Но меня дико бесит, что сейчас для запуска полезного опенсорса нужно быть сеньор-девопсом и поднимать гирлянду из Docker-контейнеров.
Поэтому я психанул, форкнул Open Notebook и упаковал весь их web/Docker-зоопарк в одно нативное macOS-приложение. Цель была простая: скачал .dmg, перетащил в Applications, вставил API-ключ и всё работает.
Что под капотом и как это работает Приложение полностью privacy-first. Документы, настройки и встроенная векторная база (SurrealDB) лежат локально на маке. Парсить можно PDF, аудио, видео, сайты, а AI-провайдера выбираешь сам: хоть OpenAI или Anthropic, хоть локальную Ollama.
Звучит просто, но скрестить это всё оказалось больно. Исходник: Next.js, FastAPI и фоновые воркеры на Python. Я завернул интерфейс в Electron, а Python-часть собрал через PyInstaller.
Самым большим челленджем стали PDF. Парсер Docling тянет за собой Torch и нейромодели, из-за чего билд приложения раздувался до неприличия. В итоге я разделил поставку: в базе идёт лёгкий воркер, а тяжёлый OCR-движок юзер скачивает прямо из настроек аппки только если он реально нужен.
Ну и отдельный кайф desktop-разработки: заставить Electron корректно убивать дочерние Python-процессы при закрытии окна, чтобы они не висели в памяти призраками.
⭐️ Если вам зашла идея или просто хотите поддержать пет-проект - влепите звездочку репозиторию. Вам секунда, а мне лучшая мотивация пилить обновы дальше.
В планах на будущее: допилить сборки под Windows и Linux.
А пока у меня остался один незакрытый гештальт с macOS: сборка не подписана сертификатом Apple, поэтому при первом запуске мак ругается и просит разрешить аппку в Privacy & Security.
Глава CD Projekt Red Михал Новаковски рассказал о долгосрочных планах студии, и позиция разработчиков звучит неожиданно сдержанно для компании с таким числом анонсированных тайтлов в разработке.
В интервью Edge Новаковски дал понять, что CDPR не стремится к модели ежегодных релизов.
Наша мечта – делать больше игр, хотя мы никогда не хотим превращаться в студию, которая будет выпускать крупную игру каждый год.
Он добавил, что у студии есть примерный десятилетний план, но цель не в том, чтобы "наводнить рынок" играми от CDPR.
Между The Witcher 3 и Cyberpunk 2077 прошло пять лет, а новую полноценную игру в серии "Ведьмак" фанаты ждали больше десяти лет. При этом сейчас в разработке у CD Projekt Red находится сразу несколько тайтлов.
Список довольно внушительный:
дополнение "Баллады прошлого" к The Witcher 3
The Witcher 4 и два её сиквела
ремейк The Witcher 1
мультиплеерная игра по вселенной "Ведьмака"
продолжение Cyberpunk 2077
загадочная Project Hadar
Студия намеренно ограничивает число своих франшиз. CDPR явно делает ставку на глубину, а не на широту охвата:
Мы не планируем расти в этом направлении.
При таком числе тайтлов в разработке ближайшее десятилетие студии обещает быть куда более насыщенным, чем предыдущее, – даже без перехода на режим конвейера.
Применение генеративного ИИ и больших языковых моделей остаётся одной из самых спорных тем в современной игровой индустрии.
Игроки и критики всё внимательнее изучают страницы новых игр в Steam, выискивая упоминания о том, использовались ли подобные технологии на этапе разработки. Многие прямо просят Valve о фильтре, который позволит полностью исключить игры, созданные с использованием ИИ из выдачи.
Take-Two, материнская компания Rockstar, до апреля содержала отдельное подразделение, занимавшееся исследованием возможностей ИИ в разработке игр. Затем, по данным СМИ, весь этот отдел был распущен. Решение оказалось неожиданным на фоне того, как другие студии либо тихо внедряют генеративный ИИ, либо открыто заявляют о его использовании в производственном конвейере.
Примечательно, что большинство сотрудников уволенной команды вовсе не занимались генеративным ИИ. Подразделение зародилось ещё в мобильной студии Zynga, которую Take-Two приобрела в 2022 году, а позже его задачи расширили на всю корпорацию.
В беседе с GamesIndustry.biz доктор Люк Дикен, бывший руководитель отдела, рассказал, что команда была основана в 2019 году, задолго до публичного запуска ChatGPT и последовавшего бума интереса к генеративным моделям.
Генеративный ИИ никогда не был тем, чем я особенно увлекался. Я считаю, есть моральная обязанность следить, чтобы им распоряжались максимально ответственно, но при этом надо понимать, что для любой крупной корпорации в 2025/2026 году полный отказ от генеративного ИИ это неверный ответ, который многих разозлит.
Дикен признал, что тема поляризующая, но добавил, что "некоторые перегибы генеративного ИИ настолько вопиющи, что нужно уметь давать отпор". Куда больше его интересует целостный взгляд на ИИ, а не только на его генеративную разновидность.
Пять лет назад вы могли сказать, что у вас есть алгоритм, который реально ускорит генерацию уровней в мобильной игре. Тогда на нас смотрели как на сумасшедших. Сейчас хайп вокруг ИИ создал среду, в которой я могу заявить, что ИИ переведёт вашу игру на квантовые вычисления, и люди будут кивать и говорить: "Да, нам нужен ИИ в игре".
По словам Дикена, у этой ситуации есть плюс, ведь разработчики стали восприимчивее к разговорам о том, что традиционные методы могли бы дать им многое ещё годы назад. Люди охотнее верят, что подобные решения существуют.
Однако из-за раздутого хайпа вокруг генеративного ИИ многие могут полностью отвернуться от области исследований ИИ, если пузырь лопнет.
Меня беспокоит, что генеративный ИИ отравляет колодец. Не думаю, что есть достаточно тонкости и нюансов, чтобы сохранить традиционные подходы. Что касается LLM, мы уже свалились в яму разочарования.
Привет! Хочу поделиться своим проектом, который решил возродить пару недель назад — мессенджер на Python. Не сомневаюсь, что такие штуки уже есть на просторах интернета и могут быть лучше того, что делаю я, но меня это не интересует. Мне нравится делать что-то самому, разбираться и по возможности «не зависеть» от чего-то.
Что это вообще такое
Это чат с клиентской и серверной частью, который работает через сокеты. На данный момент всё происходит в консоли, но в планах GUI на PyQt5. Сервер поднимается локально, клиенты подключаются к нему и начинают взаимодействовать с помощью различных команд. Клиент должен иметь аккаунт на сервере для ряда функций, поэтому первым делом он регистрируется либо входит в аккаунт. Показываю команды пользователя ниже.
Команды пользователя
🔐 Авторизация и регистрация
/reg <юзернейм> <пароль> <пароль> — зарегистрироваться на сервере
/auth <юзернейм> <пароль> — аутентифицироваться на сервере
👤 Профиль и общение
/set_nick <никнейм> — установить отображаемый никнейм
/msg <никнейм> <сообщение> — отправить личное сообщение
/offline_sms — получить сообщения, пришедшие в ваше отсутствие
/get_users — посмотреть список пользователей
📂 Файлы
/all_files [количество] — показать последние файлы (все, если число не указано)
/send_file <никнейм> <имя_файла> [текст] — отправить файл из папки data/files
Если честно, всё было в меру сложно. Конечно, чем больше папок и файлов, тем больше нужно помнить в голове и сложнее организовывать что-либо. Но всё же трудненько было сделать систему для обмена файлами, потому что пришлось параллельно думать об очереди сообщений, и в моменте я вообще ничё не понимал. Я ожидал, что придётся дебажить, но на удивление пришлось этим заниматься не очень-то и долго — всего день.
Про технологии и логику
Хочу также затронуть некоторые технологии, которые я применял. Одна из них — хэширование (hashlib + secrets). Я применял его для регистрации и аутентификации пользователей, чтобы по сети не гуляли пароли. Однако всё равно можно перехватить запрос на авторизацию:
request = self.encode({
'type': 'auth',
'username': parts[0],
'hash': hash_b64
})
И по сути войти в чужой аккаунт, скопировав этот запрос и отправив на сервер от себя. Типа да, пароль никто не узнает, но хэш-то стырить можно. В общем, не всё идеально.
Ещё я использую потоки (threading) для параллельных задач. Например, приём и отправка запросов идут в разных потоках на клиенте. А на сервере вообще под каждого клиента свой поток запускается.
Также недавно узнал про классную штуку в Python — декораторы. Очень хорошо очищают код и местами упрощают логику. Ещё датаклассы — аналогично упрощают жизнь, особенно при перекрёстных передачах параметров в экземпляры классов, коих у меня немало.
Планы на будущее
Как уже говорил, буду делать GUI, ещё хочу уведомления о сообщениях, локальную историю переписок и шифрование. Шифрование буду делать симметричное — самый незапарный вариант, для чата с друзьями за глаза.
Кстати, я не просто так это всё делаю: хочу в будущем купить Raspberry Pi и поднять свой сервер для этого мессенджера. Ну и по мелочи: группы (может и не добавлю, так как на 10 человек незачем), мобильная версия, если прям будет желание, ну и оптимизация, безопасность и так далее.
GitHub и Telegram
Кто хочет посмотреть — велкам, можно даже пулл-реквесты делать)
Gotcha Gotcha Games, разработчики серии RPG Maker, выпустили крупное обновление для инструмента создания игр Action Game Maker.
Релиз версии 1.3.0 состоялся 17 июня и приурочен к годовщине выхода программы. Главное нововведение – поддержка 3D-фонов, позволяющая разрабатывать игры в стиле 2.5D.
Action Game Maker появился в Steam в 2025 году и стал преемником Pixel Game Maker MV. Инструмент рассчитан на создателей без навыков программирования и позволяет разрабатывать 2D-игры разных жанров, включая платформеры, экшен-RPG и прочие жанры.
В основе программы лежит открытый игровой движок Godot, обеспечивающий доступ ко всем его 2D-возможностям.
Хотя движок полностью поддерживает стандартное написание кода на GDScript, в нем также доступен визуальный язык программирования на основе нод, разработанный специально для непрограммистов.
Помимо функций Godot, инструмент предлагает возможности в духе RPG Maker, такие как система баз данных, инструменты для смены сцен, 2D-анимация костей и библиотеки графических и аудиоресурсов.
С новым обновлением пользователи могут загружать 3D-модели в качестве окружения для своих игр. Эту функцию давно просили в сообществе. Стоит отметить, что 3D-контент существует отдельно от 2D-пространства геймплея, однако может работать как параллакс-фон, синхронизированный с 2D-элементами, например следовать за движением 2D-камеры.
Еще одним значимым дополнением стали кастомные плагины действий, вдохновленные системой плагинов из серии RPG Maker.
Эта возможность позволяет создавать оригинальные Условия (Conditions) и Действия (Actions) с помощью GDScript. Подробности об обновлении и дальнейших планах разработчиков опубликованы в Producer Letter #19 на странице Action Game Maker в Steam.
После двух лет, в течение которых ИИ-ассистенты стали привычной частью разработки, в индустрии наметился обратный процесс.
Часть компаний урезает бюджеты на ИИ-инструменты, и программисты возвращаются к ручному написанию кода. Поводом служит не разочарование в технологии, а её стоимость.
Картина у затронутых команд схожая. Корпоративные подписки на ассистенты вроде GitHub Copilot и Claude переводят на более скромные тарифы, лимиты ужесточают, и месячная квота заканчивается за полторы недели. Задачи, которые недавно закрывались за минуты, снова растягиваются на часы, как в эпоху до больших языковых моделей.
У возврата к ручной работе нашлась и светлая сторона. Разработчики обнаруживают, что навыки анализа, отладки и программирования никуда не делись даже после долгого перерыва. Многие отмечают, что снова ощущают полный контроль над архитектурой, тогда как ассистент порой строил неверные предположения о критических и незнакомых случаях.
Главная причина отката кроется в экономике. Личная подписка за 100–200 долларов в месяц и корпоративный доступ через API живут по разным законам. По словам разработчиков, на крупных и легаси-кодовых базах сумма в 200 долларов способна закончиться всего за один рабочий день, а опытный инженер на полном ходу сжигает до тысячи долларов в сутки.
Отсюда и решения руководства. Когда счёт привязан к фактическому потреблению токенов, расходы становятся плохо предсказуемыми, и финансовый отдел реагирует урезанием. Критики такого подхода считают его близоруким, так как потеря скорости обходится дороже сэкономленных подписок. Правда, экономически это пока не подтверждено – лишь громкие заявления.
Параллельно развернулся спор о том, за что вообще платят программисту. Одна сторона настаивает, что инженера нанимают писать код, и жалобы на возврат к этому занятию выглядят странно. Другая возражает, что ценность работы измеряется готовыми функциями и решёнными задачами, а ИИ здесь лишь инструмент.
В ход идёт сравнение с плотником. Мастера нанимают не ради того, чтобы он пилил доски вручную, а ради готовой мебели, и электроинструмент ускоряет процесс, не отменяя нужды в умелых руках, опыте и знаниях. По этой логике компания, отказавшаяся от ускорителя, рискует отстать от конкурентов.
Тем, кто оказался в урезанном режиме, советуют грамотнее распоряжаться токенами. Дорогие модели вроде Opus предлагают держать для планирования и анализа, а исполнение отдавать более дешёвым Sonnet и Haiku. Само дописывание кода нередко закрывают очень дешевые или даже бесплатные модели.
Отдельно отмечают, что наибольшую пользу нейросеть приносит при чтении кода, а не при его написании. Разбор незнакомой кодовой базы, поиск мест для новой функции, обобщение документации и быстрый второй взгляд экономят больше всего времени. Управление контекстом при этом превращается в отдельный навык, ведь привычка вываливать в окно диалога весь репозиторий съедает лимиты быстрее всего.
Как запасной вариант обсуждают локальные модели вроде Qwen, DeepSeek и Kimi, хотя их обслуживание требует отдельной команды и оборудования. Чистка истории диалога и работа малыми порциями тоже помогают растянуть квоту.
Единого мнения о последствиях нет. Часть разработчиков уверена, что без ИИ команда неизбежно проиграет гонку более расторопным соперникам. Другие отвечают, что качество кода без постоянной генерации остаётся прежним, а скорость падает не так сильно, как пугают сторонники тотальной автоматизации.
Студия NEARstudios объявила об участии в Steam Next Fest и уже запустила демоверсию своего ролевого сурвайвала с открытым миром Hawthorn. Попробовать игру в Steam можно бесплатно до 22 июня.
В Hawthorn предстоит примерить роль антропоморфного зверя, обживающего лес. Мир вдохновлён сказками викторианской эпохи и классическим фэнтези.
Игра поддерживает одиночное прохождение и онлайн-кооператив. В роли совы, мыши или другого зверька игрок строит деревню посреди живописного леса, возводит дома, занимается фермерством и рыбалкой, а собранные ресурсы пускает в крафт. В поселении живут NPC, и с теми, с кем удалось подружиться, можно делить часть работы.
За пределами деревни открывается окрестность для исследования. Пустоши и каньоны меняют облик в зависимости от сезона и погоды, а в них спрятаны ресурсы и сокровища, которые предстоит собирать и приносить домой. Снаружи встречаются и враждебные силы, и игрок сам решает, вступать в бой или искать мирный путь.
Помимо этого случаются разные случайные события, а порой деревню атакуют природные угрозы. Эти испытания приходится преодолевать, защищая поселение.
Доступная сейчас в Steam демоверсия представляет собой ранний прототип, сосредоточенный на строительстве деревни. С её помощью студия показывает задуманную атмосферу, потенциал игры и упор на свободу действий, а заодно собирает отзывы для дальнейшей разработки.
Все вокруг хвалят Supabase за скорость. И да, я тоже повелся. Как бэкендера меня поначалу знатно корежило от того, что фронт ходит тупо прямиком в базу. Но ради быстрой доставки фичей я зажмурился.
Спойлер: пилится-то всё реально быстро. Только потом ты ловишь тихие баги, пропадающие логи и жесткий вендор-лок. Я собрал на Supabase уже несколько проектов и успел поседеть.
Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).
Логи.Их просто нет
Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.
Edge-функции и проклятые холодные старты Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее — холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ru edge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.
Палево с доменами в OAuth Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делалphoto math, целый час дебажил эту хрень. Думал, что сам где-то накосячил — на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.
Хаос со схемами БД Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.
Тормоза локальной разработки Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свежие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.
Тихие RLS-ошибкиRLS (Row Level Security) ошибается молча. Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.
Транзакции и боль SQL-функций Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи.Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.
Вендор-лок Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.
Короче. Для MVP или пет-проекта, чтобы просто проверить гипотезу на коленке - это топ. Да, часть этих костылей можно вылечить, если закинуть денег и перейти на платную версию. Но возникает резонный вопрос: за те же 25 баксов в месяц можно спокойно поднять Supabase на нормальной VPS-ке и вообще забыть про лимиты.
Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк? Дебаж 🐞с ноги 🦶
Забавно, но сейчас OpenAI и Anthropic фактически оплачивают мне разработку пет-прожектов из своего кармана. Ребята из SemiAnalysis провели крутой стресс-тест: купили максимальные тарифы ChatGPT Pro и Claude Max (по $200 в месяц) и гоняли на них хардкорные агентурные таски, пока не уперлись в недельные лимиты. Потом они пересчитали потраченные токены по официальным API-прайсам. Оказалось, что из Claude Max за 200 баксов можно выжать лимитов на $8 000. А из ChatGPT Pro (20x) — на безумные $14 000.
Для меня это вообще не абстрактные цифры. Я постоянно юзаю агентов (в связке с тем же Cursor) и скармливаю им гигантские простыни кода. При таком подходе маржинальность OpenAI улетает в жесткий минус: они работают в убыток уже после того, как юзер тратит 5,7% от лимита. По сути, люди, которые за $20 генерят по три письма в день, спонсируют технарей вроде меня, выжимающих из моделей все соки.
Какой продуктовый вывод я делаю для себя?
Для честной работы по API надо искать аналоги у китайских друзей — те же DeepSeek или Qwen стоят копейки, а с кодом справляются отлично.
А вот для тяжелых локальных тасков, парсинга и агентов, пока эту дыру не прикрыли, выгоднее веб-подписки OpenAI/Anthropic (через эмуляцию или прокси), чем платить им за API.
Недавнописал, что вписался консультантом в проект Signal. Бекенд развернут на self-host Supabase. Мне дико не нравится работать с их логами, поэтому решил поднять VictoriaLogs + VictoriaMetrics и прикрутить Grafana как UI.
Вся эта связка живет на одной железке в докере. У такого конфига есть только одна огромная проблема это безопасность. Виктория из коробки вообще не идет ни с какой авторизацией. Обычно это не парит: засовываешь всё за VPN и забываешь. Но с 2025 года с VPN всё туго. Его надо постоянно поддерживать и оживлять, а времени на это нет.
Отсюда вопрос: как не светить Викторию голой в сеть, но при этом иметь доступ к админке, если вдруг что сломается?
Докер сам строит внутри себя сети, и контейнеры отлично общаются по адресам типаgrafana:3000. Мой локальный браузер про эти внутренние адреса на VPS, конечно, ничего не знает. Но оказалось, что кто-то уже столкнулся с этой проблемой до меня и собрал докер-образ с Хромом (lscr.io/linuxserver/chromium).
Работает это так: на удаленной виртуалке поднимается браузер, к которому я подключаюсь из своего обычного браузера. Получается такой фрейм прямо в приватную сеть докера. Сидишь и вбиваешь в строку имена контейнеров. Естественно, сам веб-интерфейс этого Хрома надо закрыть паролем, иначе вся затея теряет смысл.
Штука прикольная. Можно даже срезать качество картинки и FPS, если инет тупит. Но есть боль с буфером обмена. Текст просто так не скопируешь, приходится пихать его в отдельное окошко. Плюс у меня Мак сcmd+c/v, а на сервере крутится линукс сctrlи мозг при переключении немного ломается.
Как итог, костылем я доволен. Собрал себе админку без VPN, в которую буду залезать может раз в полгода, но зато без боли.
А как вы сейчас прячете внутренние тулзы на пет-проектах? Страдаете с ключами и туннелями или есть решения проще?
Если верить одной широко раскрученной байке, то в режиме огибания рельефа местности автопилот истребителей F-16 израильских ВВС выходил из строя при полете над Мертвым морем. Высота машины в какой-то момент пересекала отметку "уровня моря", происходило деление на ноль отчего у автопилота приключался паралич мозга.
Чего уж говорить, если фирма Lockheed Martin может так опростоволоситься, то что взять с нас, простых разработчиков игрушек?
На моей памяти из проектов Nival Interactive наиболее урожайным на комичные баги был Блицкриг 2. Если кто не знает, это такая стратегия на тему второй мировой. Очень кстати смешная даже и без багов. У нас был строгий немецкий издатель, а немцы они страсть какие пугливые до всего что связано с их нацистским прошлым. Упоминать имя фюрера нельзя, слова типа "нацистский", "фашистский" тоже табу, даже свастика у нас была не настоящая, а стилизованная. И это при том, что между миссиями у нас были ролики, поясняющие какие-то исторические события связанные с игровым процессом. В результате получилась эдакая гламурная войнушка в стиле галантного века только с танками и бомбардировщиками без особых претензий на историчность. Кстати, видя какое у нас получается непотребство, наш военный консультант попросил убрать из титров его имя :)
ФАУ-2 - это такая немецкая мегапетарда. Германия ими под конец войны докучала Великобритании, но без особого успеха. Вундерваффе страдало от кучи детских болезней и хорошо если могло оторваться от земли. Зачастую взрывалась прямо на стартовом столе, а уж коли отрывалось да еще и летело в сторону Англии, то уж вообще успех. Горючее, между прочим, 3,5 тонны этилового спирта :)
Фиг.1. Вундерпетарда.
Ну, сделали и мы в Блицкриге эту самую ракету. Как и немцы, сделали ее уже ближе к концу проекта и соорудили на базе объекта "самолет". Но программисты несколько схалтурили и не пооткручивали у бывшего самолета подозрительную для баллистической ракеты функциональность. Оказалость, что если во время полета к цели начинал идти дождь или снег, то во-первых ракета говорила человеческим голосом "Fliege zuruck"(нем. лечу назад), а во-вторых разворачивалась и летела обратно на базу. Фигли там, погода то нелетная.
А еще был у нас замечательный юнит - отряд спецназовцев. Войска у нас могут получать в ходе миссии опыт, а за опыт дают всякие интересные способности. Так вот, донельзя прокачанные спецназовцы получали возможность маскироваться под вражескую пехоту. Достаточно было просто кликнуть в отряд неприятельских солдатиков, и наши бойцы переодевались в их форму. Можно было безнаказанно разгуливать по вражеской базе. Ну, до первого выстрела, конечно.
Но, беда в том, что в Блицкриге кроме собственно пехоты еще были всякие антуражные юниты, типа коров, свиней и собак. Выяснилось, что спецназ вовсе не чурается переодевания в бобиков и хавроний. Если учесть, что механизм этого самого переодевания несколько глючил и часть отряда можно было нарядить в одну форму, часть в другую, то можно было создавать совершенно безумные подразделения. Например, отряд из собак, свиней и панцергренадеров. Учитывая, что отряду можно отдавать всякие приказы типа "маршировать", "ползти" и т.д., то игроку предоставлялась уникальная возможность полюбоваться марширующими свиньями. Получалось это у них, впрочем, паршиво, потому что скелет свиньи не соответствует скелету пехотинца и выглядит это как отряд ездящих не попе хрюшек. А еще этот цирк-шапито можо было запихать в окоп. Сидят, значит, свиньи с собаками в окопе и периодически из него выглядывают.
Фиг.2. Свинко.
Со свиньями был связан, кстати, еще один баг, из-за которого игра падала. В какой-то момент программисты что-то такое там подкрутили и свиньи перестали быть нейтральными, а обрели возможность принадлежать какому-то игроку. Управлять ими было нельзя, но формально они могли быть "наши" или "ненаши". Так вот свиньи роняли игру. Потому что видя неприятеля, патриотичная хавронья хотела дать врагу отпор и лезла за оружием, которого у нее естественно не было. Если мне не изменяет память, программисты исправили баг, просто выдав свинье пистолет Люгер без патронов. Визуально это никак не видно, но формально, теперь, видя врага, она лезет за оружием, видит что патронов нет и на этом успокаивается.
Кстати, собака, в отличие от свиньи, может кусаться. И число укусов у нее ограничено, кабы не соврать, десятью тысячами. Потом у барбоса кончаются "патроны", и он становится безобидным. Кстати интересный вопрос, я не проверял, будет ли грузовик снабжения, который подвозит боеприпасы, подносить патроны собаке?
JIRA ISSUE #182355 Type: BUG Priority: MEDIUM Created: 21.02.12 18:21 Description: С "Дзуйкаку" взлетает "Зеро" с маркировкой авианосца "Кага".
21.02.12 18:30 Elena Ivanova [community manager] commented: наблюдательные товарищи пишут в интернете что у нас на утекших в сеть скриншотах на самолетах не та маркировка цветные полосы а должны быть белые
22.02.12 11:51 Elena Ivanova [community management] reassigned to Sergei Lodkin [qa lead] оформите баг чтобы исправили а то позоримся
05.03.12 15:41 Sergei Lodkin [qa lead] reassigned to Mihail Dorenkov [qa engineer]
11.03.12 10:42 Mihail Dorenkov [qa engineer] reassigned to Alexander Rozhko [art director] Надо нанести на самолеты две белые полосы.
06.04.12 11:13 Alexander Rozhko [art director] reassigned to Semen Kemshakov [3d artist]
17.04.12 15:50 Semen Kemshakov [3d artist] reassigned to Tatiana Severina [textures artist] Нужны две одинаковые белые текстуры для полосок. Очень надо!
20.04.12 11:10 Tatiana Severina [textures artist] reassigned to Alexandra Lebedeva [2d artist] нужны эскизы двух белых полосок, а то я не знаю, на что они похожи
24.04.12 12:00 Alexandra Lebedeva [2d artist] reassigned to Tatiana Severina [textures artist] У нас полный завал. Полоски сможем не раньше, чем через два месяца.
01.05.12 18:34 Tatiana Severina [textures artist] reassigned to Alexandra Lebedeva [2d artist] можешь сверхурочно поработать? может, дома? это же пара часов, не больше. очень надо!
02.05.12 12:30 Alexandra Lebedeva [2d artist] reassigned to Tatiana Severina [textures artist] Взяла работу на дом, ночью засела рисовать. (((((( Парень мой спрашивает: "Чего не спишь?" А я ему: "Да понимаешь, у меня тут тут две полоски..." Обернулась - а его нет. Где теперь его искать? ((((((
02.05.12 15:54 Tatiana Severina [textures artist] reassigned to Semen Kemshakov [3d artist] похоже, текстур не будет. возьмите пока любую похожую текстуру, потом заменим, когда сделаем
11.05.12 12:13 Semen Kemshakov [3d artist] reassigned to Andrei Hobotov [programming lead] Я замоделил две белых полоски, лежат на системном диске. Теперь надо, чтобы движок крепил их к самолетам.
08.06.12 10:33 Andrei Hobotov [programming lead] reassigned to Alexei Mshigorotchitskii [junior programmer] Леша, прицепи к самолетам по две белые полоски.
08.06.12 12:11 Alexei Mshigorotchitskii [junior programmer] reassigned to Andrei Hobotov [programming lead] Вдоль или поперек?
10.06.12 17:14 Andrei Hobotov [programming lead] reassigned to Konstantin Krainihin [historical consultant] Вдоль или поперек?
10.06.12 17:15 Konstantin Krainihin [historical consultant] reassigned to Andrei Hobotov [programming lead] Поперек
11.06.12 18:35 Andrei Hobotov [programming lead] reassigned to Alexei Mshigorotchitskii [junior programmer] Поперек
14.06.12 18:35 Alexei Mshigorotchitskii [junior programmer] closed issue. Готово
17.06.12 14:30 Mihail Dorenkov [qa engineer] reopened issue. Не видно что-то
21.06.12 11:51 Alexei Mshigorotchitskii [junior programmer] commented: Как не видно? Вчера в релиз ушло. Тестеры в недоумении, уже триста писем с вопросами, что это за странные полоски на всех самолетах.
25.06.12 12:50 Mihail Dorenkov [qa engineer] commented: В какой релиз? Даже альфа еще не началась.
01.07.12 12:21 Mihail Dorenkov [qa engineer] commented: World of Warships
01.07.12 19:30 Alexei Mshigorotchitskii [junior programmer] reassigned to: Andrei Hobotov [programming lead] Я программист World of Warplanes. Смотрите внимательнее, кому баги перекидываете.
07.07.12 14:57 Andrei Hobotov [programming lead] reassigned to Alexei Mshigorotchitskii [junior programmer] Леха, прикинь, в Киеве твой однофамилец работает. Только он Мщигорочицкий, а ты Мчигоротчитский.
07.07.12 14:58 Alexei Mshigorotchitskii [junior programmer] reassigned to: Andrei Hobotov [programming lead] Я в курсе, что я там работаю. Я из за ваших гребаных полосок такой нагоняй получил. Теперь вычистить не можем - во все бранчи уже просочились.
07.07.12 14:59 Andrei Hobotov [programming lead] commented: Упс... сорька. Опять не тому перекинул.
07.07.12 15:00 Andrei Hobotov [programming lead] reassigned to Alexei Mchigorotchitskii [junior programmer] Леха, прикинь, в Киеве твой однофамилец работает. Только он Мщигорочицкий, а не Мчигоротчитский.
16.07.12 13:01 Mihail Dorenkov [qa engineer] reopened issue. Почему закрыли несделанный таск?
20.07.12 09:31 Andrei Hobotov [programming lead] commented: Леха, ты выше-то почитай, что сделать надо.
21.07.12 15:59 Alexei Mchigorotchitskii [junior programmer] commented: Ааааа... я думал, ты таск завел, чтобы про однофамильца рассказать. Еще удивился, чего не по аське, в одной же комнате сидим.
21.08.12 11:09 Alexei Mchigorotchitskii [junior programmer] closed issue. Сделано
23.08.12 14:37 Mihail Dorenkov [qa engineer] reopened issue. Истребители перестали сбивать. Не могут стрелять.
01.09.12 13:26 Alexei Mchigorotchitskii [junior programmer] assigned to Andrei Hobotov [programming lead] Я не понимаю, в чем дело.
15.09.12 19:03 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer] Боря, проверь, в чем там дело.
04.11.12 09:23 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead] Полоски закрывают пулеметы. А на них материал, в котором прописана коллизия для пуль. Пули не проходят.
11.11.12 10:00 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer] Как полоски могут закрывать пулеметы, если полоски нанесены в задней части фюзеляжа?
14.11.12 11:11 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead] А у нас у истребителей настоящие пулеметы как раз в задней части фюзеляжа. А в крыльях - фейковые, для вида только, пыщ-пыщ делать. Так исторически сложилось, уже не помню, почему. Теперь долго переделывать, на это вся их баллистика завязана.
05.12.12 12:07 Andrei Hobotov [programming lead] reassigned to Semen Kemshakov [3d artist] Зачем полоски коллизят пули? Сними с них коллизию.
12.12.12 12:03 Semen Kemshakov [3d artist] reassigned to Andrei Hobotov [programming lead] Я не могу, у нас коллизии захардкожены в текстурах, а других текстур нет. Эту вырезал с Флетчера, самая белая текстура, какую нашел. А у него там броня четыре сантиметра.
27.12.12 11:34 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer] У нас правда коллизии захардкожены в текстурах? Нельзя их оттуда вынести в отдельную настройку?
14.01.13 17:00 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead] Да как же их вынесешь? У нас же честный расчет пробития, с учетом карты нормалей текстуры, а в альфа-канале у нее усталость металла закодирована.
03.02.13 12:12 Andrei Hobotov [programming lead] reassigned to Tatiana Severina [textures artist] Сделайте уже нормальные текстуры для полосок, только визуал. Сколько можно тянуть?
12.02.13 15:45 Tatiana Severina [textures artist] reassigned to Alexandra Lebedeva [2d artist] как там насчет эскиза?
13.02.13 11:15 Alexandra Lebedeva [2d artist] reassigned to Tatiana Severina [textures artist] Говорила же уже: у нас завал, сможем не раньше, чем через два месяца. Срочно перерисовываем все миникарты, сказали поконтрастнее выделить сушу. Кто как, а я выделяю более темненькой водой. Ночью работать больше не буду (((((((
14.02.13 11:10 Tatiana Severina [textures artist] reassigned to Andrei Hobotov [programming lead] у нас завал. сможем не раньше, чем через четыре месяца.
01.03.13 18:20 Elena Ivanova [community manager] changed priority to HIGH высокий проритет задачи они опять заметили что полоски неправильные говорят что не будут играть в такой отстой проект на грани провала
07.03.13 17:27 Andrei Hobotov [programming lead] reassigned to Semen Kemshakov [3d artist] Подвинь полоски, чтобы не закрывали пулеметы.
07.03.13 17:28 Konstantin Krainihin [historical consultant] commented: Я щас кому-то подвигаю! До миллиметра по историческим фотографиям вымеряли...
11.03.13 12:36 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer] Боря, придумай какой-нибудь хак. Ситуация безвыходная.
17.05.13 14:37 Boris Vovk [senior programmer] reassigned to Vladimir Orlov [game designer] Пропишите пулеметам дамаг 231 вместо 2. Из него ровно 229 уйдет на пробитие полосок, дальше полетят пули с остаточным дамагом 2, как и должно быть.
27.05.13 11:22 Vladimir Orlov [game designer] reassigned to Boris Vovk [senior programmer] Прописал пулеметам дамаг 231
29.05.13 15:01 Boris Vovk [senior programmer] closed issue. Теперь все должно быть в порядке.
30.06.13 16:30 Sergei Lodkin [qa lead] reopened issue: После вашего изменения Нью-Мексико вдруг начал нагибать всех, кто к нему приблизится. Нет, не так. Нью-Мексико вдруг начал НАГИБАТЬ КРОВЬ КИШКИ РАСЧЛЕНЕНКА ВСЕХ РАСПИДАРАСИЛО В МЕЛКИЕ КЛОЧКИ. Мы случайно взяли Нью-Мексико и два раза нагнули геймдизайнеров в товарищеском матче. Нам приятно. Спасибо. Но теперь они тоже просекли фишку, поэтому пора исправить.
01.07.13 10:02 Boris Vovk [senior programmer] reassigned to Vladimir Orlov [game designer] Почему Нью-Мексико начал нагибать? Вы кроме пулеметов истребителей ничего не меняли?
01.07.13 17:00 Vladimir Orlov [game designer] reassigned to Boris Vovk [senior programmer] Оказывается, те же самые пулеметы, отскейленные в 10 раз, используются как орудия второстепенного калибра Нью-Мексико. По форме очень похожи, вот моделлеры и решили сэкономить. Дамаг тоже автоматически скейлится, но уже в 1000 раз, пропорционально объему ствола. Так что у нас теперь у Нью-Мексико дамаг 231000 на выстрел второстепенного калибра.
03.07.13 18:01 Elena Ivanova [community manager] changed priority to VERY HIGH просьба ускориться нас опять в интернете ткнули носом в этот позор не те полоски мне стыдно за тот отстой что мы делаем аааааааааа
03.07.13 19:39 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead] Хак не прокатил. Надо всю архитектуру движка менять, чтобы можно было динамически оверрайдить коллизии в текстурах. Иначе ничего не получится. А это работы на полгода.
04.07.13 10:13 Andrei Hobotov [programming lead] reassigned to Slava Makarov [makarovslava] Такие решения должны приниматься на высшем уровне. Ну что, отодвигаем альфу на полгода? Слава, жду решения.
04.07.13 10:22 Andrei Hobotov [programming lead] reassigned to SerB [vice makarovslava] Извините, что беспокою. Это очень важный и срочный баг, его фикса ждут уже больше года. Вы не знаете, где Слава Макаров?
04.07.13 10:28 SerB [vice makarovslava] reassigned to Andrei Hobotov [programming lead] Нет, я не знаю, где Слава Макаров.
04.07.13 10:37 Slava Makarov [makarovslava] commented: Извините, что не сразу ответил. Я тут подумал и решил, что проще забанить того неприятного человека. Белые полоски делать не надо, всем отбой. Пойду думать, как бан обосновать.
04.07.13 18:21 Alexandra Lebedeva [2d artist] reopened issue: Как не надо? (((((((( А зачем же я вчера всю ночь эскиз рисовала? (((((((( Хотела сюрприз сделать ((((((
04.07.13 18:27 Alexander Rozhko [art director] commented: Скинь эскиз на сетевой диск посмотреть. Может, куда-нибудь пристроим.
04.07.13 18:34 Alexander Rozhko [art director] commented: А почему там не две белых полоски, а три оранжевых звездочки?
04.07.13 20:48 Alexandra Lebedeva [2d artist] commented: Я - художник, а не маляр... ((((((( Я творчески переосмыслила... ((((( Я хочу, чтобы у нас была красивая игра... (((((((
Подписка за 80 долларов в год ради приложения, которое отслеживает атмосферное давление. Календарь для семьи и детских обязанностей за 29 долларов плюс. Надоедающая реклама в трекере для продуктов. Микротранзакции в рабочих приложениях...
Привычный набор готового софта всё чаще оказывается дороже, тяжелее и неудобнее, чем хотелось бы, и пользователи начали отвечать на это просто: собирать нужные инструменты самостоятельно, описывая задачу нейросети обычными словами.
Именно об этом развернулась большая ветка в сообществе r/ClaudeAI. Вопрос звучал предельно конкретно – не про эффектные демки и разовые эксперименты, а про то, что люди реально собрали и используют каждый день.
После шести сотен комментариев, сложилась ясная картина того, как вайбкодинг применяется обычными пользователями.
Инструменты для разработчиков и айтишников
Самый заметный пример из ветки – крошечная команда wtf. Это десяток строк в shell, которые перехватывают последнюю упавшую команду вместе с её stderr и отправляют всё в Claude с просьбой объяснить, что сломалось и как чинить.
Создатель отметил, что запустил её больше двух сотен раз с момента установки, и описал эффект так – это инструмент, нужды в котором не осознаёшь, пока он не появится.
Некоторые рассказали, что собрали собственные веб-интерфейсы для Claude Code, потому что терминал и расширение для VS Code их не устраивали.
Другие написали обработчики дежурных алертов, скрипты переключения роутера на резервный 5G-канал и даже агентов, которые присматривают за другими агентами и не дают им лениться.
Один из участников описал систему для дежурного реагирования в финансовой компании, сопоставимой по масштабу с крупным банком. Инструмент с доступом только на чтение к очередям Kafka, продакшен-базе и кодовой базе сам оценивает алерты, расставляет приоритеты и ведёт историю инцидентов вместе с решениями оператора.
Появился и менеджер времени выполнения для MCP-серверов, который запускает их только в момент использования и гасит остальное, экономя оперативную память на мини-ПК с 16 ГБ RAM.
Быт и семейные дела
Это оказалась самая массовая категория. Лидирует здесь список покупок, отсортированный по полкам конкретного магазина в том порядке, в котором человек идёт вдоль рядов.
Создатель пояснил, что раньше мучился с таблицей Google, а главной победой стала вовсе не сборка приложения, а то, что им начала пользоваться жена и сама добавляет позиции через синхронизацию.
Похожих историй много:
Семейные календари с привязкой к Google, детские чарты обязанностей с наградами на подержанном планшете вместо коммерческого гаджета за триста долларов, базы рецептов, которые разбирают ссылки на готовые блюда и собирают из них недельный план с агрегированным списком покупок.
Один участник довёл идею до приложения в духе "Тиндер для ужина", где пара отмечает категории еды и находит согласие по тому, чего обоим хочется сегодня.
Отдельно стоит личная вики, куда человек свёл выгруженные данные из социальных сетей, eBay и Amazon, семейную историю, геоданные из 250 тысяч фотографий и переписку. Получился взаимосвязанный архив собственной жизни, который умеет читать и дополнять Claude. По сути это более честная версия того профиля, что платформы и так держат на пользователя, только под его контролем.
Здоровье и хобби
Тот самый барометр от мигреней открывает категорию узких трекеров. Это просто HTML-файл на телефоне, который показывает текущее давление и динамику за сутки, чтобы сопоставлять перепады с приступами боли.
Платные аналоги в магазинах приложений просяи за то же самое более восьмидесяти долларов в год.
Сюда же относится локальный архиватор данных Garmin. Создатель, инженер-механик, обнаружил неприятную деталь – примерно через полгода платформа без предупреждения понижает разрешение исторических данных, и подробная статистика за день превращается в усреднённые показатели. Скрипт на Python забирает всё локально до того, как это произойдёт, и строит графики вариабельности сердечного ритма и сна без облака и подписки.
Что еще:
Кастомные фитнес- и нутрициологические панели
приложения для изучения мексиканского испанского и китайского
инструменты для кампаний по Dungeons & Dragons
менеджеры филамента для 3D-принтера
трекеры запасов патронов
приложение, которое по фото пачки кофе выдаёт стартовый рецепт под конкретную машину и кофемолку, ведёт лог проливов и подсказывает, что менять дальше
веб-приложение, которое переписывает схемы для вязания с сокращениями обычными словами, плюс пошаговые инструкции
Малый бизнес
Здесь пользователи фактически собирают целые системы планирования под себя.
Кто-то собрал полноценную CRM для строительной компании с учётом времени, счетами, инвентарём инструментов и обслуживанием автопарка, а также система, на которой целиком работает бизнес – запись и расшифровка звонков, отслеживание лидов, SMS-напоминания для сотрудников в полях и клиентский портал. Такими решениями уже пользуются по несколько работников и десяток смежных компаний.
Один участник, занимающийся международными обзвонами без опыта в продажах, собрал расширение для дозвонщика Twilio, которое расшифровывает разговоры, и подключил его к Claude через MCP.
После 40–50 звонков в день он просит ИИ разобрать переговоры и подсказать, что улучшить, и связывает с этим первые две закрытые сделки.
Другой человек автоматизировал монтаж воскресных видео для церкви, выстроив на Python конвейер с разделением аудиоканалов, классификацией речи и пения и автосубтитрами, и теперь укладывается в час вместо прежней нагрузки, из-за которой уволился предшественник.
Самым проработанным выглядит инструмент HR-директора из британского детского сектора. Он собрал систему из восьми агентов:
оценщик задачи
эксперт по трудовому праву с еженедельным самообновлением
исследователь судебной практики
внутренний HR-специалист
агент по благополучию сотрудников
представитель профсоюза
агент по защите детей
финальный писатель отчётов в авторском стиле
На один разбор уходит на пять с лишним часов меньше, плюс система ловит мелкие ошибки.
При всей привлекательности вайбкодинга у подхода есть оборотная сторона. Исследование от мая 2025 года показало, что 170 из 1645 веб-приложений, собранных на платформе Lovable, содержали уязвимости, способные раскрыть персональные данные.
Также есть юридические риски записи звонков без уведомления собеседника, особенно при работе с клиентами из ЕС.
Однако общая тенденция тут прослеживается – полезными оказываются скучные узкие инструменты, которые пользователь запускает регулярно.
Если есть нишевая задача, под которую думаешь "вот бы было приложение", ответ теперь звучит так – собери его сам за вечер.
Чет Фалисек, работавший над сюжетом Half-Life 2: Episode One и Two, а также Left 4 Dead 1 и 2, высказался о возможном участии в разработке Half-Life 3 – и его ответ оказался весьма однозначным.
В ответ на комментарий на YouTube, где утверждалось, что написать Half-Life 3 было бы легко, так как сюжет может развиваться "в любом направлении", Фалишек сделал чёткое заявление. Перед этим он оговорился, что не намекает ни на какие анонсы и говорит о событиях более чем десятилетней давности.
Когда люди спрашивают меня: "О, разве ты не хотел бы?" – нет! Нет.Я почти никогда не хочу касаться чего-то, у чего уже есть какой-то лор или история. Даже Left 4 Dead или что угодно другое. Я не хочу трогать ничего старого. Я не хочу, чтобы люди, которые помнят всё это лучше меня, кричали на меня из-за того, что я изменил какую-то деталь лора, которому к этому моменту уже 50 лет.
В качестве примера Фалисек привёл Bungie. По его словам, когда он обсуждал возможность сотрудничества со студией – не по Marathon, а по другому проекту – огромный массив лора Destiny 2 его буквально испугал.
Все их игры обладают колоссальным количеством лора, и этот лор меня пугает. Я плохо знаю даже историю собственной жизни, куда уж мне разбираться в вашей игре. Я не хочу писать внутри всего этого. Для меня любой сиквел – это кошмар, которого я никогда не хочу делать.
Что касается непосредственно Half-Life 3, Фалисек не стал подбирать мягких формулировок:
Нет. Я не хочу касаться этого даже десятифутовым шестом. Или даже гравипушкой, удерживающей этот десятифутовый шест на расстоянии от меня. Гравипушкой к десятифутовому шесту – я бы не стал.Я бы не стал даже с руками Дога.
Слова Фалисека звучат особенно интересно на фоне того, что происходило с франшизой в последние годы. Half-Life: Alyx вышла в 2020 году и оставила сюжет в точке, буквально кричащей о продолжении: финал игры кардинально изменил расстановку сил в нарративе серии. Это заставляет задуматься, как Valve сама относится к накопившемуся грузу лора и ожиданий аудитории.
Слухи о Half-Life 3 периодически вспыхивают с новой силой – в том числе разговоры о возможном релизе в связке со Steam Machine. Фалисек, впрочем, дал понять, что его мнение здесь не изменится ни при каком раскладе.
Разработчик Доминик Джон в интервью порталу 80.lv поделился деталями работы над Project Shadowglass – игрой, которая использует уникальную технику рендеринга, сочетающую полностью трёхмерное окружение со стабильным низкоразрешённым пиксель-артом.
Когда первые ролики игры появились в сети, многие зрители решили, что графика создана с помощью ИИ, заранее отрендерена или вовсе не работает в реальном времени.
Джон описывает визуальный стиль как нечто близкое к "прогулке внутри двумерного пиксель-арта". Сам разработчик предлагает называть подход "Pixerly" – по аналогии с термином "Painterly", который описывает игры, выглядящие как живопись. Идея в том, чтобы взять ретро-игру и оказаться внутри экрана, где в любом направлении взгляд встречает 2D-пиксельную графику.
Основным источником вдохновения стала эпоха до появления графических ускорителей. Разработчик выделил System Shock, Ultima Underworld и The Elder Scrolls II: Daggerfall, а также атмосферу заставок ролевых игр конца 80-х и середины 90-х.
По словам Джона, прототипы псевдо-3D в его портфолио тянутся ещё с 2010-х годов, когда он перебирал разные методы для достижения нужного эффекта.
С технической стороны подход ближе к классическому 3D, чем многие предполагают. Воксели не используются, а ручная отрисовка двумерных пикселей опциональна. Основную работу выполняет набор кастомных шейдеров и рендеринг-кода – ни одна отдельная техника не даёт полного эффекта, а нужный вид складывается из совместной работы множества методов. Среди очевидных приёмов – точечная фильтрация и таблицы LUT, но это лишь поверхностный слой более глубокой системы стабилизации пикселей.
Ключевым выбором стал движок Godot. Полная открытость исходного кода без лицензионных платежей позволила Джону менять рендерер так, как требовалось, не создавая собственный движок с нуля. Из дополнительных инструментов разработчик упомянул только Blender, Affinity и Aseprite – ничего экзотического для проекта не потребовалось.
Баланс между ретро-ограничениями и современными ожиданиями остаётся ежедневной задачей. Джон отметил, что постоянно экспериментирует с внешним видом солнца, размышляя, насколько уместны свечение и лучи света в общей эстетике.
Подход состоит в том, чтобы выявить, какие прошлые ограничения работали как художественные преимущества, и затем подбирать к ним современные доработки.
Производственный процесс при таком подходе ускоряется в одних аспектах и замедляется в других. Мелких деталей меньше, однако в низком разрешении приходится постоянно проверять читаемость объектов под любым углом. Персонажи и предметы порой требуют разных версий для близкого и дальнего планов, иначе вблизи они превращаются в пиксельный шум.
Освещение разработчик называет главным вызовом, так как чувство глубины в низкоразрешённой 2D-графике даётся нелегко.
Project Shadowglass задумана как стелс-ориентированный иммерсив-сим, поэтому динамические тени должны не только выглядеть правильно, но и корректно работать в геймплее. Опыт Джона как 2D-пиксель-художника помогает сразу замечать, где композиция теряет глубину или ключевые детали.
На вопрос о популярности стиля разработчик ответил, что играм с такой эстетикой удаётся попасть в зону "знакомого, но нового". В комментариях он часто видит фразу о том, что именно так игры представлялись зрителям в детстве.
По мнению Джона, на фоне гиперреалистичной графики и ИИ-генерации в 4К возникла потребность в стилях, которые работают вместе с воображением игрока, а не заменяют его.
В перспективе разработчик надеется, что подобный подход распространится среди инди-разработчиков и со временем покажет, способен ли он вытянуть полноценную игру.
Особый интерес для него представляют возможные ремастеры в стиле "Pixerly" – в качестве кандидатов Джон назвал Ultima VII и Final Fantasy VI, а также классические квесты от LucasArts и Sierra.
Геймдизайнер Томас Грове из японской студии Studio Interrupt провёл наглядное сравнение двух популярных движков, собрав идентичную игру в обоих.
Результаты оказались показательными – Godot обошёл Unity практически по всем показателям.
На протяжении более чем десяти лет Unity оставался одним из главных движков для инди-разработки, на нём были созданы такие хиты как Hollow Knight, Among Us и оригинальная Subnautica. Однако в последние годы всё больше разработчиков переходят на Godot – движок с открытым исходным кодом, схожий с Unity по возможностям и функциональности.
Причины перехода зачастую были связаны с этическими и финансовыми вопросами, в частности со скандалами вокруг Unity и попытками ввести плату за каждую установку игры. Но Грове решил отбросить эти факторы и сравнить движки исключительно как инструменты разработки.
Грове создавал хоррор-сурвайвал вместе со своим сыном и решил использовать этот тайтл для тестирования обоих движков.
Я давно хотел увидеть честное сравнение двух движков бок о бок, а не одну и ту же игру, сделанную разными разработчиками. Я подумал, что это мой шанс наконец сделать это и решить, хочу ли я двигаться дальше с Godot или продолжать использовать Unity.
Игра находилась на ранней стадии разработки, но уже включала полноценный контроллер персонажа, систему переходов камеры, систему смены сцен, трипланарный дизер-шейдер и систему интерактивных объектов. Все эти функции были реализованы в обоих движках, после чего Грове сравнил их производительность.
С точки зрения функциональности движки показали себя примерно одинаково – каждый справлялся с отдельными задачами чуть лучше или чуть хуже конкурента. Однако по эффективности рабочего процесса Godot оказался значительно впереди.
Godot загружает проект более чем в 5 раз быстрее Unity, экспортирует в 20 раз быстрее и компилирует скрипты в 31 раз быстрее. Последний показатель особенно важен, ведь при разработке игры компиляция скриптов выполняется сотни раз. Кроме того, Godot занимает всего 164 мегабайта дискового пространства против 20 гигабайт у Unity.
Если посмотреть на все данные, Godot обошёл Unity по каждому показателю, кроме финального FPS на выходе.
При этом оба варианта игры работали с частотой кадров значительно выше минимальных 60 FPS, так что разница в этом параметре не имела практического значения. В итоге разработчик решил продолжить работу над игрой именно в Godot.
Впрочем, некоторые зрители справедливо указали на ограничения эксперимента. Пользователь WitchfellGame написал:
Сцена была слишком простой, чтобы нагрузить какие-либо системы, о чём свидетельствует очень высокая частота кадров.
Другой комментатор добавил:
Если вы не используете полноценный завершённый игровой проект, вы не узнаете, какой движок подойдёт вашему проекту при масштабировании.
Создать две полноценные игры с нуля исключительно ради тестирования движков – задача малореалистичная. Однако последовательность и масштаб разницы в результатах Грове всё же указывают на то, что Godot в целом работает эффективнее Unity, по крайней мере на начальных этапах разработки.
