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

• Видеореклама и просмотр видео за награду.

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

• Нативная реклама.

Интеграция рекламы в интерфейс приложения. Например, спонсируемые товары в приложениях для шопинга.

• Медийная реклама через локальные сети.

Используйте азиатские рекламные платформы TikTok Ads, Baidu, Naver в Корее, LINE Ads в Японии.

• Микроплатежи и внутриигровые покупки.

Игры «крутилки» за внутриигровую валюту. Особенно популярны в Японии и Китае.

• Виртуальные товары и премиальный контент.

Продажа скинов, стикеров, VIP-статусов. Например, приложение Line в Японии зарабатывает миллионы на стикерах.

• Подписки на контент.

Аниме, манга, дорамы — ключевые ниши в Южной Корее и Японии.

• Freemium модель.

Бесплатный базовый функционал, но платные премиум функции. Например, приложения для изучения языков Duolingo и HelloChinese. Фитнес приложения с персонализированными планами тренировок.

• Партнёрские программы и кросспромоушн.

Кэшбэк-сервисы и партнёрство с локальными маркетплейсами Shopee, Lazada и Taobao.

• Лицензирование приложения под брендами местных компаний.

Особенно актуально для B2B-сегмента.

• Поддержка локальных платёжных систем.

Без интеграции местных методов оплаты конверсия будет низкой. Для Китая это Alipay и WeChat Pay. Для Японии PayPay и LINE Pay. Для Южной Кореи это KakaoPay и Naver Pay. В Индии популярны Paytm и PhonePe.

• Социальная коммерция.

Встраивание функций для покупок внутри приложения через социальные сети, стриминговые платформы и шопинг. Особенно популярно в Китае через Taobao Live.

• Реферальные программы.

Пользователи получают бонусы за привлечение друзей.

• Использование супер-приложений.

Интеграция в экосистемы типа WeChat для Китая или Grab для Юго-Восточной Азии в целом. Мини-приложения внутри платформ с доступом к их аудитории. Монетизация через комиссии или подписки.

• Геймификация для удержания аудитории.

Ежедневные награды и челленджи. Пользователи возвращаются за бонусами.

• Квесты с платным участием.

Например, платные турниры в мобильных играх.

• Монетизация данных.

Анонимизированная аналитика для крупных компаний. Собираются данные о поведении пользователей при соблюдении GDPR и локальных законов, например, PDPA в Сингапуре.

В заключении, стоит отметить, что в Китае очень строгие правила к сбору данных. Сегодня важно делать упор на то, что пользователи со смартфонов на первом месте, особенно в Азии, где 95% интернет пользователей заходят через мобильные телефоны.

Друзья, если работаете на азиатских рынках, поделитесь своим опытом!

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

Правильный выбор тегов не гарантирует стопроцентного успеха, но точно определяет, какую аудиторию вы привлечёте и какую конверсию получите.

1. Начните с конкурентов

Перед тем как приступить к наполнению страницы, поищите в стиме игры, которые вы считаете прямыми аналогами или ориентирами по жанру, стилю или атмосфере.

Внимательно проанализируйте их страницы: какие теги указаны у них? Какие стоят на первых пяти позициях? Это не для копирования, а для понимания, как уже представлен ваш сегмент.

2. Проанализируйте полный список тегов

Чтобы выбрать подходящие теги, важно знать, какие в принципе существуют. В стиме для этого есть специальная страница с популярными тегами. Её можно использовать для анализа.

3. Система из четырёх слоёв: как структурировать теги

Не выбирайте теги хаотично. Разбейте задачу на четыре логических уровня, описывая игру от общего к частному. Так вы создадите для алгоритма и игрока полную и понятную картину.

Пример:

Уровень 1: Ядро — жанр и поджанр
Это фундамент. Определитесь с терминами: «Шутер», «Тактический шутер», «Стратегия» или «Глобальная стратегия в реальном времени». Чем точнее поджанр, тем лучше.

Уровень 2: Визуальный стиль и перспектива
Как игра выглядит в глазах игрока. Это измерение (2D, 3D, 2.5D), ракурс (вид сверху, от первого лица, изометрия) и стиль графики (пиксель-арт, аниме или реализм).

Уровень 3: Сеттинг и атмосфера
Выбираем нужную тематику, к примеру: «Киберпанк», «Средневековье», «Постапокалипсис». И атмосферу: «Мрачная», «Смешная», «Расслабляющая».

