Что нужно сделать, чтобы шли и оставались?

Сложность не в том, что нужно заполнить три поля. По отдельности они действительно стандартные.

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

Множество нюансов…

2 Likes

Если игроку сложно потратить 5 секунд на регистрацию, то представляешь сколько ему надо потратить времени на изучение правил игры?

1 Like

Видишь, не поняла.. Это не так работает, когда завлек идет другой таймер.

Главные первые секунды, это на уровне психологии.

1 Like

Еще забыл, у нас нет описания на главной бонусов новичка и преимуществ серверов (доступный или прибыльный)

Поэтому и уточняла, чтобы понять о чем речь.

1 Like

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

Первые секунды важны, даже с каждой прокруткой колесика люди отваливаются в процентном соотношении.

CRO (Conversion Rate Optimization) — оптимизация конверсии.
Это работа над тем, чтобы больше посетителей выполняли нужное действие: зарегистрировались, купили, оставили заявку и т.д. Анализируют, где люди уходят, тестируют разные варианты страниц, кнопок, текстов, :backhand_index_pointing_right: форм (как раз то о чем пишу).

1 Like

Ну вот вроде как был же формат “Карибский землевладелец”. Но потом от него почему отказались и даже акции обратно выкупили.

Я относительно такой концепции не возражаю, тут скорее вопрос к администрации, почему такой формат не зашёл.

3 Likes

Согласен. В этом направлении тоже нужно поработать.

Да и это тоже имеет место быть.

1 Like

Даже не мои догадки — это видно по моей статистике!!! Похожую ситуацию я видел и у других партнеров, кто выкладывал свои показатели на форуме. Люди просто не доходят до регистрации, показатель отказа окло 98,85%. Какая бы реклама ни была, она не поможет, если пользователь теряется еще на главной странице. Причины указал выше

1 Like

Был такой формат. Он мне нравился. И первое, что я сделал, когда вернулся в игру - кинулся искать эти акции… А их НЕТ!
Выкупили их, или нет, у меня - теперь сложно сказать. О том что они выкупались я впервые услышал уже тогда, когда искать подтверждение было слишком поздно, из-за массы других телодвижений на аккаунте.
Почему отказались - тоже не знаю. А гадать не хочу, дабы никого не обидеть.

Риторический … А зачем прибыль отдавать игре, если можно просто усложнить и тем самым убить интерес ?)))

Не совсем так, я узнал про проект по рекламе.

2 Likes

Которую легко мог заказать игрок, под партнёрку. Там ведь наверняка был реф хвост.

2 Likes

Я вроде на Рамблер, тоже через баннер и не сразу зарегистрировался, так как не было чёткой фразы про вывод.

1 Like

Что нужно сделать, чтобы люди шли и оставались — часть 1 из 2

Пост отредактирован chagpt-5.6 Sol pro, который подчистил эмоциональный мусор, противоречия, двусмысленность и неполиткорректность приведя все в порядок. В оригинале была матершина, обвинения в растрате, подлоге, жульничестве, насилии над личностью, лютая неполиткорректность и всякакя Санта Барбара. В резултьтате есть неточности, но мне лениво их исправлять. В целом я соглясен почти со всем, но это потому, что исходный текст был моим. Время генерации и комментарий нейросети оставлены специально. Чтиво долгое, но мне понравилось. Матюкофф не хватет, конечно…

Поделено на 2 части, ибо нельзя опубликовать пост более 32000 символов.

Worked for 8m 18s>

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


Что нужно сделать, чтобы люди шли и оставались

Текст сознательно длинный.

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

Кому нужен ответ в несколько строк, он выглядит так:

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

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

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


1. Проблема не в отсутствии рекламы

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

Отчасти это правда. Новые игроки нужны. Но реклама сама по себе ничего не решает.

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

Человек увидит сложный интерфейс, десятки взаимосвязанных механик, необходимость читать огромные объёмы информации, непонятный порог входа и отсутствие очевидного ответа на простой вопрос:

Что я должен сделать прямо сейчас и зачем мне это делать?

Часть уйдёт сразу.

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

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

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

Поэтому сначала нужно ответить на четыре вопроса:

  1. Почему новый человек должен зарегистрироваться?
  2. Почему он должен вернуться завтра?
  3. Почему он должен вложить деньги через месяц?
  4. Почему он должен остаться через пять лет?

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


Часть I. Стабильность и доверие

2. Главная проблема — отсутствие предсказуемости

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

Главная проблема — отсутствие ощущения надёжности.

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

Сейчас строить долгосрочные планы сложно.

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

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

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

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

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

Но существует огромная разница между развитием проекта и переписыванием уже совершённых сделок задним числом.


2.1. Менять можно правила будущего, а не прошлое

Нужен простой принцип:

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

Например, если сегодня продаётся лицензия с определёнными условиями, через год эти условия не должны ухудшаться для старых владельцев.

Если вводятся новые требования к активу, должны существовать:

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

Новая экономическая модель действительно может проектироваться почти с чистого листа. Но здесь важно разделять две вещи:

Совместимость старой механики можно не сохранять.

Совместимость права собственности сохранять необходимо.

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


2.2. Нужна экономическая конституция проекта

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

Например:

  1. Значительные экономические изменения объявляются заранее.
  2. Для крупных изменений устанавливается переходный период.
  3. Уже приобретённые активы не ухудшаются задним числом без компенсационного механизма.
  4. Причина изменения и ожидаемый эффект публикуются до запуска.
  5. После запуска публикуется фактический результат.
  6. Экстренные изменения допускаются только при угрозе безопасности или существованию проекта.
  7. Даже экстренное изменение должно сопровождаться объяснением и планом устранения последствий.
  8. Условия ограниченных лицензий и выпусков фиксируются на момент покупки.
  9. Эмиссия токенов и игровых валют производится только по заранее опубликованным правилам.
  10. Администрация не использует информационное преимущество для торговли активами проекта.

