Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Yan_Shrayber_-_vse_3.docx
Скачиваний:
17
Добавлен:
01.07.2025
Размер:
9 Мб
Скачать
☆

Один последний пример: посчитаем деньги

Если вы и в самом деле пытаетесь заработать денег, продав вашу игру – целиком или же часть ее – то, в конце концов, это и есть одна из ваших главных забот. Есть люди, для которых это самая главная забота: они бы предпочли создать игру, которая хорошо окупается, но при этом совершенно неинтересная, чем потрясающую, интересную и новую игру, которая будет «широко известна в узких кругах» (просто эвфемизм для провалившейся, но не заслуживавшей этого, игры). Другие гейм-дизайнеры предпочли бы сделать игру прежде всего интересной, так что вам нужно решить, с какой вы стороны баррикад… потому что, если вы сами не знаете, однажды кто-то решит за вас.

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

Для игр, что традиционно продаются онлайн или в розницу, это довольно типичная диаграмма: большие объемы продаж в день релиза, которые постепенно уменьшаются по экспоненте, пока продажи не станут настолько маленькими, что смысла продавать игру уже не будет. Если вы разрабатываете онлайн-игру, вам не нужно волноваться о количестве экземпляров, или об объеме места, занимаемого игрой на полках, так что вы можете поработать над ней чуть дольше. Тут-то и становится ясна идея «длинного хвоста” – потому что эта кривая выглядит так, будто у нее есть маленький хвостик справа. В этом случае необходимо опасаться подводных камней, которые иногда появляются, и того, что вызвало их появление – сами по себе такие штуки обычно не происходят.

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

Если же вы выпускаете онлайн-игру, например, ММО, или игру на флэш-портале, или на Фейсбуке, схема может немного отличаться: объем продаж сначала невысок (высок, если вы предварительно поработали над маркетингом), затем, если игра хорошая, он увеличивается по мере работы сарафанного радио, так что, по сути, это та же диаграмма, но немного растянутая по времени. Отличная новость по поводу такого вида релиза: вы можете управлять диаграммой продаж в реальном времени. Внесите изменения в игру сегодня, отмечайте изменения в продажах до конца недели, и продолжайте модифицировать игру по ходу действия. Поскольку у вас пошаговые дополнения, которые как-то влияют на продажи, вы получаете постоянный отклик на малейшие изменения, который выражается в количестве денег, приносимых вашей игрой. Тем не менее, следует помнить, что ваша игра существует не в вакууме: зачастую есть множество внешних факторов, которые могут повлиять на продажи. К примеру, бьюсь об заклад, что, если произошло какое-то крупное стихийное бедствие, о котором трубят газеты по всему миру, у большинства игр на Фейсбуке упадет посещаемость, так как люди будут читать новости. Так что, если игровая компания внесла небольшое изменение в игру накануне разлива нефти в Мексиканском заливе и заметила внезапный спад активности в той области, создатели, если они не следят за реальным миром, могут ошибочно решить, что изменение было плохим.

В идеале вам нужно бы устранить эти факторы, чтобы вы знали, что именно измеряете, контролируя внешние факторы. Один из способов сделать это (который работает не всегда): одновременно предоставить две версии игры разным игрокам, и затем сравнить две группы. Важно, чтобы вы выбирали игроков случайно (и не давали, к примеру, одну версию владельцам давно зарегистрированных аккаунтов, а другую – новым игрокам). Разумеется, если в двух группах сам игровой процесс будет различаться, это неизбежно вызовет гнев некоторых игроков, особенно, если одной из групп достанется несбалансированная версия, которую нужно будет доработать. Так что такое лучше делать с вещами, которые на баланс не повлияют: к примеру, рекламными баннерами, текстами всплывающих информационных диалогов, заставками, цветами или внешним видом иллюстраций в игре, и тому подобными штуками. Или, если уж менять игровой процесс, то так, чтобы это было понятно и очевидно для игроков: например, присоединить случайным образом игрока к какой-либо фракции (как в World of Warcraft при регистрации игрок выбирает сторону – Альянс или Орду, только тут это будет происходить случайно), и заставить их воевать между собой, вплетя этот факт в предысторию игрового мира, так что будет абсолютно естественно, если у двух сторон версии игры будут в чем-то различаться. Не могу привести примеров игр, в которых создатели действительно провернули этот трюк, но было бы интересно на это посмотреть.

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

Во-первых, что такое «игрок»? Если у некоторых пользователей несколько аккаунтов (с вашего разрешения или нет), или если в системе есть старые, «спящие» (неиспользуемые) аккаунты, то, будете ли вы считать их игроками или нет, повлияет на все ваши расчеты. Обычно компании заинтересованы в том, чтобы считать доходы от уникальных активных пользователей, потому как владельцы «спящих» аккаунтов деньги обычно не тратят, а одного пользователя с несколькими аккаунтами нужно считать одним игроком, даже если он вкладывает средства в каждый из своих аккаунтов.