Уровень 4: Ключевые механики и особенности
Простыми словами, это то, чем игрок будет занят: «Крафтинг», «Защита башни», «Исследование», «Паркур», «Управление ресурсами».

4. Кол-во тегов и их порядок

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

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

Убедитесь, что на первых позициях — самые конкретные и уникальные теги, которые описывают геймплейное ядро и ключевую фишку игры. Старайтесь убирать абстрактные теги (такие как «Инди» или «Для одного игрока») в самый конец.

5. Работа с сообществом и контроль тегов

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

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

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

Заключение

Помните, что теги — это мост между игрой и её ЦА. Чем прочнее этот мост, тем больше вероятности, что нужный игрок дойдёт до точки назначения и захочет купить или добавить проект в вишлист.

Введение

В этот раз я ввязался в кооперацию, а не в одиночку стал делать игру, как обычно бывает у меня. Уже принимал участие в командной разработке на конкурсы, например, «Антивирус» (или «Cybxus Heart») на Гаминатор 19, «Изгоняющий» на Гаминатор 25, и «Из Тени» на ЗОК 2024.

В прошлых совместных разработках моя роль была исключительно графическая — рисовал графику, делал 3д модели. Короче говоря, художник, но с обсуждением каких-то геймплейных идей. Хотя, я немного программировал в случае с «Антивирус», когда он стал «Cybxus Heart» после конкурса. А когда делаю игру в соло, то я отвечаю за все аспекты: программирование, геймдизайн, графика, музыка и т. д.

И вот новый конкурс на сайте Gamin.me — Гаминатор 28. На нём я взял себе другую роль — на мне была вся техническая часть. Короче говоря в этом проекте я был программистом. Повествование в этой статье, разумеется, только с моей стороны и мои восприятия. Не могу знать что думали, как делали и ощущали другие члены команды.

Об Изгоняющем я писал статью по графике на ВК, на ДТФ.

Концепция

Всё началось ещё до старта конкурса Гаминатор 28. Задолго. Всё началось в 1799 году … ладно-ладно, не настолько давно. Всё началось после проведенного мной недо-конкурса Графических Ассетов на сайте Gamin, где был ровно один участник – Kot211. Конечно, я был расстроен таким положением дел, но благодарен Коту, что он поучаствовал. Как я понял, то ему понравилось, что его рисунки оживают в игре, пусть и столь примитивной. А я именно этого и добивался: дать художникам (начинающим или мастерам) возможность “оживить” свои художества.

Спустя какое-то время после окончания конкурса Ассетов Кот написал, что мой конкурс вдохновил его и он полон решимости сделать целую игру-платформер! И мы начали это долго обсуждать. Пока мы перекидывались идеями, появилась новость о скором проведении  конкурса Гаминатор 28 пользователем Anim86. Мы решили делать игру на этот конкурс и стали обсуждать это меньше т.к. нужно было дождаться объявления темы. Однако, мы уже тогда определились, что я буду программистом, а Кот рисовать графику и уровни.

Тема появилась. Она мне не понравилась. Примерно со старта конкурса написал мне и Scorched. Он сразу обозначил, что ему интересно делать звуки и поинтересовался задумал ли я чего делать на этот конкурс — я ответил, что уже ввязался в кооперацию и решил спросить Кота по поводу ещё одного участника. И почти сразу же Кот создал чат в телеграмме для обсуждения разработки нашей игры.

Вот так у нас образовалась команда из
Kot211 — графика, уровни, сюжет, ведение проекта, и, как мне кажется, вся идея;
DarkDes (т.е. я) — программирование, техническая часть;
Scorched — звуки, некоторая музыка и подбор музыки;

Думал, что мы будем пользоваться чатом редко, но там оказался плотный и скоростной трафик сообщений! Пару раз писал команде в полу-шутку, что “да вот же, я уже сделал игру на эту тему – Красный Робот с Гаминатора 22! И он тоже платформер!”. Этот проект с Гаминатора 22 в итоге стал практически основой для текущего.

Мы начали придумывать игру. Мне показалось, что больше влияния было от Кота, чем от меня или Скорчеда. Т. е. геймплей и сюжет придумал он, мы лишь обсуждали эти аспекты, не сильно внося какие-то новые. Были там моменты от концепции, что я с Котом обсуждал до конкурса. Например, что главный герой является роботом, есть руины и игра в жанре платформер. Вот что пишет по этому поводу Кот:

Да, собственно, вся наша доконкурсная концепция сводится к трём словам: платформер, роботы, руины. Изначально у нас с тобой возникла идея сделать что-то вместе незадолго до Гаминатора, но никак с ним не связанная. Накидывали идей, чтобы понять, что нам обоим было бы интересно. Пришли вот к этим трём словам, и от них попробовали построить общую идею. Среди вариантов этой идеи был и вариант с горой, пространством внутри (не пещерой, а скорее имитацией поверхности), значительно более масштабным (но всё ещё камерным) сюжетом и более обширным миром, чем в конкурсной игре. Все эти идеи остались не проработанными, т.к. начался Гаминатор и мы решили что-то сделать на него. В итоге на конкурсную игру у нас остались те самые общие три слова: платформер, роботы и руины. А лично я в своих сюжетных придумках оставил гору, вдохновляясь Кейв Стори и той нашей большой идеей, и главного героя робота как наследника нашего с тобой незавершённого обсуждения, кем может быть герой в той большой истории.

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

© Kot211

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

Наверно, не в деталях, а размыто суть игры была сформирована сразу: Платформер, история, персонажи, сюжетные моменты. Поэтому потребовалась таблица с описанием конкретики и Кот сделал настоящую Монстр-Таблицу, да ещё и из нескольких листов! Он написал как видит игру, какие ресурсы там были бы, звуки, музыка, графика. Казалось, что учтено всё. Забегая вперёд спойлер: не всё.

В каком-то смысле эта таблица похоже на Beat-Chart, где описывается уровень и механики на нём. Скажу сразу, что ориентироваться в ней было сложно.

Мы продолжали обсуждать концепцию в чате, от чего Скорчед даже начал переживать, что мы не успеем с такими объемами. Я с ним соглашался —  ничего не успеем. Поэтому я предложил сделать игру за 2 недели, а не месяц, который отводился на этот конкурс. Это позволило бы сосредоточится на самом важном и потом полировать игру. Забегая вперёд: конечно же, мы не взяли лимит в 2 недели и да, мы не успели к оригинальному дедлайну, как и было предсказано.

Разработка

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

Я сделал немного платформеров или игр схожего жанра. Могу вспомнить такие игры как «Непонятна тьма» для КОД 16,  «Рунтрис» или «Супер Матвей Галаксеевич» для КОД 17.2  (18),  «Криста фон Граф» на MP3 Jam и конечно «Красный Робот» (он же «Игра без названия, но про робота») с Гаминатора 22, который послужил основой для текущего проекта.

Собрав старые наработки я сделал проект Platforman 2. Где первый? Судя по датам он стал основой для Красного робота и собран после Непонятной тьмы.

Platforman 2 основа для всех моих следующих платформеров, неким хабом откуда будут тянутся скрипты и объекты в другой проект, а потом доработанные версии этих скриптов из проекта должны вернутся в этот хаб-проект.

В будущем я хочу сделать технический монстр-проект Framework, где будут все мои наработки, чтобы глобально отслеживать изменения своей кодовой базы GameMaker. Для меня является проблемой — трекать изменения всех своих модулей, скриптов и объектов. Я делал таблицу и сейчас наткнулся на airtable, где попытаюсь выстроить целую БД, чтобы было проще оперировать своими наработками. Это было небольшое техническое отступление.

Пока я делал основу, где герой может прыгать, собирать монеты, и бегать по кривым поверхностям, концепт оброс некоторым количеством деталей концепта. Я приступил к созданию конкретного списка что нужно сделать т. е. список To-Do. Думал, что пока я пишу список и реализую его, то вся конкретика появится и устаканится. Но вышло так, что даже в своих списках (враги, например) всё ещё не появились как конкретный концепт и на тот момент было непонятно что вообще реализовывать.

Скорчед хотел попробовать использовать FMOD, и я даже скачал его себе на компьютер. Есть официальное расширение для GameMaker. Но честно, я сомневался в решении использовать FMOD. Мне было непонятно зачем такая сложность для простого проигрывания звуков. Там была пара интересных моментов, например, что из звуков можно составить более сложный звук и «запрограммировать» какие-то параметры. Но хоть демка от самого GameMaker у меня работала, но уж слишком много кода и телодвижений нужно было сделать для добавления всего лишь одного звука. Я решил, что это неоправданно и отказался от этой библиотеки.