Такой документ может дать проекту больше доверия, чем ещё один новый блок.


2.3. Должен существовать публичный план развития

Не обязательно раскрывать коммерческие тайны или публиковать точные даты всех обновлений.

Но игрок должен понимать хотя бы направление движения.

Например:

  • какие механики считаются основными;
  • какие механики будут переработаны;
  • какие направления больше не являются стратегическими;
  • будет ли развиваться игровой интерфейс;
  • планируется ли бесплатный вход;
  • какую роль будут выполнять CLC и AMERO;
  • каким предполагается DAO;
  • какие виды автоматизации будут добавляться;
  • какие источники дохода администрация считает основными;
  • какой должна стать экономика через три-пять лет.

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

Это неправильная модель.

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


Часть II. Интерфейс и автоматизация

3. Управление крупным аккаунтом не должно быть наказанием

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

Не в качестве наказания. В качестве обязательного тестирования собственного продукта.

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

Куры — это не игровой процесс. Это способ превратить свободный вечер в административную работу.

Поля могут освобождаться не тогда, когда ожидает игрок. Ремонты княжеств требуют постоянного внимания. Множество механик живёт каждая в своём интерфейсе, по своим правилам и со своей логикой.

На маленьком аккаунте это раздражает.

На крупном аккаунте это превращается в отдельную профессию.


3.1. Не всякое ручное действие является геймплеем

Иногда ручное управление защищают аргументом:

Если всё автоматизировать, играть будет не во что.

Это верно только в том случае, если ручное действие содержит выбор, риск, соревнование или необходимость принимать решение.

Если игрок выбирает стратегию кормления, оценивает рынок, решает, какое животное оставить, а какое продать, — это игровой процесс.

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

Если игрок анализирует сроки освобождения полей и строит производственный цикл — это управление.

Если поле фактически освобождается позже указанного времени и игрок вынужден постоянно обновлять страницу — это не управление.

Если игрок определяет, когда ремонтировать объект, исходя из экономики, — это решение.

Если он должен вручную зайти в сотни одинаковых объектов и нажать одинаковую кнопку — это канцелярская работа.

Автоматизация должна убирать действия, в которых нет содержательного выбора.


3.2. Базовая автоматизация должна быть доступна всем

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

Базовая автоматизация — это не роскошь и не инвестиционная привилегия. Это минимальное требование к современному проекту.

В базовый набор должны входить:

  • глобальный поиск по объектам;
  • фильтры;
  • сортировка;
  • сохранённые наборы фильтров;
  • групповые операции;
  • теги и пользовательские категории;
  • история действий;
  • журнал событий;
  • единая система уведомлений;
  • отображение точного времени завершения процессов;
  • массовое подтверждение однотипных операций;
  • базовые правила автоматического ремонта;
  • минимальные и максимальные уровни запасов;
  • отчёт о состоянии хозяйства;
  • нормальная работа с мобильного устройства;
  • возможность быстро найти проблемный объект.

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


3.3. Расширенную автоматизацию можно монетизировать

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

Например:

  • сложные сценарии действий;
  • автоматическая сортировка животных по параметрам;
  • автоматическая выбраковка;
  • автоматический забой при достижении заданных условий;
  • автоматические производственные цепочки;
  • управление очередями;
  • прогнозирование дефицита ресурсов;
  • автоматическое размещение заказов;
  • автоматическая закупка в заданном ценовом диапазоне;
  • расширенная аналитика;
  • отчёты по доходности;
  • API;
  • уведомления во внешние системы;
  • сложные правила ремонта;
  • автоматическое перераспределение ресурсов между объектами.

Вот за это уже можно брать деньги, продавать подписки, лицензии или использовать удержание AMERO.

Разница принципиальная:

Поиск животного и групповая операция — базовое удобство.

Система, сама принимающая решения по заданной стратегии, — расширенный коммерческий инструмент.


3.4. Нужна единая панель управления

У крупного владельца должна существовать страница, на которой он видит состояние всего аккаунта:

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

Сейчас игрок часто управляет не хозяйством, а набором разрозненных страниц.

Проекту нужен не просто новый дизайн. Нужна единая модель управления.


Часть III. Экономика

4. Деньги не должны появляться из воздуха

Это центральный вопрос.

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

Но если эти цифры связаны с реальной ценностью, выводами или обязательствами, появляется простой вопрос:

Кто за это заплатил?

У любой выплаты существует источник.

Это может быть:

  • платёж другого игрока;
  • комиссия;
  • продажа товара или услуги;
  • внешний доход проекта;
  • расходование резерва;
  • новая эмиссия;
  • снижение стоимости другого актива;
  • будущие обязательства.

Других вариантов нет.

Если игрок получает экономическую выгоду, но источник этой выгоды не виден, это не означает, что источник отсутствует. Это означает, что он скрыт или перенесён во времени.

В конечном счёте дефицит всё равно кто-то оплачивает.


4.1. Нужно разделять игровую награду и финансовое обязательство

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

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

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

Поэтому необходим принцип:

Плюшки могут появляться из воздуха. Деньги и ликвидные активы — нет.

Или, точнее:

Любая эмиссия ликвидного актива должна иметь понятное правило, лимит, цель и источник спроса.


4.2. Нужна не обязательно дефляционная, а сбалансированная экономика

Я первоначально формулировал это как необходимость дефляционной модели. Но точнее будет сказать иначе.

Экономика должна быть:

  • предсказуемой;
  • проверяемой;
  • ограниченной;
  • сбалансированной;
  • устойчивой к снижению притока новых денег.

Дефляция сама по себе не является решением.

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