Во-вторых, есть разница между теми игроками, которые играют в вашу игру бесплатно и вообще не собираются ни за что платить, и между теми, кто регулярно тратит деньги в игре. Представьте себе игру, на которой вы зарабатываете очень много денег притом, что платят за нее очень немного людей. Это значит, что вы создали действительно отличную игру, которая хорошо привлекает и удерживает бесплатных игроков и, что, как только пользователей удается убедить тратить деньги, они тратят их, и много. Но одновременно это значит, что у вас проблемы с «заманиванием» — вам сложно заставить игроков заплатить в первый раз. Значит, вам нужно подумать о стимуле, который побудит пользователей заплатить немного (для начала). А теперь представьте другую игру, где большинство игроков платят, но платят немного. Это уже другая проблема, суть которой заключается в том, что ваша платежная система отпугивает игроков, или что вы, как минимум, недостаточно стимулируете их тратить больше денег – вы будто бы достигаете определенного потолка платежей в какой-то точке. Возможно, в итоге вы получаете равное количество денег в обоих случаях, но решать эти задачи нужно по-разному.

Обычно разница между ними обозначается двумя аббревиатурами, которые сейчас у всех на слуху: ARPU (средняя выручка на одного пользователя) и ARPPU (средний доход с одного платящего пользователя). Как по мне, лучше бы их называли игроками, а не пользователями, но не я эти термины придумал.Как бы то ни было, в первом случае, когда меньшинство платит, когда большинство играет бесплатно, ARPPU будет очень высоким, а во втором – очень низким, даже если ARPU одинаково для обоих игр.

Разумеется, общее число игроков тоже необходимо принимать в расчет, а не только считать его средним показателем. Если ваши показатели ARPU и ARPPU очень высоки, но ваша база игроков составляет всего лишь несколько тысяч, хотя должно быть несколько миллионов, тогда, возможно, это проблема маркетинга, а не гейм-дизайна. Это зависит от того, что происходит с вашей базой с течением времени, и от того, где вы находитесь в этом «хвосте» кривой продаж. Так что эти три вещи – продажи, ARPU и ARPPU – могут дать вам необходимую информацию о том, в чем заключается проблема: в представлении игры (то есть предложении попробовать поиграть в нее), заманивании (в том, чтобы заставить заплатить за нее в первый раз) или в удержании (в том, чтобы заставить игроков снова и снова возвращаться к игре).  И, когда вы преодолеете эти проблемы внесенными в игру изменениями и дополнениями, вы неоднократно сможете провести параллели между определенными изменениями в механике игры и возросшими продажами.

Еще стоит обратить внимание на график взаимозависимости времени и денег для среднего пользователя. Сколько люди платят вам в тот день, когда только заводят аккаунт? А что насчет следующего дня, и следующего за ним? Видите – сначала денег очень много, а потом пользователи платят все меньше? Вы видите нисходящую кривую, когда пользователи сначала играют бесплатно, потом платят в первый раз – и много, а потом платят все меньше и меньше, пока не начинают снова играть бесплатно? Или восходящую, когда игроки платят немного, потом – чуть больше, и больше, и тут – бам! – и они вообще перестают играть? Регулярные маленькие выплаты или традиционные модели с «длинным хвостом»? Что это говорит вам о том, насколько вы вознаграждаете постепенный прогресс игроков?

Просматривая информацию о своих доходах, не забудьте о такой статье, как «расходы». Есть две статьи расходов: предоплата за разработку и текущие траты. Первые – это разработки новых функций игры, в число которых входят как «удачные» (т.е. те, которые повышают доход), так и «неудачные», которые вы пробуете применить и затем отказываетесь от них. Вам необходимо помнить, что соотношение удачных-неудачных функций не будет равным, так что вам придется принять некую часть неудачных идей как часть расходов на разработку удачных (это разновидность так называемых «невозвратных издержек», о которых мы говорили на 6 неделе, когда говорили о ситуационном балансе). Текущие расходы – это, например, стоимость трафика, серверов и службы поддержки, и эти расходы имеют обыкновение расти с увеличением числа игроков. Поскольку обычно цель любого бизнеса – это увеличить свою прибыль (то есть заработанные деньги без учета потраченных), а не доходы (то есть просто полученные деньги), вы точно захотите учесть все вышеперечисленное, если вы пытаетесь оптимизировать свои ресурсы разработки.

Небольшое предостережение (ох, кажется, я много таких предостережений раздаю на этой неделе): статистика хороша для анализа прошедших событий, но, если вы пытаетесь предсказать с её помощью будущее, всё намного сложнее. К примеру, у только что выпущенной и очень популярной игры может быть кривая, которая выглядит как поднимающаяся по экспоненте. Так и тянет предположить, особенно, если условия очень подходят под экспоненциальную функцию, что так будет продолжаться и дальше. Но здравый смысл подсказывает, что так вечно продолжаться не может: людей на Земле ограниченное количество, так что, если ваша кривая экспоненциально растет быстрее, чем увеличивается прирост населения, рано или поздно показатели упадут. Кривые роста в деловой сфере обычно не экспоненциальны, они представляют собой так называемые «S-образные» кривые: начинаются они как экспоненциально поднимающиеся кривые, и постепенно переходят в логарифмически (т.е. медленно) поднимающиеся кривые, которые со временем начинают опускаться или выравниваться. Многие инвесторы совершают грубую ошибку, путая S-образную кривую с экспоненциально поднимающейся, пример (более или менее) мы могли наблюдать лет десять назад – пузырь доткомов. Незаконные схемы-пирамиды зачастую тоже проходят через такую кривую, с тем лишь исключением, что, достигая высшей точки “S”, они обычно рушатся.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]