Моё решение Скорчед принял и мы стали использовать обычные звуки в GameMaker. Я создал скрипт GameSFX() с кучей функций ffx_ (нет, это не final fantasy x!) — так обозначил всю группу звуко-эффектных функций, в которых Скорчед мог делать всё что захочет. А я вызывал эти ffx_ функции в коде игровой логики. ffx_ не называется sfx_ от того, чтобы не создавать путаницу. FFX (первая F это Feedback) я хотел расширить с просто звуковых эффектов, до более глобальных: vfx (спрайты дыма, например), тряска камеры, вибрация контроллера. Но это, наверно, уже только в будущих проектах.

Помню, Скорчед написал, что он так-то программист, но не хочет участвовать в конкурсах в этой роли. И теперь я понимаю почему! Об этом позже. Но программерские навыки явно помогли ему с легкостью дополнять функции звуков, если он что-то захотел изменить. Он попросил меня только добавить возможность блокировки воспроизведения звуков, если их больше чем N. Чтобы не игралось 10 выстрелов, например, а только 4 одновременно.

Как я писал ранее, мы сразу обозначили свои роли: я технический отдел, Кот рисует графику, сюжет, делает уровни, а Скорчед отвечает за звуки (в будущем он с Котом подбирали музыку, я в это не лез). Однако, ещё на этапе обдумывания думал, что катсцены, которые были прописаны в сюжете, будет делать Кот через мою удобную систему написания катсцен кодом, предполагая, что он с движком знаком. Моя система такая, что нужно писать последовательность действий в виде функций. Это не тоже самое, что и встроенные в GameMaker Timeline и Sequence, но думаю, что оба вида ресурсов можно использовать внутри моей системы. Это опять было небольшое отступление.

Но оказалось так, что и реализацию конкретных катсцен должен делать я. Ладно катсцены — система удобна мне и с ней относительно быстро сделал… или не сделал, потому что пошла зависимость от конкретики и проблемы. Вернее сказать, что этой конкретики не было в каких-то вещах. Я не могу сделать катсцену для сцены-1, которая на уровне-1, потому что этого уровня ещё нет в хоть каком-то виде. Конечно, те вещи что я мог реализовать я таки реализовал, где нет зависимости от уровня. Мне казалось, что я большую часть времени делал не конкретную игру, а какой-то эфемерный набор вещей, который мог пойти под нож и «ну надо переделать», хотя я и так много сил тратил на это. Почти весь этап разработки я провёл на тестовых уровнях под названием playground, без тестирования на конкретных игровых уровнях.

Поворот

Это не сюжетный поворот, а скорее точка слома-перелома. Мне кажется, что я перегорел. Постоянно добавляющиеся список фичей рос, а игры не было видно. Пункты из списка закрывались один за другим, и казалось уже вот всё готово, то тут и возникали некие новые детали и те самые «надо сделать», хотя вот же готовое, но нет. Именно тут, как мне кажется, я понял о чём писал Скорчед — почему он не хочет быть программистом в конкурсных участиях (хотя, может я не так его понял). Какие-то вещи добавлялись, чтобы быть переделаны т.к. изначально были не чётко обозначены. Вы можете сказать, что это нормальная практика и итеративный процесс в разработке. Может быть это так, может быть это я такой ворчун, но когда ты сделал систему и нужно снова вносить правки, которые изначально не предполагались, когда значительную часть разработки\конкурса провели в обсуждениях и вроде всё выяснили — это раздражало. Программировал игру из последних сил на тот момент. Я далеко не перфекционист и мне важнее закончить игру, а тут я видел, что с таким подходом закончить не успеем никак.

Конечно я не хочу наговорить на команду, но мне в тот момент, с моей стороны казалось то, что всегда меня преследовало при неудачных коопах, где я был на технологиях: словно я делаю всё, а другие либо ничего, либо незначительно мало относительно моих вложений. Как я писал во ведении: я не знаю как это ощущали Кот, Скорчед и что они делали и как старались, а может были какие-то обстоятельства IRL. Например, Кот писал, что он рисовал графику в последние дня 3 и из этих трёх дней он спал крайне мало, если вообще спал.

Подходил дедлайн и моя твёрдая уверенность, что не успеем и что время будет потрачено зря, отвердевает до состояния алмаза. Так и хотел написать в чат «я же говорил» (а может и написал!?).