С другой стороны, постоянная инфляция уничтожает накопления и превращает долгосрочное владение в наказание.

Нужен баланс между:

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

Цель — не обязательное постоянное сокращение денежной массы.

Цель — отсутствие бесконтрольного размывания стоимости.


4.3. Каждый фонд должен иметь понятный источник

У игроков возникают вопросы по поводу драконов, различных фондов, чудес, двигателя, разума и других механизмов.

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

Но игрокам оно неочевидно.

Поэтому по каждому крупному фонду должна существовать публичная схема:

  1. Из каких поступлений формируется фонд?
  2. Какой процент поступлений направляется в него?
  3. Есть ли максимальный размер обязательств?
  4. Что происходит, если поступлений недостаточно?
  5. Может ли фонд финансироваться эмиссией?
  6. Может ли администрация менять формулу?
  7. Как часто публикуется состояние фонда?
  8. Какие резервы существуют?
  9. Какова сумма будущих обязательств?
  10. Кто принимает решение о расходовании средств?

Слова «фонд пополняется из экономики игры» недостаточно.

Экономика игры — это не источник. Это общее название множества потоков.

Нужно видеть конкретную цепочку.


4.4. Налоги должны финансировать понятные расходы

Налог может быть полезным экономическим инструментом.

Он может:

  • финансировать награды;
  • оплачивать инфраструктуру;
  • поддерживать безопасность;
  • сдерживать спекуляцию;
  • выводить излишнюю ликвидность;
  • создавать доход проекту.

Но игрок должен понимать, куда налог уходит.

Налоги, комиссии и сборы должны покрывать:

  • реальные расходы проекта;
  • обслуживание инфраструктуры;
  • поддержку;
  • разработку;
  • безопасность;
  • маркетинг;
  • формирование резервов;
  • прибыль владельцев проекта.

Прибыль администрации — это нормально. Проект не обязан быть благотворительностью.

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

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

Она не должна зарабатывать за счёт уничтожения предыдущих ожиданий.


4.5. Нужен регулярный экономический отчёт

Хотя бы раз в месяц или квартал должен публиковаться отчёт в понятном формате.

Не обязательно раскрывать все коммерческие данные. Но основные потоки должны быть видны.

Например:

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

Главное здесь не сами красивые цифры.

Главное — возможность увидеть направление.

Экономика становится устойчивее или дефицит растёт?

Количество обязательств увеличивается быстрее резервов?

Эмиссия выше реального спроса?

Старые игроки получают выплаты из текущей деятельности или из поступлений новых игроков?

Без этих данных любое обсуждение превращается в спор верующих.


4.6. Нужно прекратить противоречащие друг другу стимулы

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

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

Нет смысла поощрять долгосрочное владение, если правила долгосрочного владения регулярно меняются.

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

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

Все стимулы должны смотреть в одну сторону.


Часть IV. Два связанных контура

5. Игру нужно разделить на игровой и бизнес-контуры

Не на два отдельных проекта, а на два режима внутри одной экономики.

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

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

Человек должен иметь возможность сначала играть.

А уже потом — инвестировать, строить крупный бизнес и управлять капиталом.


5.1. Игровой контур

Вход в игровую часть должен быть бесплатным либо почти бесплатным.

Игрок получает ограниченный набор возможностей и начинает выполнять понятные действия:

  • выращивать;
  • ухаживать;
  • производить;
  • охранять;
  • нападать;
  • соревноваться;
  • исследовать;
  • выполнять заказы;
  • получать достижения;
  • развивать персонажа;
  • открывать новые возможности.

Игровой процесс должен требовать внимания, выбора и навыка.

Не просто:

Нажал кнопку. Вернись через сутки.

А, например:

  • выбрать оптимальный момент;
  • проследить за состоянием объекта;
  • правильно распределить ресурсы;
  • выполнить цепочку действий;
  • уложиться в срок;
  • конкурировать с другими игроками;
  • избежать потерь;
  • повысить качество результата.

При этом награда может быть небольшой.

Важно не то, чтобы новичок сразу начал зарабатывать огромные деньги.

Важно, чтобы он понял:

  1. что здесь можно делать;
  2. что от него зависит результат;
  3. что его действия кому-то нужны;
  4. что у него существует путь развития.

5.2. Бизнес-контур

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

Здесь игрок занимается:

  • распределением капитала;
  • производственным планированием;
  • формированием заказов;
  • торговлей;
  • управлением рисками;
  • инвестициями;
  • анализом рынка;
  • развитием инфраструктуры;
  • наймом игровых исполнителей;
  • автоматизацией.

Бизнес-игрок не обязан лично нажимать каждую кнопку на каждом поле.

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

Игровой игрок выполняет конкретную работу.

Бизнес-игрок предоставляет активы, ресурсы, заказы и оплату.

Проект обеспечивает площадку и получает комиссию.


5.3. Связующим элементом должен стать рынок заказов

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

Он:

  1. выделяет поле;
  2. выбирает необходимую культуру;
  3. предоставляет исходные ресурсы;
  4. определяет требования;
  5. указывает срок;
  6. заранее резервирует оплату;
  7. публикует заказ.

Игрок из игрового контура принимает заказ.

Он должен:

  • подготовить поле;
  • внести удобрения;
  • соблюдать график;
  • следить за состоянием;
  • вовремя выполнить необходимые действия;
  • собрать урожай;
  • сдать результат.

После автоматической проверки результата заказчик получает продукцию, исполнитель — оплату, проект — комиссию.

Деньги исполнителя в этой модели не появляются из воздуха.

Они заранее внесены заказчиком.


5.4. Пример с животноводством

Владелец бизнеса формирует заказ на выращивание животного с определёнными параметрами.

