Мы подняли важную для нас в Defold тему размера билда, и я рад, что её так подхватили: Construct (хоть это и не нативно-кроссплатформенный движок), Aras (который раньше работал в Unity), и вот теперь Mewton тоже запостил у себя.

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

К примеру, в посте Араса про оптимизацию Unity web-билда до 2 MB я привел пример, как несколькими галочками можно оптимизировать Defold до 817 KB. И это не считая того, что если собирать движок самостоятельно, то можно добиться и 400-500 KB.

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

Почитайте пост от Араса про оптимизацию web-билда в Unity и поделитесь с разработчиками на Unity - надеюсь это чуточку поможет им с размером web билдов.

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

С первого октября Poki стали платить 100% доходов с органического трафика или того, что вы сами привели. Система действует уже 2+ месяца, и пока полёт нормальный. Доход в среднем вырос на 10%.

Лично я считаю это изменение позитивным. Какие у вас мысли на этот счёт?

В этом году, после многолетнего перерыва, планирую посетить игровые конференции за пределами Швеции.

* DevGAMM Gdańsk – буду в Гданьске с 26 по 28 февраля.
* GDC 2025 – буду в Сан-Франциско с 16 по 23 марта (найти меня можно на стенде Poki, если что).

Если у вас есть вопросы по Defold или просто хотите пересечься и пообщаться – пишите, буду рад!

Что не так с Dropbox и чем я его заменил.

Концептуально Dropbox мне очень нравится. Работаешь себе в папке с файлами — а они всегда автоматически бэкапятся. Ну круто же!

Понятно, что для кода есть Git (и сервисы на выбор — от собственного хостинга до GitHub и прочих), для фото — iCloud или Google Drive в зависимости от телефона (я плачу за оба), для документов — Google Docs. И тут встаёт вопрос: а зачем тогда нужен Dropbox?

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

И такие файлы хочется (и нужно) шарить с командой, а их всегда больше, чем позволяет бесплатный лимит.
Купить аккаунт, конечно, не проблема, но вот тут начинается самое интересное: все папки, расшаренные с тобой, считаются в твой аккаунт. То есть платный аккаунт должен купить каждый, с кем ты работаешь. И каждый платит за это место.
Есть, конечно, тариф, где у команды есть одна общая папка, и она не считается в лимит каждого, но если вас 5 человек да ещё и с НДС, то это уже 90 евро в месяц. Может, это и немного, но "осадочек остался".

Я начал искать, чем можно заменить Dropbox — без потери в удобстве и без ощущения, что тебя затягивают в какую-то клиентскую пирамидальную схему. И нашёл STORAGE SHARE от Hetzner. Это решение на базе Nextcloud — по сути, open source Dropbox с приложениями под все ОС и теми же принципами работы.
Только у тебя своя админка, где ты сам добавляешь нужное количество пользователей, и за место на диске платишь один раз. И те же 5 TB обходятся в 18 евро в месяц для всей команды (с НДС).

Скоро будет год, как я полностью переехал с Dropbox на Nextcloud (Storage Share от Hetzner), и полёт нормальный.

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

Есть смысл написать про конференции, на которые я ездил.

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

GDC.
На GDC я ездил по приглашению Poki и большую часть времени провёл с ними. Крутая команда. Много классных специалистов, с которыми приятно и про работу поговорить и потусить. Основатели и менеджмент тоже отличные — с ними приятно общаться, и они действительно тебя слушают.
Удивлён, что ребята каким-то образом сохранили такую атмосферу, несмотря на рост компании. Это дорогого стоит. Обычно вся магия такого рода развеивается, если в компании становится больше 15 человек.
Сама конференция как будто стала меньше (в прошлый раз я был в 2017-м): не было стендов больших компаний, зато было много аутсорса из разных точек мира.
Имеет смысл ехать только если у вас есть чёткий план и вы собираетесь его придерживаться. Ну или если вы живёте очень близко.

Планы на май.
В мае планирую побыть на Кипре (в основном в Лимассоле 4-18, но буду на острове до 24, просто на остальные даты сложнее сказать локацию). Если вы там и хотите увидеться (покормить котиков на набережной или выпить пива), пишите в комментариях или в личку — попробуем запланировать встречу.

Уже достаточно продолжительное время у меня крутится в голове мысль, что мы в геймдеве используем какие-то форматы данных, которые изначально создавались вовсе не для разработки игр. Всякие JSON, YAML или, тьфу-тьфу, XML и тому подобное.

Множество фич — как для разработки игр, так и для самих фич внутри игр — могли бы быть более доступными и простыми в реализации, если бы о них думали ещё на этапе дизайна формата данных. Как, например, в Tomorrow Corporation Tech Demo.

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

https://telegra.ph/Materialy-po-teme-formatov-dannyh-v-razrabotke-igr-06-07

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

Если для того чтобы разобраться с кодом, я обращался к LLM, то чтобы понять подходы к работе с инструментами и сам workflow я докучал опытным коллегам: Матсу и Владу.

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

https://forum.defold.com/t/defold-editor-development-tips-and-tricks/80710?u=agulev

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

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