Кто-то наверно скажет, что плохой тайм менеджмент, координатор и лидер проекта, надо было брать сеньёра с 40 летним стажем ради игры на локальном сайте для небольшой группы энтузиастов … и вы будете серьезны? Это же конкурс хоббистов, по сути. Вся проблема, как мне кажется, была в объеме самой игры. Изменилось бы что-то, если бы я был ведущим лидером проекта, который бы снижал хотелки? Не знаю, может быть мы бы успели в срок, а может и нет, а может получилась бы не игра, а какая-то пустышка.

Когда делаешь игру в одиночку (соло), то ты ответственен только перед собой. Не успел — виноват ты сам. Сделал плохой геймплей — виноват ты сам. Весь срок конкурса бегал по неотложным делам в IRL — виноват … ладно, тут может быть кто-то другой виноват!

Может показаться, что я ругаю команду, но это не совсем так — я лишь слегка бухчу, хотя в тот момент я действительно уже был выжат. Мне, конечно, не понравилось, что нельзя просто сесть и написать код один раз и это пойдёт в «продакшен». Разумеется со своими итерациями, но не такими, что по сути надо делать две игры по объемам.

Конкурс продлили ещё на неделю. Хоть в чате разработки я писал, что не выдержу при продлении, но каким-то образом нашёл силы доделать игру. И опять делал свои списки с задачами. Мне это помогает сосредотачиваться на проекте т.к. это конкретика, конкретная вещь, делаешь только её и всё. Список багов и других моментов постоянно появлялся в чате и быстро улетал в историю и я просил писать в особый гуглдокумент, где у нас была информация по проекту и где я отслеживал свои задачи в виде простого списка.

Но и продления не хватало. Было решено вырезать небольшой, и как мне кажется, незначительный кусок в игре, где была ещё одна локация. Мне скорее обиднее за один небольшой игровой объект, которую просили сделать, а в итоге она и не была использована. Не то чтобы это меня сильно задело, но с этим связано то, что для добавления взрывчатки нужно было менять поведение объекта нанесения урона… короче запутанная история, детали которой я забыл. Суть в том, что потратил время и силы на этот объект, а он не оказался нужен.

Графика была не вся готова. Поэтому я вызвался помочь с ней и нарисовал Босса. Когда я считал примерное количество анимаций и кадров, то ужаснулся —  73 кадра! И это только по предварительным расчётам. Конечно, нужно было это нарисовать очень быстро и я осилил это за два дня.

Потом, продолжаю тематику злодеев, я нарисовал и всех трёх врагов с простейшими анимациями. Но врагов я рисовал уже во время так называемого багодня, где по идее можно было только исправлять баги, но организатор Anim86 разрешил «полировать игру». Поэтому были дорисованы некоторые спрайты (многие) Котом и враги мной.

Выводы

Многое я уже забыл спустя месяц разработки. Но мы сделали игру! Ура! Не 100% какую задумывали, но всё же дошли до конца.

И в качестве эксперимента решил выложить видео на Youtube и VKVideo продолжительностью в 30 минут, где я собрал короткие видео (и пару скриншотов) с этапов разработки в виде эдакой хроники:

Всегда предполагал и закрепил на опыте: разработка в команде это ДОЛГО и сложно! Очень много времени тратится на связь, обсуждения, разговоры, координацию и прочее. Проекту нужен тот, кто видит игру и поведёт других — тимлид, можно сказать.
Может от того, что я был программистом и бухтел, но мне кажется, что таким лидером должен быть именно программист — он будет знать все технические аспекты и возможности игры.

С другой стороны делегирование т. е. разбивка задач на другие области помогает сосредоточится на одной, но не без минусов. Когда ты не делаешь уровни, то для тебя они становятся интереснее, нежели ты сам их спроектировал и протестировал раз 100. Отдать кому-то собирать уровни это интересно!

Особо мне понравилось взаимодействие с отдельным человеком на звуках, наверно, как и музыке: я всегда оставляю звуки и музыку под конец разработки и иногда не успеваю их добавить. Мне кажется это достаточно долгим выбирать или синтезировать звук, в то время когда можно было бы дорабатывать игру. А когда эти звуки подберут\сделают за тебя ты можешь действительно делать игру, а не тонуть в поисках звуковых файлов и подбирать звучание.

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

У нас в планах имеется выпуск пост-конкурсной версии с некоторыми изменениями и улучшениями. Можете скачать текущую версию с Google Drive и следить когда появится пост-конкурсная версия в этой папке Google Drive.