Он предоставляет:

  • животное или право работы с ним;
  • корм;
  • инфраструктуру;
  • ветеринарные ресурсы;
  • условия содержания;
  • максимальный срок;
  • оплату.

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

Можно предусмотреть несколько уровней качества:

  • базовое выполнение;
  • повышенный вес;
  • улучшенное состояние;
  • выполнение без штрафов;
  • выполнение раньше срока;
  • редкий результат.

За качество начисляется дополнительная награда.

Если исполнитель бросил заказ, нарушил условия или допустил потери, снижается репутация либо удерживается залог.


5.5. Пример с охраной и войной

Княжество или предприятие нуждается в защите.

Владелец публикует заказ:

  • охранять объект в определённый период;
  • поддерживать необходимый уровень готовности;
  • реагировать на события;
  • участвовать в отражении нападений;
  • сопровождать груз;
  • выполнять патрулирование.

Исполнитель получает оплату не просто за наличие персонажа, а за выполнение измеримого действия.

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

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


5.6. Свободное производство тоже можно оставить

Никто не запрещает игроку выращивать то, что ему хочется.

Но важно разделять:

  • свободную игровую деятельность;
  • заказ с гарантированной оплатой.

Хочешь экспериментировать — выращивай что угодно и затем продавай результат на рынке.

Хочешь заранее понимать оплату — бери профинансированный заказ.

Именно так работает нормальная экономика.

Гарантированная награда должна существовать там, где существует гарантированный заказчик.


5.7. Что необходимо для рынка заказов

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

Нужны:

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

Начать можно с одного простого типа заказа.

Не нужно сразу переносить на эту модель половину проекта.

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


Часть V. Новый игрок

6. У новичка должен быть понятный первый час

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

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

Человек регистрируется и получает понятную последовательность действий:

  1. Создай персонажа.
  2. Выполни простое задание.
  3. Получи первый результат.
  4. Возьми заказ.
  5. Заработай небольшое вознаграждение.
  6. Потрать часть вознаграждения на улучшение.
  7. Увидь следующую цель.

Не нужно сразу объяснять ему всю экономику.

Не нужно показывать все активы.

Не нужно отправлять его читать сотни страниц форума.

Сначала человек должен получить игровой опыт.

Только после этого ему можно показывать глубину проекта.


6.1. Бесплатный вход не означает бесплатные деньги

Это важное различие.

Бесплатный вход означает возможность начать без обязательного вложения.

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

Иначе проект будет мгновенно атакован ботами, фермами аккаунтов и мультиаккаунтами.

Можно использовать ограничения:

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

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

Но бесплатный аккаунт не должен превращаться в бесконечный автомат печати токенов.


6.2. Первый результат должен появляться быстро

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

В первые минуты человек должен увидеть последствия своего действия.

В первый день он должен завершить хотя бы один цикл.

В первую неделю он должен понять, какое направление ему интересно.

В первый месяц — принять решение:

  • играть дальше бесплатно;
  • купить удобство;
  • вложиться в актив;
  • перейти в бизнес-контур;
  • участвовать в соревнованиях;
  • специализироваться на выполнении заказов.

Если человек месяц только готовится к тому, чтобы когда-нибудь начать играть, большинство до игры не дойдёт.


6.3. Новичку нужен маршрут, а не энциклопедия

У проекта может оставаться огромная база знаний.

Но знания должны показываться тогда, когда они нужны.

Система должна говорить:

Сейчас вам необходимо сделать вот это.

После выполнения:

Теперь вам доступно следующее.

А не:

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

Глубина — это преимущество после вовлечения.

До вовлечения глубина выглядит как препятствие.


6.4. Нужен отдельный путь возвращения

Кроме новых игроков существуют старые игроки, которые когда-то ушли.

Их вернуть часто дешевле и проще, чем привлечь полностью нового человека.

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

Нужен режим возвращения:

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

Игрок, который вернулся спустя несколько лет, не должен чувствовать, что его наказали за возвращение.


Часть VI. Монетизация

7. Проект должен зарабатывать на хорошем продукте

Коммерческий проект обязан приносить владельцам прибыль.

В этом нет ничего плохого.

Вопрос только в том, каким способом создаётся эта прибыль.

Хорошая монетизация возникает, когда игрок добровольно платит за:

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

Плохая монетизация возникает, когда игрок платит, чтобы:

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

Игрок должен платить потому, что хочет получить дополнительную ценность.

Не потому, что боится потерять предыдущие вложения.


7.1. Косметика и необязательные товары

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

  • оформление;
  • одежду;
  • декоративные постройки;
  • темы интерфейса;
  • рамки;
  • знаки отличия;
  • уникальные анимации;
  • питомцев;
  • внешний вид транспорта;
  • визуальные эффекты;
  • коллекционные предметы.

Такие товары практически не создают экономических обязательств.

Они не размывают основные активы.

Они не дают критического преимущества.

При этом они могут приносить чистую прибыль.

Но косметику невозможно продать человеку, которому неинтересно играть.

Поэтому сначала игровой процесс, потом магазин украшений.


7.2. Не нужно превращать проект в казино

Случайность может быть частью игры.

Но она не должна быть основой всей коммерческой модели.



Продолжение — во второй части: выход из проекта, CLC, AMERO, DAO, лицензии, коллективная работа, план действий, метрики и заключение.

6 Likes

Что нужно сделать, чтобы люди шли и оставались — часть 2 из 2

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

Часть VII. Выход из проекта

8. Возможность нормально выйти увеличивает желание войти

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

На мой взгляд, это неправильный подход.

Ликвидный вторичный рынок не обязательно увеличивает количество уходящих игроков.

Наоборот, понимание того, что актив при необходимости можно продать, уменьшает риск покупки.

