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

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