Большая часть моей профессиональной карьеры связана с Java и бэкенд‑разработкой: сервисами, базами данных, интеграциями, многопоточностью и проектированием систем. Но в какой‑то момент мне снова захотелось делать продукт, результат работы которого можно увидеть не только в логах и ответах API, но и непосредственно на экране.

Так я вернулся в геймдев и начал разрабатывать собственные игровые проекты. Мне был нужен инструмент для 2D‑игры с версиями для Android и браузера, который позволил бы сохранить общий код, не прятал бы происходящее за визуальным редактором и не заставлял бы отказываться от привычной Java‑экосистемы.

В итоге я выбрал libGDX.

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

В этой статье расскажу, что именно мне дал libGDX, какую часть кода действительно удалось сделать общей и где кроссплатформенность закончилась.

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

Логика выглядит убедительно ровно до того момента, пока не посмотришь, что именно считает принимающая сторона. Антифрод почти никогда не спрашивает «встречался ли нам раньше такой набор параметров». Он спрашивает другое: «бывают ли вообще такие устройства». Это два разных вопроса, и ответы на них расходятся в противоположные стороны.

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

Я честно пошёл изучать шейдеры, чтобы сделать игру красивее. Получилось. А потом посмотрел на два скриншота рядом и понял: большую часть разницы дали не шейдеры.

Её дали пять довольно тупых правок от двух до тридцати строк каждая. Самая полезная - две строки в конфиге камеры.

Внутри: таблица «цена / что чинит», формулы контактной тени, детерминированный хэш против одинаковых плиток, запечённый AO на стыках. И честный список того, что стоило дорого, а дало меньше.

Встроенный граф Obsidian хорош ровно до момента, когда vault разрастается и превращается в клубок линий. Я решил сделать из базы знаний место, которое можно запомнить, — и собрал open-source плагин CosmoGraph 3D на Three.js и WebGL. В статье разбираю весь путь от metadataCache и wikilinks до сферической раскладки по золотому углу, процедурного рельефа, кратеров, bloom и нативного ItemView внутри Obsidian. Без облачной обработки заметок и без рассказов о «магии»: только код, архитектурные компромиссы и честный список того, что ещё предстоит ускорить.