Человек легче вкладывает деньги, когда знает, что они не заперты навсегда.

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

Возможность выхода делает вход безопаснее.


8.1. Комиссия допустима, наказание — нет

Комиссия за продажу аккаунта может существовать.

Она может оплачивать:

  • сопровождение сделки;
  • проверку;
  • смену данных;
  • безопасность;
  • арбитраж;
  • работу площадки.

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

Можно сделать её зависящей от срока владения.

Например:

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

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


8.2. Нельзя удерживать игрока стоимостью выхода

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

Это ловушка невозвратных затрат.

Игрок продолжает вкладывать не потому, что видит перспективу, а потому, что надеется спасти уже вложенное.

Каждое следующее вложение объясняется предыдущим:

Нужно внести ещё немного, иначе всё потеряет смысл.

Это крайне опасная модель.

Она может некоторое время поддерживать денежный поток, но разрушает доверие.

Люди, выбравшиеся из такой ситуации, редко возвращаются и почти никогда не рекомендуют проект знакомым.

Задача должна быть противоположной:

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

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


Часть VIII. CLC и эмиссия

9. Токен не должен быть способом переложить убытки

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

Технически они могут не переводить деньги напрямую.

Но увеличение предложения при неизменном спросе создаёт давление на цену и размывает долю старых владельцев.

Поэтому новая эмиссия — это не бесплатное финансирование.

Это перенос стоимости.

Вопрос только в том, на кого именно.


9.1. Эмиссия должна иметь предел и назначение

По CLC должна существовать публичная политика:

  • максимальное предложение;
  • текущий объём обращения;
  • объём заблокированных токенов;
  • график эмиссии;
  • назначение каждой новой эмиссии;
  • получатели;
  • сроки разблокировки;
  • ограничения на продажу;
  • влияние на существующих держателей;
  • возможность изменения правил;
  • орган, принимающий решение.

Формулировка «токены будут выпущены для развития проекта» слишком расплывчата.

Развитие проекта может означать что угодно.

Нужно указывать конкретно:

  • сколько;
  • кому;
  • зачем;
  • на какой срок;
  • по какой цене;
  • с какими ограничениями;
  • какой ожидается результат.

9.2. Нельзя финансировать операционный дефицит бесконечной эмиссией

Если проект тратит больше, чем получает, существует несколько честных вариантов:

  • сократить расходы;
  • увеличить выручку;
  • привлечь инвестиции;
  • использовать заранее созданный резерв;
  • изменить бизнес-модель;
  • временно снизить выплаты;
  • продать новый продукт.

Печать дополнительного торгуемого токена также возможна, но только как прозрачное привлечение капитала.

Нельзя изображать её как отсутствие расходов.

Эмиссия токена — это продажа доли в его будущей полезности и дефицитности.

Если делать это постоянно, токен превращается в амортизатор всех ошибок проекта.

В такой актив никто не будет вкладывать надолго.


9.3. Цена не обязана расти, но система не должна программировать падение

Нельзя обещать, что токен обязательно будет расти.

Рынок ничего никому не обязан.

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

Для этого нужны:

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

Цена должна быть рыночным результатом.

Но правила должны давать токену возможность расти, а не гарантировать его постепенное размывание.


Часть IX. AMERO

10. AMERO может стать важнейшим активом проекта

Сейчас наиболее понятным активом выглядит AMERO.

Не потому, что его цена обязана расти.

И не потому, что любой токен автоматически является хорошей инвестицией.

Его потенциальное преимущество заключается в другом:

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

Но все эти преимущества существуют только при одном условии:

Количество AMERO, отображаемое на игровых счетах, должно быть полностью обеспечено AMERO на контролируемых проектом адресах.

Если внутри игры можно отобразить миллион несуществующих AMERO, внешняя ограниченность токена перестаёт иметь значение.


10.1. Нужна проверка резервов и обязательств

Проект может регулярно публиковать:

  • официальные адреса хранения;
  • общий объём AMERO на этих адресах;
  • объём AMERO, принадлежащий игрокам внутри системы;
  • объём AMERO казначейства;
  • объём заблокированных AMERO;
  • объём токенов, предназначенных для наград;
  • график разблокировок;
  • правила использования казначейства.

Одних адресов недостаточно.

Нужно сопоставлять не только резервы, но и обязательства.

Условно:

AMERO на игровых балансах пользователей не должно быть больше, чем AMERO, фактически зарезервировано под эти балансы.

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

Так появится проверяемое доверие, а не доверие на основе обещаний.


10.2. AMERO нужна реальная полезность

Токен не становится ценным только потому, что его мало.

На него должен существовать спрос.

Спрос может возникать из нескольких источников:

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

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

Не с обещанием, что однажды появится что-то полезное.


Часть X. DAO

11. Обещанное DAO должно получить конкретную форму

Раз уж @Root говорил о DAO на основе AMERO, необходимо перейти от общего обещания к архитектуре.

Слово DAO само по себе ничего не означает.

Можно сделать действительно работающую систему управления.

Можно сделать декоративное голосование, результаты которого никто не обязан учитывать.

Поэтому заранее нужно ответить на вопросы.


11.1. Что именно решает DAO

Не все решения можно передавать голосованию держателей токена.

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

Но DAO может участвовать в решениях по следующим направлениям:

  • приоритеты разработки;
  • выбор пилотных механик;
  • распределение части бюджета развития;
  • правила использования казначейства AMERO;
  • запуск новых лицензий;
  • параметры отдельных комиссий;
  • правила грантов;
  • поддержка игровых конкурсов;
  • выбор экономических экспериментов;
  • финансирование пользовательских инициатив;
  • утверждение публичных отчётов;
  • выбор представителей в рабочие группы.

Нужно заранее определить границы.

Иначе любое неудобное решение можно будет объявить «не относящимся к DAO».


