GameDevLogs

Друг поделился забавной гифкой. Я с физическими движками не очень дружу, но быстренько собрал похожую демку на Defold. HTML5 демка (если браузер не даст фокус канвасу - может тормозить, нужно кликнуть/тапнуть по черному экрану сразу после загрузки) Код

В чате Defold обещал поделиться есть ли смысл тратить время на поддержку портретного режима в игре разработанной для альбомного режима на Poki. Для тех кто не в курсе стоит отметить, что на Poki на мобильных устройствах банеры показывюатся только в портретном режиме, поэтому добавление такой поддержки имеет вполне измеримые финансовые результаты. Вводные такие: - Казуальная игра, где-то 40-50% аудитории используют мобильные устройства (телефоны и планшеты); - Время в игре на игрока ~ 14 min; - Игра сделана давно и много где не использовались gui компоненты и т.д. поэтому добавление нормальной поддержки портретного режима и тестирование заняло примерно 13 часов. Результат за 5 дней с выхода версии где добавлен портреный режим: - Вовлеченность +4.5%; - Доходы +9.5%; - Количество показываемых банеров выросло в 3 раза (до этого портретный режим не блокировался, люди могли играть в нем, но всё было мелким и неудобным). Стоит оно того или нет, решайте для себя сами. В новых играх мы делаем поддержку портретного режима изначально и это почти ничего нам не стоит. Старые игры, где добавлиние такой поддержки можно сделать быстро и просто - я, скорее всего, буду дорабатывать. Но те игры на которые нужно больше 10 часов рабочего времени - оставлю как есть.

У меня просто крутиться в голове одна мысль, от которой я не могу отделаться. Она про LLM модели. ChatGPT - это довольно общая модель и довольно требовательная к железу. Конечно технология и хайп вокруг нее летят к пику и сейчас на это пофиг. Но пофиг перестанет быть довольно скоро и следующим шагом будет “как скейлить” или “как удешевить”. Кроме того со скейлом сети, появляется больше проблем с модерацией и ограничениями, чтобы не давать пользователям делать фигню, на это тоже нужны ресурсы. Мне кажется, что одним из оптимальных решений дать моделям специализацию. OpenAI идет по пути плагинов через доп промпты, это то, что они продают: ты им платишь за количество токенов в промпте т.е. будет логично давать тебе возможность расширять функционал добавляя возможность быстро и просто добавлять в промпты большие объемы данных (в качестве контекста запроса). И тогда ты получаешь специфический функционал за счет больших вложений средств. Я же думаю о специализации за счет добучения, подход при котором общая модель это бекенд, дающий базовые правила взаимодействия и т д А верхний слой это то, чему ты сеть дообучил для своих задач собственно, как и с SD, когда ты дообучаешь модель на своих артах. Это поможет решить и проблемы “цензуры” т.к. если сеть специализирована, то определить “не релевантный” запрос куда проще. А так же поможет и с требованиями к железу, ведь сеть уже будет в контексте интересующей тебя темы т.к. до обучена на нужных именно для этой конкретной задачи материалах. Пока я вижу эксперименты с этим с llama, как, например, вот этот репозиторий: https://github.com/bublint/ue5-llama-lora Что думаете? Долетим на волне текущего хайпа прямиком к сильному AI или всё-таки пойдем на очередную итерацию, с оптимизацией и более вдумчивой утилизацией того, что уже есть?

Пообещал, что следующий пост будет технический и пропал. Молодец, слов нет. Давайте немного расскажу про байтики. Бородатым программистам это будет неинтересно. Сколько бит нужно, чтобы сохранить информацию о трансформации тайла в тайловой карте? Если вы любите прочитать истории как изгалялись разработчики игр на Famicom, чтобы сделать "красиво", то вы знаете что нам нужен как минимум: - 1 бит для того, чтобы знать есть ли отражение по вертикале; - 1 бит для того, чтобы знать отражен ли тайл по горизонтали; - чего на Famicom не было, так это поворота тайла и нам достаточно 1 бита, чтобы знать повернут тайл на 90 градусов или нет. А как же 180°, 270° и вот это вот всё. На самом деле если подумать и условиться, что сначала применяется отражение, а затем поворот, то этих данных достаточно для всех возможных вариаций. Высчитать это просто: всего у нас 4 возможных поворота в каждом из которых тайл может быть отражен т.е. 2 * 4 = 8. Мы знаем что один бит это 1 или 0 (т.е. хранит 2 состояния). Каждый следующий бит увеличивает квадратично количество информации, которое мы можем хранить (да-да, квадратично, нельзя просто разделить 8 на 2). Собственно 2*2*2 = 8 наших состояний. Ой, да вы и сами в двоичной системе разбираетесь, что я в самом деле. Можно, конечно, применить и другую схему: 90°, 180°, горизонтальное отражение. Но тогда нам придется поменять порядок применения трансформации. Сначала применять поворот, а затем flip. Итого, вся информация от трансформации помещается в 3 байта, что в Defold например, uint8_t (аж целых 5 байт остается про запас). К чему я это всё. Человеку в своей голове проще, когда действий меньше. Представить конечный результат того, что ты тайл поворачиваешь, а затем отражаешь куда проще, чем применить два отражения и затем поворот по необходимости. Второй нюанс состоит в том, что в Lua битовых операторов нет, а битовые операции делаются через bit модуль: bit.band(0x12345678, 0xff). Это не супер удобно. Да и в целом битовые операции не всем и всегда интуитивно понятны. Как же это сделать дружелюбно и для того, как это себе представляет пользователь (поворот + отражение) и для записи в коде? При этом конечный результат должен быть битовой маской использующей 2 отражения и поворот 90°. Давайте для себя запишем таблицу соответствия всех наших состояний используя повороты и оба отражения:

R_0 = R_180 + H + V (0 в двоичной системе 000)
H = R_180 + V (1 в двоичной системе 001)
V =  R_180 + H (2 в двоичной системе 010)
V + H = R_180 (3 в двоичной системе 011)
R_90 = R_270 + H + V (4 в двоичной системе 100)
H + R_90 = R_270 + V (5 в двоичной системе 101)
V + R_90 = R_270 + H  (6 в двоичной системе 110)
V + H + R_90 = R_270  (7 в двоичной системе 111)

Мы знаем что H = 1(001), V = 2 (010), R_90 = 4 (100)

0 = R_180 + 3
1 = R_180 + 2
2 = R_180 + 1
3 = R_180
4 = R_270 + 3
5 = R_270 + 2
6 = R_270 + 1
7 = R_270

Это никак не система уравнений, но можно заметить, что значение отражено т.е. в уравнении не хватает модуля. А это значит использование отрицательных значений констант для R_180 и R_270, -3 и -7 соответственно. Что это дает? Из скрипта пользователь записывает трансформацию тайла как сумму поворота и отражений без необходимости использовать битовые маски, например:

H_FLIP + ROTATE_90
V_FLIP  + ROTATE_270
ROTATE_180

А на стороне движка мы получаем маску используя только одну операцию модуль. Так, а зачем маска? Используя маску очень легко заполнять вертекс буфер просто итерируя по-небольшому массиву с шагом bitmask * 6, посмотреть на это можно тут. На следующий пост ничего обещать не буду, так выше шансы, что что-то расскажу.