Так же можно скачать из моего ТГ канала.

Да, был момент, когда я очень сильно устал от проекта и наверно готов был бросить это дело, но не бросил — ответственность перед командой и игрой. Я рад, что у нас получилось сделать игру!

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

Задавайте вопросы! Участвуете ли вы в конкурсах по разработке? Если да, то в команде или в одиночку? Каков ваш опыт, мнение и чем можете поделиться по этому поводу?

Всем спасибо за внимание!

Привет, Пикабу!

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

Пикабу — кошачья территория

Из 150 питомцев в базе 93% — кошки. Собак буквально десяток. Не знаю, то ли кошачий диабет правда встречается чаще, то ли владельцы котиков активнее гуглят решения, то ли вы тут просто все кошатники. Скорее всего, третье.

Диабет — болезнь пожилых

Больше половины питомцев старше 12 лет. Ещё штук 40 — от 7 до 12. Молодых и котят совсем мало. Это, в общем, ожидаемо — с возрастом риск растёт. Но когда видишь это на графике, как-то иначе осознаёшь.

Половина реально пользуется

Из 150 питомцев записи в дневнике есть у 75. Это не "зарегистрировались и забыли" — это реальное использование. 36 питомцев активны за последнюю неделю.

Около 40 питомцев с 1-10 записями — новички. Штук 27 с 11-50 записями — втянулись. И есть несколько с 50-100+ записями — это ежедневные замеры месяцами подряд.

Вы — люди режима

Вот это меня реально удивило. Смотрите на график активности по часам: два жёстких пика — 8 утра и 8 вечера. Это же расписание уколов. Утром укол — замер. Вечером укол — замер. Никакого "а, потом запишу". Чётко, как по армейскому распорядку.

И большинство пишет сразу

70% записей вносятся в реальном времени — прямо после замера. Только 30% "батчем", когда накопили и потом забили всё разом. Получается, телефон всё-таки под рукой в момент укола. Приятно, что приложение вписалось в рутину.

Ссылки для врачей — топ фича

Честно, не ожидал. 62 ссылки создано, 130 просмотров. В среднем каждую открывали дважды. Похоже, сами проверяете как выглядит, а потом врачу скидываете. Или врачи заходят несколько раз — тоже хороший знак.

Мальчиков чуть больше

55% мальчики, 45% девочки. И почти все стерилизованы — 93 из 150. Четверо не стерилизованы, остальные не указали.

Всего записей — почти 1200 за месяц

1118 записей глюкозы. Остальные метрики (вес, давление, температура) почти не используются — их добавил недавно, ещё не раскачались.

А как там Манишка?

Стабильно. Глюкоза скачет, но в пределах нормы. Привыкла к уколам, не дёргается. Главное — чтобы еда была вовремя и никто не занимал не мешал её спать.

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

Просьба та же: если пользуетесь и что-то неудобно — напишите.

📱 Приложение: https://diabnostic.ru
💬 Поддержка: https://t.me/diabnostic_support
💡 Предложить идею: https://voice.diabnostic.online
📢 Канал с обновлениями: https://t.me/diabnostic

Легенда инди-разработки и основатель Spiderweb Software написал полезную статью для начинающих разработчиков. В ней он анализирует, как работает мозг игрока, приводит примеры из WoW и Baldur’s Gate, а также делится советами.

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

Наказание за игру или награда за отдых

В ранних MMORPG, ценность игры измерялась часами монотонного гринда. Разработчики World of Warcraft столкнулись с вопросом: как удержать интерес игроков, не замедляя их прокачку?

Они ввели «механику усталости» — после двух часов игры награды начинали снижаться. Игрокам это конечно же не понравилось.

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

Вывод Фогеля: «Часто дело не в самой механике, а в её подаче. Смена семантики — с наказания на поощрение — может превратить раздражитель в любимую фичу».

Проблема: Почему игроки копят зелья, но не пьют их

Из анализа Джеффа Фогеля: Любой разработчик RPG знает, что игроки любят нести сотни зелий и свитков до финальных титров, но так и не использовать их. Baldur’s Gate 3 — яркий пример. Ближе к концовке игры рюкзаки ломятся от полезных, но нетронутых предметов.

Главная причина — игроки боятся потерять найденное.

«Эффект потери» — это базовый психологический принцип: боль от потери ощущается острее, чем радость от аналогичной выгоды.

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

Стратегии работы с «эффектом потери»

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

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