11.2. Один токен — один голос имеет проблемы

Простая система «один AMERO — один голос» превращает управление в голосование крупнейших владельцев.

В некоторых вопросах это логично. Тот, кто больше рискует капиталом, может иметь больший вес.

Но полностью отдавать проект нескольким крупным кошелькам тоже опасно.

Можно использовать комбинированную модель:

  • часть веса зависит от количества AMERO;
  • часть — от срока удержания;
  • часть — от репутации внутри проекта;
  • часть вопросов решается по принципу «один подтверждённый участник — один голос»;
  • для крупных решений требуется поддержка нескольких групп;
  • существуют ограничения максимального веса одного участника;
  • используется делегирование.

Одна формула не обязана применяться ко всем решениям.


11.3. Голосование должно учитывать срок удержания

Иначе человек сможет купить токены перед голосованием, повлиять на решение и сразу продать их.

Возможные решения:

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

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


11.4. DAO не должно управлять каждой кнопкой

Нельзя выносить на голосование все мелкие изменения.

Иначе проект утонет в бесконечных обсуждениях.

DAO должно определять:

  • правила;
  • бюджеты;
  • крупные направления;
  • границы полномочий.

А команда должна реализовывать решения и отвечать за результат.

Управление не означает, что тысяча держателей токена должна голосовать за цвет каждой кнопки.


11.5. Нужен первый небольшой рабочий пример

Не нужно сразу отдавать DAO половину проекта.

Можно начать с ограниченной задачи.

Например:

  • выбрать одну из трёх функций автоматизации;
  • распределить небольшой бюджет на пользовательские проекты;
  • определить следующий тип лицензии;
  • выбрать направление пилотного рынка заказов;
  • утвердить правила конкурса.

Главное — чтобы голосование имело реальный, заранее определённый результат.

После этого можно расширять полномочия.


Часть XI. Лицензии на автоматизацию за AMERO

12. AMERO можно связать с расширенной автоматизацией

Это одна из наиболее понятных форм полезности токена.

Большим аккаунтам критически не хватает автоматизации.

Но продавать её можно не просто как временную подписку, а как ограниченные передаваемые лицензии.

Пример, цифры полностью условные.

Выпускается лицензия:

Автоматическая выбраковка скота при рождении, если параметры ниже заданного значения.

Цена лицензии — 100 золотых.

Для активации необходимо заблокировать 1 000 000 AMERO.

Игрок покупает лицензию, блокирует токены и получает функцию.

Через некоторое время цена AMERO меняется. Новая серия лицензий может требовать уже 500 000 или 750 000 AMERO.

Но условия старой лицензии не меняются.


12.1. Старые условия должны сохраняться

Это критически важно.

Если сегодня лицензия требует миллион AMERO, а завтра администрация может в одностороннем порядке потребовать два миллиона, лицензия не является активом.

Это временное разрешение, которое ничего не гарантирует.

Поэтому параметры фиксируются:

  • функция;
  • необходимое количество AMERO;
  • срок блокировки;
  • стоимость продления, если оно существует;
  • возможность передачи;
  • комиссии;
  • условия отключения.

Изменения применяются только к новым выпускам.

Так ранние лицензии получают самостоятельную рыночную ценность.


12.2. Лицензиями нужно разрешить торговать

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

Например, игрок купил раннюю лицензию, требующую блокировки 500 000 AMERO.

Позже новые лицензии требуют уже 1 000 000 AMERO.

Старая лицензия становится более привлекательной и может стоить дороже.

Или наоборот: новые условия оказались выгоднее, владелец покупает новую лицензию и продаёт старую.

Проект получает комиссию со сделки.

Владелец получает ликвидный актив.

Покупатель получает полезную функцию.

AMERO получает спрос через блокировку.

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


12.3. Нельзя проверять баланс только в момент действия

Если функция требует просто иметь миллион AMERO на счёте в секунду выполнения операции, условие легко обходится.

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

Поэтому нужны:

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

Каждый AMERO должен обеспечивать конкретное право только один раз.


12.4. Базовое удобство нельзя закрывать лицензиями

Повторю ещё раз, потому что это легко испортить.

За AMERO можно продавать:

  • сложные сценарии;
  • расширенную аналитику;
  • автоматическое принятие решений;
  • интеграции;
  • оптимизацию;
  • профессиональные инструменты.

Но нельзя продавать:

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

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


Часть XII. Продажи товаров за AMERO

13. Эксклюзивные продажи могут создавать спрос

Проект может периодически продавать за AMERO:

  • ограниченные лицензии;
  • декоративные предметы;
  • уникальные права;
  • коллекционные активы;
  • билеты на события;
  • специальные сервисы;
  • расширения аккаунта;
  • ограниченные серии предметов;
  • криптобоксы или наборы.

Но заранее должно быть понятно, что происходит с полученными токенами.

Варианты:

  • сжигание;
  • длительная блокировка;
  • поступление в DAO-казначейство;
  • использование для будущих наград;
  • постепенная продажа по опубликованному графику;
  • формирование резерва;
  • оплата разработчиков с установленными лимитами.

Самый плохой вариант:

  1. Игроки покупают товар за AMERO.
  2. Администрация получает большой объём токенов.
  3. Токены сразу продаются на рынке.
  4. Владельцы AMERO оплачивают снижение цены.

В таком случае полезность превращается в механизм создания дополнительного давления на продажу.


13.1. Казначейство должно действовать по правилам

Для AMERO-казначейства нужна отдельная политика:

  • максимальный объём продажи за период;
  • цели продажи;
  • минимальный срок блокировки;
  • порядок публикации операций;
  • возможность голосования по крупным расходам;
  • отчётность;
  • разделение операционного резерва и пользовательских средств.

