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

https://telegra.ph/Kak-ya-ispolzuyu-ChatGPT-kazhdyj-den-10-20

Мы подняли важную для нас в 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, веб или мобильные игры, да и просто встретиться — пишите, организуемся.