Есть ещё один вариант

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

Пример из Queen’s Wish: зелья не исчезают, а их заряды полняются в городе. Подземелья сбалансированы под полный расход. Игрок знает, что ресурс вернётся, и тратит его более свободно.

Главный принцип: «Работайте с игроком, а не против него»

Философия Фогеля проста: «Не делайте игру для гипотетического «правильного» игрока. Делайте её для реального человека, который ненавидит терять, любит халяву и бережно хранит ресурсы на чёрный день. Ваша цель — не перевоспитать игрока, а элегантно обойти его когнитивные искажения в рамках игрового дизайна.»

Инди‑разработчик одновременно пишет код, рисует иконки, настраивает аналитику и считает, хватит ли выручки, чтобы дожить до следующего релиза. В голове при этом орут шесть голосов — от художника‑перфекциониста до паникёра, который шипит: «не лезь в серяк, всё сломаешь». Недавно я это сполна почувствовал, когда на финальной прямой запуска моего расширения для Chrome под Европу Google заблокировал рекламный кабинет — весь запуск был заточен под поисковый трафик, и в один момент канал просто исчез.

Кейс: Google Ads хлопнул дверью

Расширение жило за счёт идеи: забираем тёплый поисковый трафик из Google Ads, ведём на продукт, дальше монетизируем. Аудитория — Европа, так что нормальной альтернативы Google по объёму и качеству трафика, по сути, нет. На финальной части запуска, когда оставалось включить бюджеты и смотреть на конверсии, рекламный кабинет схлопнулся по политике: без внятных объяснений, с размытыми формулировками и стандартной отпиской.

В голове мгновенно нарисовались четыре сценария:

• спорить с Google и пытаться выбить разбан через апелляции;

• купить новый кабинет у агентства;

• залезть в прокси/серяк с «арендованными» аккаунтами;

• переписать продукт под другой источник трафика (например, Яндекс), хотя целевая аудитория живёт в Европе.

И вот тут во мне в полный голос заговорили все внутренние персонажи — от паникёра до художника. Чтобы не принимать решение «на ощущениях», я вытащил метод шести шляп.

Что за метод и зачем он инди

Метод шести шляп — это техника Эдварда де Боно, где мышление делится на шесть режимов: факты, эмоции, риски, выгоды, креатив и модерацию. Вместо того чтобы держать всё в голове одновременно и метаться, ты по очереди «надеваешь» шляпы и смотришь на одну и ту же ситуацию под разными углами.

Для инди‑разработчика это особенно полезно: обычно решения принимает либо внутренний паникёр (чёрная шляпа), либо вдохновлённый художник (зелёная/красная), а белая и жёлтая — факты и выгоды — просто молчат.

Классика такая:

• Белая — факты и цифры.

• Красная — эмоции и чуйка.

• Чёрная — риски и «что пойдёт не так».

• Жёлтая — выгоды и «что пойдёт так».

• Зелёная — варианты и идеи.

• Синяя — модератор, который собирает всё в план.

Ниже — как я разобрал свою блокировку Google Ads по этим шляпам.

Шаг 1. Белая шляпа: что есть на столе

Сначала — сухие факты без истерики.

• Продукт уже сделан и заточен под Google: UX, офферы и воронка строились вокруг поискового трафика.

• Аудитория живёт в Европе, доля Google по поиску там — доминирующая, Яндекс как основной источник трафика слабый и местами просто отсутствует.

• Кабинет заблокирован, есть формальная возможность апелляции, но практика показывает: разбирательства могут тянуться неделями без гарантий результата.

• Время и деньги, уже вложенные в продукт и рекламный сетап, — немалые, полный разворот в сторону Яндекса или другого канала = ещё месяцы работы и риск не выйти на сопоставимый объём трафика.

На этом этапе задача — увидеть реальность без «всё пропало» и «да нормально, сейчас разбанят».

Шаг 2. Красная шляпа: честно про эмоции

Здесь вообще не нужен рационал — только то, что ощущается.

• Злость: «меня наказали без объяснения, хотя я не чувствую себя злодеем».

• Страх: «если полезу в серяк — могу потерять вообще всё», «если уйду в Яндекс — просто похороню идею под Европу».

• Усталость: «не хочу ещё месяц воевать с саппортом ради призрачного разбана».

Смысл — признать, какие решения ты принимаешь просто из страха или обиды, чтобы потом не маскировать это под «рациональный выбор».