Администрация должна иметь возможность финансировать разработку.

Но владельцы токена должны понимать, какой объём потенциально может выйти на рынок.


Часть XIII. Коллективная работа

14. Игроки могут помочь, но им нужны данные

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

Эти знания можно использовать.

Но нельзя просто сказать:

Предлагайте идеи.

Идеи без данных будут строиться на догадках.

Для нормальной работы нужны хотя бы обезличенные показатели:

  • распределение аккаунтов по размеру;
  • количество активных игроков;
  • удержание;
  • приток и отток;
  • основные направления расходов;
  • основные источники доходов;
  • объём ручных действий;
  • наиболее заброшенные механики;
  • количество выполненных операций;
  • причины ухода;
  • количество проданных аккаунтов;
  • средний срок владения;
  • структура токенов;
  • состояние резервов.

Необязательно раскрывать персональные данные.

Но без общей картины невозможно спроектировать экономику.


14.1. Нужна рабочая группа, а не бесконечный форумный спор

Можно собрать небольшую группу:

  • представители администрации;
  • разработчик;
  • экономист проекта;
  • крупные владельцы;
  • средние игроки;
  • новые игроки;
  • вернувшиеся игроки;
  • активные игровые участники;
  • специалист по интерфейсам;
  • представитель держателей AMERO;
  • представитель держателей CLC.

Задача группы — не голосовать за всё подряд.

Она должна:

  1. Описать текущую экономику.
  2. Выделить ключевые проблемы.
  3. Определить ограничения.
  4. Предложить несколько пилотных решений.
  5. Выбрать измеримые показатели.
  6. Запустить эксперимент.
  7. Опубликовать результат.
  8. Скорректировать модель.

Не нужно сразу искать идеальное решение.

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


14.2. Любое обновление должно начинаться с гипотезы

Например:

Мы считаем, что рынок заказов увеличит семидневное удержание новых игроков с X до Y и сократит ручную нагрузку крупных аккаунтов на Z процентов.

Затем запускается ограниченный эксперимент.

После запуска публикуется:

  • сколько человек участвовало;
  • сколько заказов создано;
  • сколько выполнено;
  • сколько отменено;
  • сколько возникло споров;
  • сколько заработали исполнители;
  • сколько заплатили заказчики;
  • какую комиссию получил проект;
  • изменилось ли удержание;
  • возникли ли злоупотребления.

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

Это нормальная разработка продукта.

Неудачный эксперимент не является катастрофой.

Катастрофа — годами поддерживать неработающую механику только потому, что когда-то в неё уже вложили время.


Часть XIV. Что можно сделать уже сейчас

15. Необязательно сразу переписывать всю игру

Полная перестройка экономики займёт много времени и потребует огромного количества решений.

Но существуют шаги, которые можно начать делать раньше.


15.1. Опубликовать карту экономики

Нужна понятная схема:

  • откуда появляется золото;
  • куда оно уходит;
  • откуда формируются фонды;
  • как финансируются выплаты;
  • где используется эмиссия;
  • какие существуют резервы;
  • какие обязательства накоплены;
  • какие токены заблокированы;
  • какие токены могут выйти на рынок.

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


15.2. Принять правила экономических изменений

Зафиксировать:

  • сроки уведомления;
  • переходные периоды;
  • защиту старых активов;
  • порядок компенсации;
  • правила экстренных изменений;
  • обязательность анализа результатов.

Это можно сделать без программирования.


15.3. Выпустить пакет базовой автоматизации

Сначала самые болезненные места:

  • животноводство;
  • птица;
  • поля;
  • ремонты;
  • массовые операции;
  • уведомления;
  • поиск;
  • фильтры;
  • единая панель проблем.

Эта работа не создаст красивого нового блока для рекламного баннера.

Но она резко улучшит жизнь тем, кто уже приносит проекту деньги.


15.4. Запустить один бесплатный игровой маршрут

Не весь новый игровой контур.

Один маршрут.

Например:

  1. Новый игрок получает маленький объект.
  2. Выполняет обучение.
  3. Берёт простой заказ.
  4. Выполняет несколько интерактивных действий.
  5. Получает небольшую оплату.
  6. Может потратить её на развитие.
  7. Видит следующий уровень.

После этого измеряется удержание.


15.5. Запустить один тип заказов

Выбрать механику, где результат легко проверить.

Например, выращивание конкретного ресурса.

Заказчик заранее резервирует оплату.

Исполнитель выполняет заказ.

Проект получает комиссию.

После нескольких месяцев данных станет понятно:

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

15.6. Запустить первую лицензию за удержание AMERO

Не десятки лицензий.

Одну.

Например, расширенную автоматизацию животноводства.

Условия фиксируются.

AMERO блокируются.

Лицензию можно передавать.

Все операции прозрачны.

После этого можно оценить:

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

15.7. Провести первое реальное голосование DAO

Выбрать небольшой, но настоящий вопрос.

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

Заранее объявить:

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

Это даст больше доверия, чем очередное обещание будущего DAO.


Часть XV. Метрики

16. Без измерений невозможно понять, стало ли лучше

Сейчас многие решения оцениваются по количеству сообщений на форуме.

Но форум не представляет всех игроков.

Активно пишут либо наиболее вовлечённые, либо наиболее недовольные.

Поэтому нужны продуктовые показатели.


16.1. Показатели нового игрока

Нужно видеть:

  • сколько людей открыли страницу;
  • сколько зарегистрировались;
  • сколько завершили обучение;
  • сколько выполнили первое действие;
  • сколько вернулись на следующий день;
  • сколько вернулись через неделю;
  • сколько остались через месяц;
  • сколько взяли первый заказ;
  • сколько выполнили заказ;
  • сколько совершили первую покупку;
  • сколько перешли в бизнес-контур.