Поэтому, независимо от уровня скептицизма, я ставлю себе задачу пробовать разные инструменты и смотреть, что из этого получается.
ChatGPT у меня давно в списке постоянно используемых инструментов. Теперь решил попробовать Cursor (для простоты — cursor-like), и вот что я думаю.

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

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

2. Если ChatGPT в приложении в основном годится для код-сниппетов и написания скриптов, то cursor-like открывает целый новый класс использования LLM — написание одноразовых инструментов. Раньше я часто отказывался от написания инструментов с сомнительной переиспользуемостью, когда ручное выполнение задачи быстрее. Сейчас вполне реально сэкономить время, написав инструмент под одну задачу. А из-за одноразовости качество кода меня не волнует.

3. Написание по шаблону (не кодогенерация) — это когда у вас есть PR, где вы протянули API A, а нужно сделать очень похожее структурно B и C. С такими задачами cursor-like справляется отлично, так как уже написанный вами код служит ему отличным примером, и он без проблем повторяет подобное.

4. Черновики или прототипы — часто, чтобы понять, как лучше реализовать что-то, нужно начать реализацию. В процессе появляются проблемы и более глубокое понимание связей, а задача становится понятнее. С cursor-like можно буквально по текстовому описанию увидеть, какой способ реализации фичи или багфикса подходит лучше, быстро набросать черновики разных вариантов, понять, что и как они затрагивают, и безболезненно их откатить. А потом уже спокойно реализовать лучший вариант руками. Тут главное, что не возникает искажения невозвратных издержек, когда выбирается не тот вариант, что лучше всех для проекта, а тот, в который «уже вложено так много сил».

Минусы:
- Утомляет переключение моделей: auto хорош для большинства задач, но если не справляется — приходится всё переделывать на чём-то ещё (чаще всего claude-4-sonnet).
- С ростом контекста начинаются серьёзные проблемы: больше времени тратится на обход, чем на сам проект. Я много экспериментировал и удалил десятки тысяч строк, сгенерированных для тестов. Тут кроется главная опасность пункта 0, что я описал выше — LLM должен быть инструментом для работы с проектом, а не отвлекать от него.
- Нужен контроль: я отошёл на пару минут во время задачи по исправлению бага в блоге на GitHub Pages, и вместо питон-скрипта он начал руками считывать все статьи, спалив месячный лимит токенов (хотя до этого все задачи он выполнял с помощью python скриптов).
- Так как я не использую VS Code и мне не нужен автокомплит от LLM, решил посмотреть в сторону Claude Code — это мой эксперимент на этот месяц. Первая неделя — полёт отличный, но об этом в следующий раз.

Кстати, сейчас там ChatGPT 5 доступен бесплатно на неделю. Если вы ещё не пробовали Cursor — это хороший повод посмотреть на него, не тратя свои кровно заработанные.

Ах да, буду на gamescom в этом году. Если хотите встретиться - пишите.

По-моему, определился с мероприятиями для посещения до конца года. Список небольшой:

* На следующей неделе еду на Devcom и Gamescom в Кёльн.

* 6–7 ноября — на DevGaMM в Лиссабоне (ближе к дате ещё напомню).

Если планируете быть в Кёльне и хотите поговорить про Defold, веб или мобильные игры, да и просто встретиться — пишите, организуемся.

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

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

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

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

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

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

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

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

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

Вот что сам Codex написал по поводу того, что он сделал:

Я переключил освещение модели с точечного на направленный свет, чтобы затенение оставалось стабильным при движении камеры. Я добавил мягкий wrap‑терм, разделил вклад ambient/diffuse и ввёл лёгкий specular, чтобы тени были мягче, а поверхность имела аккуратный блеск. Также я ввёл холодный оттенок для ambient и небольшое ослабление для верхних граней, чтобы хайлайты не выбивались, но по яркости соответствовали референсу.

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

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

Сразу от нескольких знакомых слышал опасения: «что будем делать, когда AI нас заменит».

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

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

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

При этом шикарные результаты от AI получать можно. И лучше он будет, если у тебя есть опыт техписательства, работы с заказчиком или работы с джунами и т.п.
То есть любой опыт, направленный на работу с людьми и наведение мостов между двумя сторонами до непосредственной реализации.

С текущим уровнем моделей (в моём случае Codex) я не вижу проблем, что модель как-то не так пишет код. Отлично пишет. Но все проблемы обычно сводятся к постановке задачи из-за «я знаю контекст и понимаю, что хочу, но выразить не могу и хочу, чтобы мои мысли читали».

Именно поэтому я считаю, что принцип универсален и для людей (построение мостов между человеком и другим человеком), и для нейронок (человек ↔ бот):

"If you're thinking without writing, you only think you're thinking."

https://www.paulgraham.com/writes.html

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

Отсюда и все эти однопромптовые запросы, которые по сути сводятся к «додумай за меня», с последующим «ну ты тупой», потому что додумал не так, как хотелось. А как хотелось - ты и сам до конца не решил.

Но AI сделала ровно то, что ты просил, и сделала ровно то, что делает твой мозг: перцептивно заполнила недостающие части наиболее статистически значимыми (с небольшой рандомизацией) значениями из датасета, создав таким образом иллюзию законченности.

Поэтому вывод простой: проси нормально - нормально будет.