Шаг 3. Чёрная шляпа: где можно умереть

Дальше — максимально пессимистичный взгляд на каждый сценарий.

• Спорить с Google:

  • Потратишь недели на переписку, получая те же шаблонные ответы, без разбана.

  • За это время продукт не продвигается, выручка = 0, мотивация падает.

• Купить новый кабинет у агентства:

  • Риск попасть под политику обхода системы и получить ещё более жёсткую блокировку.

  • Завязаться на стороннего посредника и их практики, которые могут завтра поломаться.

• Прокси и серые схемы:

  • Бан по цепочке, блокировки платёжек, репутационные риски.

  • Постоянная гонка с системой вместо работы над продуктом.

• Переписать продукт под Яндекс:

  • Месяцы разработки и адаптации ради канала, который изначально слаб для твоей ЦА.

  • Можно потратить ресурс и всё равно не выйти на нужный уровень трафика.

Чёрная шляпа нужна, чтобы честно увидеть, где ты можешь потерять больше, чем готов.

Шаг 4. Жёлтая шляпа: где тут шанс

Теперь тот же список, но с вопросом «что здесь может пойти хорошо?».

• Спорить с Google:

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

• Купить новый кабинет у агентства:

  • Быстрый возврат к тестам, если работать аккуратно и не нарушать политики.

  • Можно продолжить валидировать продукт и экономику уже сейчас, не замораживая проект на неопределённый срок.

• Прокси / серяк:

  • Потенциально быстрый старт и доступ к объёмам там, где «всё перезабанено». Но цена этого старта слишком велика для соло‑инди.

• Переписать продукт под Яндекс:

  • Диверсификация и снижение зависимости от одного монополиста.

  • Возможность протестировать рынки, где конкуренция ниже или трафик дешевле, если продукт адаптируем.

Жёлтая шляпа возвращает понимание, что в каждом сценарии есть не только «помереть», но и «выиграть» — вопрос цены и горизонта.

Шаг 5. Зелёная шляпа: альтернативы, о которых не думаешь в панике

Здесь цель — не выбирать между A/B/C, а придумать C1, C2, D.

Например:

• Комбо‑стратегия: отправить официальную апелляцию в Google и параллельно запустить трафик через купленный у агентства кабинет с максимально белой конфигурацией.

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

• Адаптация продукта под несколько рекламных сетей (включая Bing Ads или локальные решения), чтобы в будущем бан одного кабинета не ставил крест на всём проекте.

Зелёная шляпа — это место, где из «всё или ничего» появляется несколько ступеней и промежуточных экспериментов.

Шаг 6. Синяя шляпа: решение и правила игры

На этом этапе я собрал всё выше в конкретный план.

Что решил:

• Не уходить в полностью серые схемы, где ставка — не только кабинет, но и платежи/аккаунты.

• Зафиксировать стратегию:

  • подать нормальную апелляцию в Google (без иллюзий, но как обязательный шаг);

  • купить новый кабинет у агентства и использовать его максимально аккуратно, без нарушений политик и «серых» связок, чтобы продолжить тесты и не замораживать проект;

  • в параллель смотреть на альтернативные каналы, но не сносить архитектуру продукта ради гипотетического Яндекса под Европу.

Какие метрики для себя отметил:

• стоимость клика и установки с нового кабинета;

• конверсия в целевое действие внутри расширения;

• стабильность аккаунта в течение первых недель работы.

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

Как использовать это у себя

Если у тебя сейчас:

• заблокировали рекламный кабинет;

• умер основной источник трафика;

• приходится выбирать между «серяком», паузой и сменой стратегии —
  вместо того, чтобы бесконечно крутить в голове одни и те же мысли, попробуй сделать так:

1. Чётко сформулируй вопрос (одним предложением).

2. Пройди по шляпам и честно выпиши по 3–5 пунктов на каждую.

3. В синей шляпе зафиксируй: какое решение ты принимаешь сейчас, на какой срок, какие метрики покажут, что это было не зря.

Когда начал прогонять через шляпы не только монетизацию, но и такие аварийные ситуации, стало заметно, что во мне чаще всего орёт чёрная шляпа (паникёр) и иногда красная (обида/страх), а факты и выгоды просто не доходят до стола.

Если тебе заходит формат разборов решений инди‑разработчика (с цифрами, факапами и рабочими фреймворками), залетай в мой Telegram‑канал. Там чаще, короче и местами больнее