16.2. Показатели старых игроков

Нужно измерять:

  • сколько активных аккаунтов;
  • сколько вернувшихся;
  • сколько ушедших;
  • среднее время управления аккаунтом;
  • количество ручных операций;
  • использование автоматизации;
  • число выставленных на продажу аккаунтов;
  • число завершённых продаж;
  • причины продажи;
  • срок владения;
  • изменение объёма вложений;
  • удовлетворённость основными механиками.

16.3. Экономические показатели

Минимальный набор:

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

Пока эти цифры не измеряются и не публикуются, любое заявление «обновление оказалось успешным» остаётся мнением.


Часть XVI. Что точно не нужно делать

17. Не нужно снова лечить симптомы

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

17.1. Ещё один новый блок

Новый блок может временно оживить обсуждение.

Но он не исправит:

  • отсутствие доверия;
  • сложный вход;
  • ручное управление;
  • непрозрачную экономику;
  • отсутствие выхода;
  • эмиссионное давление.

17.2. Очередной подарок новичкам

Подарок привлечёт охотников за подарками.

Но не создаст причину остаться.

17.3. Масштабная реклама до исправления удержания

Реклама продукта с низким удержанием просто ускоряет отток и ухудшает репутацию.

17.4. Продажа базового удобства

Нормальный интерфейс не должен быть премиальной функцией.

17.5. Обещание роста токена

Никто не может гарантировать рыночную цену.

Нужно обещать правила, полезность и прозрачность, а не курс.

17.6. Новая эмиссия для закрытия старых обязательств

Это перенос проблемы на держателей токена.

17.7. Ухудшение старых активов ради продажи новых

Такой подход уничтожает доверие ко всем будущим продажам.

17.8. Налог на выход как способ удержания

Удерживать нужно перспективой, а не стоимостью побега.

17.9. Декоративное DAO

Голосование без обязательного результата только сильнее снижает доверие.

17.10. Попытка переделать всё одновременно

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


Часть XVII. Как должна выглядеть итоговая система

18. Интересы всех сторон можно совместить

В работающей модели процесс выглядит примерно так.

Новый игрок бесплатно входит в игровой контур.

Он проходит короткое обучение, выполняет реальные заказы и получает небольшую оплату.

Крупный владелец формирует заказ и оплачивает полезную для себя работу.

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

Базовое управление становится удобным.

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

AMERO получает полезность через управление, лицензии, залоги и специальные сервисы.

Эмиссия и резервы становятся прозрачными.

Старые условия лицензий и активов сохраняются.

Выход через вторичный рынок остаётся доступным.

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

Игрок зарабатывает не потому, что система нарисовала ещё денег, а потому, что другой участник оплатил нужный ему результат.


18.1. Кто что получает

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

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

Крупный владелец получает снижение ручной нагрузки и возможность покупать игровую работу.

Инвестор получает понятные правила, отчётность, ликвидность и защиту собственности.

Держатель AMERO получает реальную полезность, а не только ожидание будущего роста.

Администрация получает комиссии, продажи сервисов, рост оборота и более устойчивый доход.

Сам проект перестаёт зависеть исключительно от постоянного притока новых вложений.


Заключение

Сейчас вопрос стоит не в том, какой новый блок добавить.

Вопрос в архитектуре всего проекта.

Люди идут туда, где:

  • легко начать;
  • интересно действовать;
  • понятны правила;
  • виден результат;
  • можно развиваться;
  • собственность защищена;
  • экономика объяснима;
  • выход не превращён в наказание.

Люди остаются там, где они видят будущее.

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

Нельзя называть ручное нажатие сотен одинаковых кнопок игровым процессом.

Нельзя постоянно создавать ликвидные активы без понятного источника спроса.

Нельзя финансировать старые обязательства бесконечным размыванием новых токенов.

Нельзя сначала поощрять долгосрочное владение, а затем менять условия задним числом.

Нельзя удерживать человека только тем, что выход слишком дорог.

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

Это можно использовать.

Но для этого нужны не очередные временные акции.

Нужны:

  1. правила стабильности;
  2. прозрачная экономика;
  3. базовая автоматизация;
  4. бесплатный игровой контур;
  5. рынок профинансированных заказов;
  6. нормальный вторичный рынок;
  7. ограниченная и понятная эмиссия;
  8. реальная полезность AMERO;
  9. работающее DAO;
  10. измеримые эксперименты.

Я не утверждаю, что предложенная схема является единственно правильной.

Скорее всего, многие детали придётся менять.

Но направление, на мой взгляд, должно быть именно таким:

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

Тогда появится шанс не только удержать тех, кто ещё остался, но и вернуть старых игроков, привлечь новых и наконец полететь в сторону луны.

Хотя для начала неплохо было бы просто перестать копать в сторону центра Земли.

9 Likes

6 и 17 согласен почти во всём. Букаф много, но есть прям очень интересные мысли.

4 Likes

Полностью согласен 6, 17 !!!

Слишком много мест, где хочется поставить лайк… поставлю один, общий, хотя, если честно, не со всеми аспектами первой части согласен.

2 Likes

Дочитал (некоторые места - долистал, не буду скрывать)… попутно вспомнил Николай Василича, с его бессмертными вечерами.
Много полезных и интересных вещей, особенно понравился пункт про игроков, желающих помочь.
НО…
Это страшно ДАЖЕ просто ЧИТАТЬ.
А вопрос: кто будет всем этим заниматься и где брать на это деньги, если, даже простейшие вопросы не находят понимания, отклика и желания (может возможностей - кто знает?) их решать? - отправляет весь этот фолиант в заслуженное место… среди других томов мировой научной фантастики.
В любом случае - спасибо автору! Было интересно.

4 Likes