Спасибо, что высказали мнение насчёт деконстракта, обратная это круто!
Сегодня совсем короткий пост про два довольно хардкорных жанра. Обычно подобные продукты это совсем не про мобайл, но у данных есть особенности, которые роднят их с большинством мидкор игр, содержащих гринд. По своей сути они сессионно ориентированы и уже очень давно решают проблему реиграбельности на ограниченных объемах контента.
Для классической roguelike игры характерно наличие процедурно генерируемых уровней и полной потери прогресса при смерти персонажа. Уровень сложности прохождения неизменен, по сути всё, что меняется от сессии к сессии только скилл игрока. Важным недостатком является ощущение потери времени, когда в очередной раз проигрываешь. Для решения проблемы однообразия в enter the gungeon реализована система, когда игрок побеждая боссов может открыть новое оружие, которое с некоторой вероятностью выпадет при последующих прохождениях. На баланс сильно не влияет, поскольку значительно более сильным оно не является и получение носит вероятностный характер. Вторым популярным решением является разблокировка новых персонажей для прохождения. Они также сбалансированы чтобы не быть более сильными, но при этом играться иначе. Третьим решением является выдача скинов, которые вносят разнообразие в визуальный ряд. В Hades реализовали выдачу дополнительного нарратива в качестве награды. В целом их объединяет одно - меняют ощущение от игры, не оказывая влияния на сложность.
Примеры roguelike: enter the gungeon, slay the spire, spelunky, binding of Isaak.
В итоге появились разработчики, которые хотели расширить аудиторию за счёт менее скилловых игроков. Они внесли существенное изменение в ограничения жанра - добавили сохраняемые сущности, как к примеру монеты или опыт, за которые можно было прокачать характеристики персонажа, открыть новые способности и идти в подземелье со значительно большей вероятностью продвинуться дальше. Так каждое прохождение начало иметь значение. Теперь любой игрок независимо от скилла мог рано или поздно победить, за счет снижения сложности, обусловленного ростом характеристик персонажа. Недостатком становится отсутствие обратной связи от роста скилла игрока - невозможно определить победил ты из-за роста навыка или из-за того, что прокачал персонажа. Вторым неоднозначным моментом стала кривая сложности, которая изначально достаточно жесткая, но затем постоянно снижается.
Примеры roguelite: rogue legacy, deadcells.
Больше про механики данных данных жанров расскажу, когда буду описывать режим лабиринта в afk arena.
Источник(англ.): https://www.youtube.com/watch?v=G9FB5R4wVno
Сегодня совсем короткий пост про два довольно хардкорных жанра. Обычно подобные продукты это совсем не про мобайл, но у данных есть особенности, которые роднят их с большинством мидкор игр, содержащих гринд. По своей сути они сессионно ориентированы и уже очень давно решают проблему реиграбельности на ограниченных объемах контента.
Для классической roguelike игры характерно наличие процедурно генерируемых уровней и полной потери прогресса при смерти персонажа. Уровень сложности прохождения неизменен, по сути всё, что меняется от сессии к сессии только скилл игрока. Важным недостатком является ощущение потери времени, когда в очередной раз проигрываешь. Для решения проблемы однообразия в enter the gungeon реализована система, когда игрок побеждая боссов может открыть новое оружие, которое с некоторой вероятностью выпадет при последующих прохождениях. На баланс сильно не влияет, поскольку значительно более сильным оно не является и получение носит вероятностный характер. Вторым популярным решением является разблокировка новых персонажей для прохождения. Они также сбалансированы чтобы не быть более сильными, но при этом играться иначе. Третьим решением является выдача скинов, которые вносят разнообразие в визуальный ряд. В Hades реализовали выдачу дополнительного нарратива в качестве награды. В целом их объединяет одно - меняют ощущение от игры, не оказывая влияния на сложность.
Примеры roguelike: enter the gungeon, slay the spire, spelunky, binding of Isaak.
В итоге появились разработчики, которые хотели расширить аудиторию за счёт менее скилловых игроков. Они внесли существенное изменение в ограничения жанра - добавили сохраняемые сущности, как к примеру монеты или опыт, за которые можно было прокачать характеристики персонажа, открыть новые способности и идти в подземелье со значительно большей вероятностью продвинуться дальше. Так каждое прохождение начало иметь значение. Теперь любой игрок независимо от скилла мог рано или поздно победить, за счет снижения сложности, обусловленного ростом характеристик персонажа. Недостатком становится отсутствие обратной связи от роста скилла игрока - невозможно определить победил ты из-за роста навыка или из-за того, что прокачал персонажа. Вторым неоднозначным моментом стала кривая сложности, которая изначально достаточно жесткая, но затем постоянно снижается.
Примеры roguelite: rogue legacy, deadcells.
Больше про механики данных данных жанров расскажу, когда буду описывать режим лабиринта в afk arena.
Источник(англ.): https://www.youtube.com/watch?v=G9FB5R4wVno
Краткий пересказ доклада с прошедней конференции в google. Александр Барабаш, старший менеджер по продуктам в ZeptoLab и просто очень приятный собеседник, рассказал некоторые кейсы из оперирования игры C.A.T.S. (2 года, 170 млн. установок по всему миру).
Выбирая элементы игры, на которые в первую очередь стоит обратить внимание, есть смысл оптимизировать сложность. Это тот элемент, который оказывает влияние на ретеншн и деньги. У них сложность на старте обычно бывала занижена, всегда стоит проверять повышенную.
Отсутствие необходимости и возможности накопления позволяет сделать экономику игры менее инертной и в целом оздоровить её.
Стартер пак игроки ожидают по примеру других игр. В CATS стартер пак доступен с самого начала в магазине и поднимается игроку, когда тот сталкивается со сложностями. По опыту ребят лучше всего себя показывает оффер на $2. Дороже - падает конверсия, дешевле падает доход.
Лучше всего работает премиум валюта с некоторым добавлением других ресурсов.
Если игрок не берет оффер - перебираем варианты с различными типами ценностей. На всякий случай оставляем стартер пак в магазине.
Некоторые пользователи конвертятся и через 2 месяца.
Стартер пак составляет малую долю в мидкор проекте, поэтому излишняя оптимизация первого оффера ни к чему.
Чтобы игроки не ждали оффера экономя деньги, большинство делается на ресурсы, которые можно моментально потратить. Валюта хоть и продается хорошо, но есть смысл делать по праздникам, чтобы не избаловать аудиторию.
Если информация о предпочтениях игрока для выдачи офферов пока не накопилась, предлагаем достаточно дорогой оффер и если он не взял, предлагаем дешевле. Очень важно, чтобы дешёвый не был более выгодным. Иначе игроки будут ждать более душевых. Как вариант использовать парные акционки.
Потенциальные точки влияния на эффективность работы офферов:
- подбор содержимого по действиям игрока
- выбор момента показа оффера
- эксперименты по позиционированию оффера, к примеру предложить его, как награду за достижение
Показ рекламы составляет достаточно большую часть доходов. Но доход за просмотр рекламы с пользователя становится меньше с каждым просмотром.
Поэтому можно разделить показы и подход к работе с ними на 3 категории:
1й показ. Для первого показа делается специальное предложение, зачастую дающее уникальный контент, который сложно получить в игре, чтобы сконвертить даже тех, кто не любит смотреть. Перенесли рекламу в попап из интерфейса и выросла конверсия.
2-5. Приносят меньшую пользу, поэтому награда за него менее ценная, чтобы не вредить экономике. Чтобы сделать их полезными для игрока предлагается выбор, игрок дожидается, когда будет предложено что-то полезное лично для него и за что он готов смотреть рекламу.
>5. С остальными работа происходит иначе. В игре есть сундуки за таймеры, за рекламу можно ускорить открытие.
Вредит ли реклама инапам? Для их проекта нет влияния ни на платежи, ни на ретеншн, если конечно не отдавать чрезмерно большие объёмы ценностей за рекламу.
Кейсы.
Влияние визуала на эффективность магазина. Пробовали экспериментировать с артом на инапах, с их последовательностью - никакого значимого эффекта.
Ни один конверсионный оффер отличный от $2 не показал лучших результатов.
Эксперименты со скоростью прогресса ни к чему не привели. Игроки проходят дальше за то же время, но соотношение отвалившихся и оставшихся не меняется.
Источник: нет в открытом доступе.
Выбирая элементы игры, на которые в первую очередь стоит обратить внимание, есть смысл оптимизировать сложность. Это тот элемент, который оказывает влияние на ретеншн и деньги. У них сложность на старте обычно бывала занижена, всегда стоит проверять повышенную.
Отсутствие необходимости и возможности накопления позволяет сделать экономику игры менее инертной и в целом оздоровить её.
Стартер пак игроки ожидают по примеру других игр. В CATS стартер пак доступен с самого начала в магазине и поднимается игроку, когда тот сталкивается со сложностями. По опыту ребят лучше всего себя показывает оффер на $2. Дороже - падает конверсия, дешевле падает доход.
Лучше всего работает премиум валюта с некоторым добавлением других ресурсов.
Если игрок не берет оффер - перебираем варианты с различными типами ценностей. На всякий случай оставляем стартер пак в магазине.
Некоторые пользователи конвертятся и через 2 месяца.
Стартер пак составляет малую долю в мидкор проекте, поэтому излишняя оптимизация первого оффера ни к чему.
Чтобы игроки не ждали оффера экономя деньги, большинство делается на ресурсы, которые можно моментально потратить. Валюта хоть и продается хорошо, но есть смысл делать по праздникам, чтобы не избаловать аудиторию.
Если информация о предпочтениях игрока для выдачи офферов пока не накопилась, предлагаем достаточно дорогой оффер и если он не взял, предлагаем дешевле. Очень важно, чтобы дешёвый не был более выгодным. Иначе игроки будут ждать более душевых. Как вариант использовать парные акционки.
Потенциальные точки влияния на эффективность работы офферов:
- подбор содержимого по действиям игрока
- выбор момента показа оффера
- эксперименты по позиционированию оффера, к примеру предложить его, как награду за достижение
Показ рекламы составляет достаточно большую часть доходов. Но доход за просмотр рекламы с пользователя становится меньше с каждым просмотром.
Поэтому можно разделить показы и подход к работе с ними на 3 категории:
1й показ. Для первого показа делается специальное предложение, зачастую дающее уникальный контент, который сложно получить в игре, чтобы сконвертить даже тех, кто не любит смотреть. Перенесли рекламу в попап из интерфейса и выросла конверсия.
2-5. Приносят меньшую пользу, поэтому награда за него менее ценная, чтобы не вредить экономике. Чтобы сделать их полезными для игрока предлагается выбор, игрок дожидается, когда будет предложено что-то полезное лично для него и за что он готов смотреть рекламу.
>5. С остальными работа происходит иначе. В игре есть сундуки за таймеры, за рекламу можно ускорить открытие.
Вредит ли реклама инапам? Для их проекта нет влияния ни на платежи, ни на ретеншн, если конечно не отдавать чрезмерно большие объёмы ценностей за рекламу.
Кейсы.
Влияние визуала на эффективность магазина. Пробовали экспериментировать с артом на инапах, с их последовательностью - никакого значимого эффекта.
Ни один конверсионный оффер отличный от $2 не показал лучших результатов.
Эксперименты со скоростью прогресса ни к чему не привели. Игроки проходят дальше за то же время, но соотношение отвалившихся и оставшихся не меняется.
Источник: нет в открытом доступе.
Сегодняшняя статья не только, да и не столько про игры, сколько про мобильные приложения в целом. Некоторые советы я адаптировал, выбрасывать специально ничего не стал, поскольку это скорее идеи для размышления, чем руководство к действию. Разделил на 2 части, чтобы легче воспринимались.
1. Не рассказывать пользователю о функционалах с помощью экранов при первом запуске - то что ему нужно он уже увидел в сторе и поэтому скачал, остальное отдаляет от того за чем пришел
2. На каждом экране должно легко считываться одно действие, которое ожидается от игрока
3. Используйте положительное подкрепление. Даже добавление простого прогресс бара зачастую оказывает положительное влияние на выполнение цепочки действий
4. Однозначно определите ваши ценности для пользователя и используйте их в push уведомлениях на возврат
5. Выделите одну основную метрику продукта (она может быть производной от других). Определите влияющие на неё метрики и степень их влияния при минимальном изменении. Так вы найдете потенциальные точки роста.
6. Как выглядит идеальный онбординг? Он дает пользователю ту ценность, за которой он пришел
7. Позаботьтесь о пользователях, которые зайдут в момент технических работ и сбоев
8. Если есть функционал регистрации и логина, то акцент на экране должен быть именно на регистрации, пользователи значительно реже разлогиниваются
9. Не используйте больше двух вариантов регистрации. Больше вариантов вызывают сложности выбора у пользователя
10. Каждый экран должен выглядеть отлично при поднятой клавиатуре, если там возможно её вызвать.
11. Работайте над текстами сообщений об ошибках, они должны быть однозначны и не отпугивать далеких от техники пользователей
12. Тестируйте наиболее рискованные гипотезы, внося заметные изменения в продукт
13. Анализируйте действия наиболее успешных пользователей и направляйте сессии других игроков по тому же пути
14. Разделяйте пользователей на когорты. Некоторым пользователям не нужен туториал
15. Сместите из туториала в первой сессии всё, что можно перенести во вторую. Это сделает геймплей более гладким
16. Проанализируйте поведение пользователей в первую сессию. Возможно окажется, что есть критерии, по которым можно выделить потенциальных плательщиков
17. Всё, что не направлено на получение игроком удовольствия от геймплея, за которым он пришел, вредит онбордингу. Стоит очистить первую сессию от просьб поделиться с друзьями и навязчивых офферов
18. Стоит ориентироваться на на действия, совершенные пользователем, а не на время, проведенное в продукте, когда обращаетесь к пользователю (push, email, etc)
19. Полезно предоставить пользователю моментальную ценность при первом входе в продукт, это может быть эпизод кор геймплея с интересными механиками или что-то ещё, выполнение чего позволит игроку почувствовать уверенность в своих силах в вашей игре
20. Для удобства онбординг можно разделить на 3 фазы:
- До. Регистрация и логин
- Во время. Сам онбординг во время первой сессии
- После. То как пользователь будет разбираться в новых функционалах
21. Не рассказывать, показывать в действовии
22. Планировать исходя не от продукта, а от ожиданий игрока
23. Пост-онбординг в следующих сессиях - рекомендации и предложения игроку
24. Давайте пользователю понять общую длину онбординга, к примеру с помощью прогресс-бара
25. Положительное подкрепление за достижения, в том числе и визуальное
26. Вводить новые функционалы без ущерба тем, которые пользователь уже освоил
27. Стоит спрашивать себя, нужно ли это пользователю в данный момент на данном этапе. Если нет - отсекать
28. Актуальные задачи в онбординге вместо инструкций и подсказок
29. Награждение пользователя за достижения в онбординге поможет игроку ознакомиться с механиками сундуков с таймерами, гача и прочих непрямых способов доставки ценностей до игрока
30. Для объяснения сложных функционалов стоит использовать видео, вместо текстовых подсказок
Источник (англ.): https://medium.com/@andreibaklinau/the-best-67-mobile-onboarding-tips-that-i-have-found-on-the-internet-21c439a5a3ab
1. Не рассказывать пользователю о функционалах с помощью экранов при первом запуске - то что ему нужно он уже увидел в сторе и поэтому скачал, остальное отдаляет от того за чем пришел
2. На каждом экране должно легко считываться одно действие, которое ожидается от игрока
3. Используйте положительное подкрепление. Даже добавление простого прогресс бара зачастую оказывает положительное влияние на выполнение цепочки действий
4. Однозначно определите ваши ценности для пользователя и используйте их в push уведомлениях на возврат
5. Выделите одну основную метрику продукта (она может быть производной от других). Определите влияющие на неё метрики и степень их влияния при минимальном изменении. Так вы найдете потенциальные точки роста.
6. Как выглядит идеальный онбординг? Он дает пользователю ту ценность, за которой он пришел
7. Позаботьтесь о пользователях, которые зайдут в момент технических работ и сбоев
8. Если есть функционал регистрации и логина, то акцент на экране должен быть именно на регистрации, пользователи значительно реже разлогиниваются
9. Не используйте больше двух вариантов регистрации. Больше вариантов вызывают сложности выбора у пользователя
10. Каждый экран должен выглядеть отлично при поднятой клавиатуре, если там возможно её вызвать.
11. Работайте над текстами сообщений об ошибках, они должны быть однозначны и не отпугивать далеких от техники пользователей
12. Тестируйте наиболее рискованные гипотезы, внося заметные изменения в продукт
13. Анализируйте действия наиболее успешных пользователей и направляйте сессии других игроков по тому же пути
14. Разделяйте пользователей на когорты. Некоторым пользователям не нужен туториал
15. Сместите из туториала в первой сессии всё, что можно перенести во вторую. Это сделает геймплей более гладким
16. Проанализируйте поведение пользователей в первую сессию. Возможно окажется, что есть критерии, по которым можно выделить потенциальных плательщиков
17. Всё, что не направлено на получение игроком удовольствия от геймплея, за которым он пришел, вредит онбордингу. Стоит очистить первую сессию от просьб поделиться с друзьями и навязчивых офферов
18. Стоит ориентироваться на на действия, совершенные пользователем, а не на время, проведенное в продукте, когда обращаетесь к пользователю (push, email, etc)
19. Полезно предоставить пользователю моментальную ценность при первом входе в продукт, это может быть эпизод кор геймплея с интересными механиками или что-то ещё, выполнение чего позволит игроку почувствовать уверенность в своих силах в вашей игре
20. Для удобства онбординг можно разделить на 3 фазы:
- До. Регистрация и логин
- Во время. Сам онбординг во время первой сессии
- После. То как пользователь будет разбираться в новых функционалах
21. Не рассказывать, показывать в действовии
22. Планировать исходя не от продукта, а от ожиданий игрока
23. Пост-онбординг в следующих сессиях - рекомендации и предложения игроку
24. Давайте пользователю понять общую длину онбординга, к примеру с помощью прогресс-бара
25. Положительное подкрепление за достижения, в том числе и визуальное
26. Вводить новые функционалы без ущерба тем, которые пользователь уже освоил
27. Стоит спрашивать себя, нужно ли это пользователю в данный момент на данном этапе. Если нет - отсекать
28. Актуальные задачи в онбординге вместо инструкций и подсказок
29. Награждение пользователя за достижения в онбординге поможет игроку ознакомиться с механиками сундуков с таймерами, гача и прочих непрямых способов доставки ценностей до игрока
30. Для объяснения сложных функционалов стоит использовать видео, вместо текстовых подсказок
Источник (англ.): https://medium.com/@andreibaklinau/the-best-67-mobile-onboarding-tips-that-i-have-found-on-the-internet-21c439a5a3ab
Сегодня совмещенный пост из продолжения советов по онбордингу и немного из перевода статьи с деконстрактора, который запилил на днях на dtf.
31. Используйте все доступные каналы ивязи с пользователем (пуши, сообщения внутри игры, соц. сети)
32. Пока количество данных недостаточно, чтобы делать выводы, постарайтесь связаться с каждым пользователем, с которым сможете и получить информацию от них
34. Прогрессбар должен начинаться с заполненного значения
35. Акцентируйте внимание пользователя на тех же моментах, которыми сконвертили его в установку из стора. В первое время в игре он растерян и испытывает сомнения туда ли попал.
36. Не используйте более 3х вариантов, большее количество вызовет проблемы выбора у части пользователей
37. Когда делаете новости (рассылка, внутриигровое окно - не важно) всегда используйте иллюстрации
38. Пэйволы стоит размещать так, чтобы не вызывать агрессию пользователей (на мой взгляд банально для части продуктов, не верно для другой части)
39. Откажитесь от сложной авторизации пользователя на старте, задача показать ему ценность игры, а не узнать его логин
40. Постепенно увеличивайте сложность, чтобы сложные механики, которые изначально необязательны, становились в последтвии необходимы пользователю
41. Напоминайте пользователях о незаконченных делах, это может помочь вернуть его в игру
42. Всегда дробите онбординг на шаги, чтобы легко можно было построить воронку и понять где проблема
43. Создавайте дополнительные каналы связи с пользователем, совет был не про игры, но для игр тоже имеет место. Каждый новый метод нотификации дает вам шанс вернуть пользователя, зачастую кита, или как минимум даст возможность в случае необходимости получить трафик, о котором у вас есть некоторые сведения
44. Запрашивая информацию у пользователя указывайте причину, людям свойственно не хотеть отвечать на необоснованный вопрос
45. Откажитесь от создания пароля пользователя в первой сессии. Совет скорее для больших mmo, если вы уже запросили email, то можно дать пользователю играть с ним, а в момент, когда ясно, что пользователь остается, запросить его
46. Тем же образом стоит изабвить от всего, что может отвлечь пользователя.
47, 54, 55 - дублируют прошлые пунты
48. Сделайте обучение пользователя контекстным и показывайте информацию там, где она может быть использована, иначе он скорее всего забудет
49. Обещайте дать игрокам то, что их взволнует и заставит вернуться за этим в игру
50. Создавайте привычку у пользователя за счет повторения рутинных действий
51. Не объясняйте пользователям очевидные вещи, это вызывает скуку и негатив
52. Не злоупотребляйте видеообъяснениями, не смотря на один из прошлых советов. Они отнимают время у игрока и сравнительно дороги в производстве и поддержании актуальности. По возможности не делайте функционалы так, чтобы они требовали подобных объяснений
53. Если есть необходимость поставить перед пользователем сложную задачу на онбординге - указывайте время, которое она займет и прогресс выполнения.
56. В играх удовольствие пользователя во многом зависит от него самого, а не только от игры. Поэтому изучайте, сегментируйте, ищите индивидуальный подход к каждому типу игрока
57. Давайте эмоциональную окраску функциональному онбордингу. Данный пункт отчасти дублирует пункт про необходимость положительного подкрепления.
58. После завершения онбординга его роль отчасти берет на себя саппорт
59. Текстовки должны быть максимально простые и открытые, как если бы общались с другом
60. Запрашивать информацию у пользователя, а также пермишны для приложения лучше небольшими порциями и постепенно
62. Быстрый прогресс вначале, рост на несколько уровней за пару минут, потом на аналогичный рост могу потребоваться недели и больше
63. Кастомизируйте настройки под пользователя, если у вас есть какая-либо информация о нём. К примеру предпочтительные цветовые схемы в зависимости от региона мира и т.д.
64. Используйте логин через соц. сети
66. Не заставляйте игрока ждать, развлекайте во время ожидания
31. Используйте все доступные каналы ивязи с пользователем (пуши, сообщения внутри игры, соц. сети)
32. Пока количество данных недостаточно, чтобы делать выводы, постарайтесь связаться с каждым пользователем, с которым сможете и получить информацию от них
34. Прогрессбар должен начинаться с заполненного значения
35. Акцентируйте внимание пользователя на тех же моментах, которыми сконвертили его в установку из стора. В первое время в игре он растерян и испытывает сомнения туда ли попал.
36. Не используйте более 3х вариантов, большее количество вызовет проблемы выбора у части пользователей
37. Когда делаете новости (рассылка, внутриигровое окно - не важно) всегда используйте иллюстрации
38. Пэйволы стоит размещать так, чтобы не вызывать агрессию пользователей (на мой взгляд банально для части продуктов, не верно для другой части)
39. Откажитесь от сложной авторизации пользователя на старте, задача показать ему ценность игры, а не узнать его логин
40. Постепенно увеличивайте сложность, чтобы сложные механики, которые изначально необязательны, становились в последтвии необходимы пользователю
41. Напоминайте пользователях о незаконченных делах, это может помочь вернуть его в игру
42. Всегда дробите онбординг на шаги, чтобы легко можно было построить воронку и понять где проблема
43. Создавайте дополнительные каналы связи с пользователем, совет был не про игры, но для игр тоже имеет место. Каждый новый метод нотификации дает вам шанс вернуть пользователя, зачастую кита, или как минимум даст возможность в случае необходимости получить трафик, о котором у вас есть некоторые сведения
44. Запрашивая информацию у пользователя указывайте причину, людям свойственно не хотеть отвечать на необоснованный вопрос
45. Откажитесь от создания пароля пользователя в первой сессии. Совет скорее для больших mmo, если вы уже запросили email, то можно дать пользователю играть с ним, а в момент, когда ясно, что пользователь остается, запросить его
46. Тем же образом стоит изабвить от всего, что может отвлечь пользователя.
47, 54, 55 - дублируют прошлые пунты
48. Сделайте обучение пользователя контекстным и показывайте информацию там, где она может быть использована, иначе он скорее всего забудет
49. Обещайте дать игрокам то, что их взволнует и заставит вернуться за этим в игру
50. Создавайте привычку у пользователя за счет повторения рутинных действий
51. Не объясняйте пользователям очевидные вещи, это вызывает скуку и негатив
52. Не злоупотребляйте видеообъяснениями, не смотря на один из прошлых советов. Они отнимают время у игрока и сравнительно дороги в производстве и поддержании актуальности. По возможности не делайте функционалы так, чтобы они требовали подобных объяснений
53. Если есть необходимость поставить перед пользователем сложную задачу на онбординге - указывайте время, которое она займет и прогресс выполнения.
56. В играх удовольствие пользователя во многом зависит от него самого, а не только от игры. Поэтому изучайте, сегментируйте, ищите индивидуальный подход к каждому типу игрока
57. Давайте эмоциональную окраску функциональному онбордингу. Данный пункт отчасти дублирует пункт про необходимость положительного подкрепления.
58. После завершения онбординга его роль отчасти берет на себя саппорт
59. Текстовки должны быть максимально простые и открытые, как если бы общались с другом
60. Запрашивать информацию у пользователя, а также пермишны для приложения лучше небольшими порциями и постепенно
62. Быстрый прогресс вначале, рост на несколько уровней за пару минут, потом на аналогичный рост могу потребоваться недели и больше
63. Кастомизируйте настройки под пользователя, если у вас есть какая-либо информация о нём. К примеру предпочтительные цветовые схемы в зависимости от региона мира и т.д.
64. Используйте логин через соц. сети
66. Не заставляйте игрока ждать, развлекайте во время ожидания
67. При изменении данных подчеркивайте источник откуда они. К примеру пользователь получил монеты из сундука, пусть они летят именно из сундука, а не просто крутится счетчик.
Источник (англ.): https://medium.com/@andreibaklinau/the-best-67-mobile-onboarding-tips-that-i-have-found-on-the-internet-21c439a5a3ab
Выжимка из деконстракта.
- Matchington Mansion единственный home/gardenscapes-like match3 сравнившийся по объемам выручки и аудитории с оригиналом
- Есть теория, что компания разработчик - Firecraft studio - фиктивная, а настоящий создатель крупный медиатор рекламы Applovin
- Запускались чуть позже Homescapes, долгое время не могли расти, пока не нашли креативы, которые позволили им дешево лить трафик
- В первом квартале года Playrix, защищая свои позиции на рынке, развязал войну за внимание потенциальных пользователей, взвинтив стоимость привлечения настолько, что многие компании (GLU mobile в т.ч.) больше не могли закупать траффик
- Уровни в MM чаще строятся по принципу много бустов, большой уровень механик блокеров, чем в HS. Там чаще используют уровни, в которых нужна определенная стратегия для победы, за счет конфигурации уровня
- В мете отличие в большем количестве вариатнов декоров, возможности получать новые варианты у друзей и платной замене декоров
- Нарратив MM имеет более ярко выраженный конфликт и романтическую линию, что ориентировано на ЦА
- Подход к ивентам также отличается, в HS добавили соревновательные механики в то время, как в MM сделали упор на отдельные локации и классический геймплей
Источник: https://dtf.ru/gamedev/55759-protivostoyanie-matchington-mansion-i-homescapes-dekonstrakt-otlichiy
P.S.
Насчет следующих материалов - напишите в личку какие доклады с последней White Nighs интересуют, по возможности сделаю по ним посты.
Источник (англ.): https://medium.com/@andreibaklinau/the-best-67-mobile-onboarding-tips-that-i-have-found-on-the-internet-21c439a5a3ab
Выжимка из деконстракта.
- Matchington Mansion единственный home/gardenscapes-like match3 сравнившийся по объемам выручки и аудитории с оригиналом
- Есть теория, что компания разработчик - Firecraft studio - фиктивная, а настоящий создатель крупный медиатор рекламы Applovin
- Запускались чуть позже Homescapes, долгое время не могли расти, пока не нашли креативы, которые позволили им дешево лить трафик
- В первом квартале года Playrix, защищая свои позиции на рынке, развязал войну за внимание потенциальных пользователей, взвинтив стоимость привлечения настолько, что многие компании (GLU mobile в т.ч.) больше не могли закупать траффик
- Уровни в MM чаще строятся по принципу много бустов, большой уровень механик блокеров, чем в HS. Там чаще используют уровни, в которых нужна определенная стратегия для победы, за счет конфигурации уровня
- В мете отличие в большем количестве вариатнов декоров, возможности получать новые варианты у друзей и платной замене декоров
- Нарратив MM имеет более ярко выраженный конфликт и романтическую линию, что ориентировано на ЦА
- Подход к ивентам также отличается, в HS добавили соревновательные механики в то время, как в MM сделали упор на отдельные локации и классический геймплей
Источник: https://dtf.ru/gamedev/55759-protivostoyanie-matchington-mansion-i-homescapes-dekonstrakt-otlichiy
P.S.
Насчет следующих материалов - напишите в личку какие доклады с последней White Nighs интересуют, по возможности сделаю по ним посты.
Сегодняшний пост будет посвящен конференции, недавно проведенной гуглом. Ребята сказали, что заинтересованы в Российском сегменте игрового рынка, на данный момент он самый прибыльный из стран восточной Европы и демонстрирует весьма успешный рост по установкам - 1.9 млрд (+7% за год), платежам $254 млн(+33%). Для сравнения приложения скачали 2.2 млрд раз и заплатили $42 млн.
Одним из важнейших аспектов успеха игры является её качество, о нём и пойдет речь. 42% пользователей, оставивших отзыв на 1 звезду жалуются на проблемы со стабильностю приложения. 73% из поставивших 5 звезд хвалят скорость работы, дизайн и удобство. Качество оказывает серьезное влияние на бизнес-метрики игры.
Основные параметры (всего 15), примеры:
- Частота падений
- Частота ANR ошибок
- Медленная загрузка
- Большое потрбление ресурсов в т.ч. энергии
- Отказы в разрешениях от пользователя
Работать с ними позволяет Android Vitals. На старте нужно обратить внимание на ключевые показатели в соответствующем разделе google developer console и попробовать исправить наи более критичные ошибки. Для улучшения работы с качеством приложения на этапе оперирования ребята добавили функционал, который позволяет сравнить свои показатели с конкурентами Vitals->Overview->View details->Edit peer group. Также рекомендуется настроить почтовые оповещения при обнаружении аномалий.
Рекомендуют привлекать всех членов команды к контролю качества, это дает хороший результат.
Политика ревью приложений при заливке в стор.
Решения принимаются людьми, сейчас максимально обращают внимание на:
- Нарушение авторских прав
- Схожесть до степени смешения с другими брендами как на уровне лого и арта игры, так в названии компании.
- Нарушение законодательства (в т.ч. неприкрытое пиратство)
- Злоупотребление рекламой, принудительный показ её пользователю в неожиданных местах без соответствующих символов. Особенно ревностно относятся к рекламе в детских приложениях.
- Сексуальный контент (включая позы, игрушки, эскорт услуги), в т.ч. в рекламе и контенте, созданном пользователями
Пре-регистрация.
Также ребята акцентировали внимание на появившемся функционале пре-регистраций. По сути это способ собрать контакты пользователей на этапе перед запуском, чтобы в момент запуска игры play market разослал им уведомления о доступности игры. Стоит пообещать награду за пререгистрацию.
Плюсы:
- Высокая конверсия в установку (38%).
- Более высокие показатели ретеншна на запуске.
Инстант.
Возможность опробовать геймплей игры без установки. Нужно выделить самую затягивающую часть геймплея и сделать из неё билд менее 10мб размером. Потенциально очень сильный маркетинговый инструмент, в показанных кейсах прирост утсановок составил от 6 до 30%.
Дистрибуция через App bundle.
Новая архитектура дистрибуции, направленная на решение проблемы с большим парком девайсов и сложностью региональной дистрибуции. По сути заливается специального формата бандл, из которого play market собирает под девайс пользователя билд минимального размера. Также данная система позволяет производить обновление приложения на уровне инфраструктуры гугла, что не дают классические CDN. Это отдельная тема, которая требует более серьезного изучения на собственном опыте. Когда будет - расскажу.
Источник: нет в открытом доступе, отчасти блог google.
Одним из важнейших аспектов успеха игры является её качество, о нём и пойдет речь. 42% пользователей, оставивших отзыв на 1 звезду жалуются на проблемы со стабильностю приложения. 73% из поставивших 5 звезд хвалят скорость работы, дизайн и удобство. Качество оказывает серьезное влияние на бизнес-метрики игры.
Основные параметры (всего 15), примеры:
- Частота падений
- Частота ANR ошибок
- Медленная загрузка
- Большое потрбление ресурсов в т.ч. энергии
- Отказы в разрешениях от пользователя
Работать с ними позволяет Android Vitals. На старте нужно обратить внимание на ключевые показатели в соответствующем разделе google developer console и попробовать исправить наи более критичные ошибки. Для улучшения работы с качеством приложения на этапе оперирования ребята добавили функционал, который позволяет сравнить свои показатели с конкурентами Vitals->Overview->View details->Edit peer group. Также рекомендуется настроить почтовые оповещения при обнаружении аномалий.
Рекомендуют привлекать всех членов команды к контролю качества, это дает хороший результат.
Политика ревью приложений при заливке в стор.
Решения принимаются людьми, сейчас максимально обращают внимание на:
- Нарушение авторских прав
- Схожесть до степени смешения с другими брендами как на уровне лого и арта игры, так в названии компании.
- Нарушение законодательства (в т.ч. неприкрытое пиратство)
- Злоупотребление рекламой, принудительный показ её пользователю в неожиданных местах без соответствующих символов. Особенно ревностно относятся к рекламе в детских приложениях.
- Сексуальный контент (включая позы, игрушки, эскорт услуги), в т.ч. в рекламе и контенте, созданном пользователями
Пре-регистрация.
Также ребята акцентировали внимание на появившемся функционале пре-регистраций. По сути это способ собрать контакты пользователей на этапе перед запуском, чтобы в момент запуска игры play market разослал им уведомления о доступности игры. Стоит пообещать награду за пререгистрацию.
Плюсы:
- Высокая конверсия в установку (38%).
- Более высокие показатели ретеншна на запуске.
Инстант.
Возможность опробовать геймплей игры без установки. Нужно выделить самую затягивающую часть геймплея и сделать из неё билд менее 10мб размером. Потенциально очень сильный маркетинговый инструмент, в показанных кейсах прирост утсановок составил от 6 до 30%.
Дистрибуция через App bundle.
Новая архитектура дистрибуции, направленная на решение проблемы с большим парком девайсов и сложностью региональной дистрибуции. По сути заливается специального формата бандл, из которого play market собирает под девайс пользователя билд минимального размера. Также данная система позволяет производить обновление приложения на уровне инфраструктуры гугла, что не дают классические CDN. Это отдельная тема, которая требует более серьезного изучения на собственном опыте. Когда будет - расскажу.
Источник: нет в открытом доступе, отчасти блог google.
Получился небольшой перерыв в постах - софтлончу игру, со всеми сопутствующими крутыми штуками типа рабочего дня на 12-16 часов, за что я так люблю геймдев. Но вот наконец выкроил время и вот пост с GDC про Brawl Stars. Последний запустившийся проект от компании supercell обладает непростой судьбой. Изначально он показал не лучшие метрики и компании выпускающие проекты-хиты обычно убивают подобные проекты. Но проведя более года в софтлонче игра всё-таки сумела стать успешной.
Работа на прототипом началась еще до выхода clash royale и 15.06.2017 вышли на ios в Канаде. Основные причины, помимо сходства канадского рынка со штатовским - возможность сравнить с показателями софтлончей прошлых проектов, более простой матчмейкинг для людей из одного региона. На IOS остановились потому, что легче оперировать одной платформой и в отличие от гугловых apk, приложения в экосистеме ios медленнее распространяются по миру. В бете они провели 545 дней.
Очень важным моментом в разработке всех их проектов было управление. Хотелось добиться максимального удобства взаимодействия. Сразу отбросили классическую схему для шутеров с двумя джойстиками. В первом прототипе игроки перемещались по тапу в область экрана, по пути стреляя в цели. Темп игры получился медленный и геймплей был довольно скучным.
Юзертест показал, что это по-прежнему создавало сложности для игроков. Пальцы закрывали весь экран. Но поместив в комнату 3х человек исследователи заметили, что игроки всё равно наслаждаются игрой, хоть и страдают от управления.
В итоге решили выбрать между двух вариантов, с перемещением по тапу и с виртуальным джойстиком. Заказли исследование на основе playable у независимой компании - им не удалось выявить победителя. Тем же окончился тест на игроках - возвраты были равными.
Пытаясь решить проблему управления они пришли к ландшафтному режиму и использованию двух джойстиков. Раньше использовать 2 джойстика было невозможно из-за портретной ориентации. Пришлось переучивать игроков.
Системе апгрейдов отводилась основная роль в прогрессе игрока в мете. Изначально реализовали систему по типу rpg, когда есть очки развития, которые можно инвестировать в статы: здоровье, атака и супер атаку. Они сделали незначительным разброс между максимальной и минимальной прокачкой всего 25%, чтобы не сломать баланс. В clash royale разброс порядка 200%.
Матчмейкинг компенсировал остальное. Ожидаемый эффект получен, пользователи не жаловались на pay to win. Все ценности поместили в лутбоксы. Ресурс для прокачки - эликсир. Каждый раз, когда вместо дупликата легендарного героя выпадало немного элексира игроки изрядно огорчались.
Решили сделать другую систему прогресса. К этому моменту игра находились уже 6 месяцев в бете, каждое изменение отпугивало часть игроков. Вместо элексира сделали уникальные ресурсы для каждого персонажа (значки, медали и т.д ), которые можно было вкалдывать в навыки. Для полностью прокаченных персонажей добавили звездность, которая влияла на персонажа, к примеру у одного из персонажей большой эффект на геймплей начинала оказывать способность замедления суператакой. Это все усложнило баланс для ГД и понимание для игроков. Поскольку визуально нельзя было определить есть ли определенный эффект у персонажа противника или нет. Но долгосрочный ретеншн начал расти.
Прошло ещё 3 месяца (в софтлонче уже 9) и они вновь решили изменить систему прогресса игрока. Чем явно не обрадовали игроков. Решили взять систему clash royale с карточками персонажей и монетами.
Теперь игрок не выбирал в какой именно параметр вложить ресурс прокачки героя, было просто 10 уровней прокачки. Разница между уровнями была сделана значительной, чтобы ощущалась игроком. Разброс между новым персонажем и вкаченным до конца увеличили до 40%.
Обновленный интерфейс стал гораздо приятнее, решил проблему непонимания игроками сущностей звезд, медалей и значков. Но метрики все равно не улучшились.
Работа на прототипом началась еще до выхода clash royale и 15.06.2017 вышли на ios в Канаде. Основные причины, помимо сходства канадского рынка со штатовским - возможность сравнить с показателями софтлончей прошлых проектов, более простой матчмейкинг для людей из одного региона. На IOS остановились потому, что легче оперировать одной платформой и в отличие от гугловых apk, приложения в экосистеме ios медленнее распространяются по миру. В бете они провели 545 дней.
Очень важным моментом в разработке всех их проектов было управление. Хотелось добиться максимального удобства взаимодействия. Сразу отбросили классическую схему для шутеров с двумя джойстиками. В первом прототипе игроки перемещались по тапу в область экрана, по пути стреляя в цели. Темп игры получился медленный и геймплей был довольно скучным.
Юзертест показал, что это по-прежнему создавало сложности для игроков. Пальцы закрывали весь экран. Но поместив в комнату 3х человек исследователи заметили, что игроки всё равно наслаждаются игрой, хоть и страдают от управления.
В итоге решили выбрать между двух вариантов, с перемещением по тапу и с виртуальным джойстиком. Заказли исследование на основе playable у независимой компании - им не удалось выявить победителя. Тем же окончился тест на игроках - возвраты были равными.
Пытаясь решить проблему управления они пришли к ландшафтному режиму и использованию двух джойстиков. Раньше использовать 2 джойстика было невозможно из-за портретной ориентации. Пришлось переучивать игроков.
Системе апгрейдов отводилась основная роль в прогрессе игрока в мете. Изначально реализовали систему по типу rpg, когда есть очки развития, которые можно инвестировать в статы: здоровье, атака и супер атаку. Они сделали незначительным разброс между максимальной и минимальной прокачкой всего 25%, чтобы не сломать баланс. В clash royale разброс порядка 200%.
Матчмейкинг компенсировал остальное. Ожидаемый эффект получен, пользователи не жаловались на pay to win. Все ценности поместили в лутбоксы. Ресурс для прокачки - эликсир. Каждый раз, когда вместо дупликата легендарного героя выпадало немного элексира игроки изрядно огорчались.
Решили сделать другую систему прогресса. К этому моменту игра находились уже 6 месяцев в бете, каждое изменение отпугивало часть игроков. Вместо элексира сделали уникальные ресурсы для каждого персонажа (значки, медали и т.д ), которые можно было вкалдывать в навыки. Для полностью прокаченных персонажей добавили звездность, которая влияла на персонажа, к примеру у одного из персонажей большой эффект на геймплей начинала оказывать способность замедления суператакой. Это все усложнило баланс для ГД и понимание для игроков. Поскольку визуально нельзя было определить есть ли определенный эффект у персонажа противника или нет. Но долгосрочный ретеншн начал расти.
Прошло ещё 3 месяца (в софтлонче уже 9) и они вновь решили изменить систему прогресса игрока. Чем явно не обрадовали игроков. Решили взять систему clash royale с карточками персонажей и монетами.
Теперь игрок не выбирал в какой именно параметр вложить ресурс прокачки героя, было просто 10 уровней прокачки. Разница между уровнями была сделана значительной, чтобы ощущалась игроком. Разброс между новым персонажем и вкаченным до конца увеличили до 40%.
Обновленный интерфейс стал гораздо приятнее, решил проблему непонимания игроками сущностей звезд, медалей и значков. Но метрики все равно не улучшились.
За этот год в бете они игнорировали очень важный момент, который поняли уже давно - максимум в brawl stars хорошо играть с друзьями, в компании. Это создает лучший геймплей, вырабатывает привычку у игроков заходить вместе и в итоге дает очень высокие показатели ретеншна. Но есть большие сложности с тем, чтобы собрать достаточное количество друзей, поэтому был реализованы кланы (назвали их тогда Bands), чтобы создать замену друзей в реальном мире.
В игре не было списков друзей, так что сыграв удачную партию со случайными людьми не было никакой возможности связаться с ними и играть вместе дальше. Фундаментальное решение стартовать только на ios начинало выходить боком, поскольку игроки не могли позвать друзей, играющих на android девайсах, а это урезанная виральность и ограниченный рост.
Комьюнити.
Они начали создавать комьюнити на реддите, оптравив туда часть людей из беты с помощью новостных постов. Помимо этого он стал точкой агрегации пожеланий, жалоб и фан арта.
Все шло не слишком гладко, пришлось возвращать все покупки при каждом обновлении, касавшемся изменения система прогресса. но даже это не искореняло негатив. Измение управления вызывало еще больший отток игроков. Игроки жаловались на отсутствие контентных дополнений.
В момент релиза контентных дополнений (к примеру новый персонаж) - метрики выростали. В дополнение ко всему новые игроки в игре периодически переходили по ссылке в группу и видели горы негатива, что также не способствовало росту метрик.
В мае 2018 они поняли, что все их действия не приносит значительного результата по метрикам и в итоге решили сосредоточиться на создании контента(персонажи и режимы), упрощении игры с друзьями и улучшении экономики, прогрессии наград. Вместо награды за гринд сделали наглядную линейку наград без лутбоксов. Они добавили возможность играть снова в том же составе с незнакомцами, добавили их в рекомендации в списке друзей. Запустившись на андроиде получили органический рост на обеих платформах.
Его выводы:
- не бойтесь инноваций и изменений
- при этом не стоит опасаться вернуться к популярным более удачным решениям
- на пользователей в бете большое влияние оказывает регулярность обновлений
- улучшайте то, что и так доставляет основное удовольствие в игре
Ребята считают, что если бы они раньше занялись социальными механиками, то как минимум гораздо раньше поняли, что игра зайдет.
Q&A:
- Отказались от удвоения лутбоксов за рекламу.
- Выход на Азию дал новых игроков и скачок в росте.
- Принимают решение о том стоит ли софтлончить или нет проконсультировавшись с командой и проведя внутренние плейтесты
Источник (англ., 1 час): https://youtu.be/VSVAmf5LCuo
В игре не было списков друзей, так что сыграв удачную партию со случайными людьми не было никакой возможности связаться с ними и играть вместе дальше. Фундаментальное решение стартовать только на ios начинало выходить боком, поскольку игроки не могли позвать друзей, играющих на android девайсах, а это урезанная виральность и ограниченный рост.
Комьюнити.
Они начали создавать комьюнити на реддите, оптравив туда часть людей из беты с помощью новостных постов. Помимо этого он стал точкой агрегации пожеланий, жалоб и фан арта.
Все шло не слишком гладко, пришлось возвращать все покупки при каждом обновлении, касавшемся изменения система прогресса. но даже это не искореняло негатив. Измение управления вызывало еще больший отток игроков. Игроки жаловались на отсутствие контентных дополнений.
В момент релиза контентных дополнений (к примеру новый персонаж) - метрики выростали. В дополнение ко всему новые игроки в игре периодически переходили по ссылке в группу и видели горы негатива, что также не способствовало росту метрик.
В мае 2018 они поняли, что все их действия не приносит значительного результата по метрикам и в итоге решили сосредоточиться на создании контента(персонажи и режимы), упрощении игры с друзьями и улучшении экономики, прогрессии наград. Вместо награды за гринд сделали наглядную линейку наград без лутбоксов. Они добавили возможность играть снова в том же составе с незнакомцами, добавили их в рекомендации в списке друзей. Запустившись на андроиде получили органический рост на обеих платформах.
Его выводы:
- не бойтесь инноваций и изменений
- при этом не стоит опасаться вернуться к популярным более удачным решениям
- на пользователей в бете большое влияние оказывает регулярность обновлений
- улучшайте то, что и так доставляет основное удовольствие в игре
Ребята считают, что если бы они раньше занялись социальными механиками, то как минимум гораздо раньше поняли, что игра зайдет.
Q&A:
- Отказались от удвоения лутбоксов за рекламу.
- Выход на Азию дал новых игроков и скачок в росте.
- Принимают решение о том стоит ли софтлончить или нет проконсультировавшись с командой и проведя внутренние плейтесты
Источник (англ., 1 час): https://youtu.be/VSVAmf5LCuo
Наконец добрался до докладов с white nights. Начну с доклада от Playrix об оперировании продуктами и подхода к созданию контента.
Динамика обновлений.
- Апдейт раз в 5-6 недель, содержит 1-2 новых матч3 элемента
- Каждую неделю добавляют 25 уровней.
Для того чтобы поддерживать темп обновления во всех трех проектах построили систему.
Ведут документ прототипов с описанием и рефами отдельно на каждом проекте.
Пробовали вести единый документ, но тогда все начинали брать одни и те же механики в разные проекты.
Механики протипируют, чтобы проверить эмоции пользователя. Есть специальная кросспроектная команда, которая в курсе происходящего, проводит аудит механик и обладает очень большой экспертизой в данном вопросе.
Для того, чтобы сбалансировать скорость создания контента ввели понятие сложности механик.
Простые механики - имеют в основе уже отработанные на других механиках принципы, взаимодействие с помощью матчей и взрывов.
Сложные - механики, с неординарной реакцией на действия игрока (пример генератор льда, создающий лёд при каждом матче рядом)
Очень сложные - сет элементов, много анимаций и графики, сложно тестировать (пример корм для кошки).
Сложные требуют много внимания от игрока, и он путается, поэтому важно сохранять баланс.
Визуал механик.
- образ играет важную роль в том, как механика воспринимается игроком
- 60-70% времени занимает работа с визуалом
- можно использовать практически одну и ту же механику с совершенно разным визуалом и создавать новое ощущение у игрока
- механики связаны с позитивно окрашенными событиями в метаигре, к примеру лимонад, пончик или собачка. В фишдоме взяли нерпу, которую нужно кормить рыбой, пришлось изрядно потрудиться над визуалом, чтобы не было ощущения, что она ест героев игры. Сделали абстрактный кулон.
Сложная задача - сочетаемость элементов друг с другом и бэками в долго живущем проекте. Художнику нужно давать подбор рефов, которые передают как визуал, так и эмоцию от механики. К примеру у клубка это ощущение тепла, уюта.
Стилизация.
В homescapes все элементы объемные, в спокойных, даже пастельных тонах и передают некоторое тактильное ощущение. В gardenscapes это что-то связанное с землей, к примеру тот же гном не сверкает белизной, а имеет некоторые изъяны типа трещин, следов от того, что стоял в земле.
Также есть список правил по цветовому ряду. У проектов есть разница по скорости визуализации, homescapes к примеру медленнее, чем более абстрактный fishdom.
Всегда стоит учитывать как игра смотрится рядом с конкурентами. Недавно провели анализ и обнаружили что gardenscapes медленнее, чем остальные продукты, а значит игрок получает меньше эмоций за время в игре. Пробуют ускорить эффекты.
Дизайн уровней.
На каждом проекте особенности учитываются и пишутся в кодекс level дизайнера.
К примеру:
- на старте уровня 3-4 свободных хода минимум, иначе ощущение ограниченности
- опитмальное количество ходов 25-30
- чем больше уровень, тем должен быть динамичнее, быстрее меняется
Для тестирования проводят "экспертный отсмотр". Команда обладающая экспертизой матч3 играет в уровни для релиза и дает рекомендации. За время использования такого подхода формируется понимание аспектов, которые сильнее всего влияют на ощущение от игры.
Используют схожую кривую сложности во всех проектах с небольшими смещениеями.
Источник (рус., 25 мин.): в открытом доступе пока нет.
Динамика обновлений.
- Апдейт раз в 5-6 недель, содержит 1-2 новых матч3 элемента
- Каждую неделю добавляют 25 уровней.
Для того чтобы поддерживать темп обновления во всех трех проектах построили систему.
Ведут документ прототипов с описанием и рефами отдельно на каждом проекте.
Пробовали вести единый документ, но тогда все начинали брать одни и те же механики в разные проекты.
Механики протипируют, чтобы проверить эмоции пользователя. Есть специальная кросспроектная команда, которая в курсе происходящего, проводит аудит механик и обладает очень большой экспертизой в данном вопросе.
Для того, чтобы сбалансировать скорость создания контента ввели понятие сложности механик.
Простые механики - имеют в основе уже отработанные на других механиках принципы, взаимодействие с помощью матчей и взрывов.
Сложные - механики, с неординарной реакцией на действия игрока (пример генератор льда, создающий лёд при каждом матче рядом)
Очень сложные - сет элементов, много анимаций и графики, сложно тестировать (пример корм для кошки).
Сложные требуют много внимания от игрока, и он путается, поэтому важно сохранять баланс.
Визуал механик.
- образ играет важную роль в том, как механика воспринимается игроком
- 60-70% времени занимает работа с визуалом
- можно использовать практически одну и ту же механику с совершенно разным визуалом и создавать новое ощущение у игрока
- механики связаны с позитивно окрашенными событиями в метаигре, к примеру лимонад, пончик или собачка. В фишдоме взяли нерпу, которую нужно кормить рыбой, пришлось изрядно потрудиться над визуалом, чтобы не было ощущения, что она ест героев игры. Сделали абстрактный кулон.
Сложная задача - сочетаемость элементов друг с другом и бэками в долго живущем проекте. Художнику нужно давать подбор рефов, которые передают как визуал, так и эмоцию от механики. К примеру у клубка это ощущение тепла, уюта.
Стилизация.
В homescapes все элементы объемные, в спокойных, даже пастельных тонах и передают некоторое тактильное ощущение. В gardenscapes это что-то связанное с землей, к примеру тот же гном не сверкает белизной, а имеет некоторые изъяны типа трещин, следов от того, что стоял в земле.
Также есть список правил по цветовому ряду. У проектов есть разница по скорости визуализации, homescapes к примеру медленнее, чем более абстрактный fishdom.
Всегда стоит учитывать как игра смотрится рядом с конкурентами. Недавно провели анализ и обнаружили что gardenscapes медленнее, чем остальные продукты, а значит игрок получает меньше эмоций за время в игре. Пробуют ускорить эффекты.
Дизайн уровней.
На каждом проекте особенности учитываются и пишутся в кодекс level дизайнера.
К примеру:
- на старте уровня 3-4 свободных хода минимум, иначе ощущение ограниченности
- опитмальное количество ходов 25-30
- чем больше уровень, тем должен быть динамичнее, быстрее меняется
Для тестирования проводят "экспертный отсмотр". Команда обладающая экспертизой матч3 играет в уровни для релиза и дает рекомендации. За время использования такого подхода формируется понимание аспектов, которые сильнее всего влияют на ощущение от игры.
Используют схожую кривую сложности во всех проектах с небольшими смещениеями.
Источник (рус., 25 мин.): в открытом доступе пока нет.
Сегодня пост по проблематике создания сценариев из конспекта книги Роберта Макки, предоставленного старшим ГД из NX Studio - Бурылиной Ириной. Полный конспект можно прочитать в источнике, ссылка внизу.
Вообще сюжет в игре как ни странно это очень нетривиальная штука. Чаще всего он сделан просто чтобы был хоть какой-то, при этом банален и состоит из кучи клише. Есть и другая крайность, когда нарративщик пилит проработанный сюжет, со сложными диалогами и огромным количеством отсылок, пытаясь создать своего Улисса. А игрок прокликивает всё, потому что пришел играть, взаимодействовать, а не читать. Как раз сейчас оцениваю, насколько большую роль сценарий играет для казуальной аудитории, обвязав логированием диалоги и косвенно касаясь данной темы в UX-исследованиях. Но об этом в другой раз.
Проблема интереса.
Любопытство - это интеллектуальная потребность получить ответы на вопросы. История же ставит эти вопросы. Каждый поворотный пункт подстегивает любопытство аудитории, заставляя её гадать, что же будет дальше.
Мастерство сценариста помогает скрывать какой-либо факт или результат, чтобы поддерживать желание аудитории двигаться по истории дальше. Однако следует избегать ложных тайн - фальшивого любопытства, вызванного искусственным сокрытием фактов, когда экспозиция, которая может и должна быть представлена, откладывается в надежде поддержать интерес аудитории.
Проблема неожиданности.
Погружаясь в новую историю, мы надеемся, что она нас удивит. Хотим получить опыт, которого у нас ещё никогда не было. Если все события будут происходить ровно так, как представлялось аудитории, то в итоге она останется несчастна.
Нужно уметь удивлять.
Истинная неожиданность - возникает в результате внезапного появления бреши между тем, что предвиделось, и результатом. Оно «истинное», потому что далее следует вспышка понимания, когда открывается правда, скрытая под оболочкой вымышленного мира.
Ложная неожиданность - часто используется в плохих фильмах ужасов и подрывает ожидания аудитории (прим.: К герою тянется рука, он оборачивается и... Видит просто друга, а вовсе не маньяка или призрака).
Проблема совпадений.
История формирует смысловое содержание. Поэтому совпадение можно считать врагом сценариста, так как это случайное, абсурдное стечение обстоятельств, которое по определению лишено смысла. Однако, в реальной жизни нелепые совпадения тоже имеют место быть, и они вносят некий диссонанс в наше существование. Поэтому, если уж и включать в историю совпадения, то в дальнейшем они должны обрести смысл.
Рекомендации:
- включайте совпадения в свой сценарий как можно раньше, чтобы оставалось достаточно времени для придания им значения.
- не используйте совпадения для создания финала. Это «бог из машины» — самый великий грех сценариста.
Проблема логических дыр.
Появление в повествовании «дыр» — еще один путь к потере доверия аудитории. Теперь истории недостает логики, потому что отсутствуют звенья в цепи причинно-следственной связи. Как и совпадения, дыры являются частью нашей жизни. Нередко что-то происходит, но объяснить причину мы не можем.
Нужно следить, чтобы в истории было как можно меньше логических дыр. Ну а если уж они имеются, то признать их, и может даже подшутить над ними.
Источник (рус.) : https://docs.google.com/document/d/1fZE87LWZjT0KfI_gyW2gpu6Y79z7fZJhwE4uUvYVKWQ/edit#
Вообще сюжет в игре как ни странно это очень нетривиальная штука. Чаще всего он сделан просто чтобы был хоть какой-то, при этом банален и состоит из кучи клише. Есть и другая крайность, когда нарративщик пилит проработанный сюжет, со сложными диалогами и огромным количеством отсылок, пытаясь создать своего Улисса. А игрок прокликивает всё, потому что пришел играть, взаимодействовать, а не читать. Как раз сейчас оцениваю, насколько большую роль сценарий играет для казуальной аудитории, обвязав логированием диалоги и косвенно касаясь данной темы в UX-исследованиях. Но об этом в другой раз.
Проблема интереса.
Любопытство - это интеллектуальная потребность получить ответы на вопросы. История же ставит эти вопросы. Каждый поворотный пункт подстегивает любопытство аудитории, заставляя её гадать, что же будет дальше.
Мастерство сценариста помогает скрывать какой-либо факт или результат, чтобы поддерживать желание аудитории двигаться по истории дальше. Однако следует избегать ложных тайн - фальшивого любопытства, вызванного искусственным сокрытием фактов, когда экспозиция, которая может и должна быть представлена, откладывается в надежде поддержать интерес аудитории.
Проблема неожиданности.
Погружаясь в новую историю, мы надеемся, что она нас удивит. Хотим получить опыт, которого у нас ещё никогда не было. Если все события будут происходить ровно так, как представлялось аудитории, то в итоге она останется несчастна.
Нужно уметь удивлять.
Истинная неожиданность - возникает в результате внезапного появления бреши между тем, что предвиделось, и результатом. Оно «истинное», потому что далее следует вспышка понимания, когда открывается правда, скрытая под оболочкой вымышленного мира.
Ложная неожиданность - часто используется в плохих фильмах ужасов и подрывает ожидания аудитории (прим.: К герою тянется рука, он оборачивается и... Видит просто друга, а вовсе не маньяка или призрака).
Проблема совпадений.
История формирует смысловое содержание. Поэтому совпадение можно считать врагом сценариста, так как это случайное, абсурдное стечение обстоятельств, которое по определению лишено смысла. Однако, в реальной жизни нелепые совпадения тоже имеют место быть, и они вносят некий диссонанс в наше существование. Поэтому, если уж и включать в историю совпадения, то в дальнейшем они должны обрести смысл.
Рекомендации:
- включайте совпадения в свой сценарий как можно раньше, чтобы оставалось достаточно времени для придания им значения.
- не используйте совпадения для создания финала. Это «бог из машины» — самый великий грех сценариста.
Проблема логических дыр.
Появление в повествовании «дыр» — еще один путь к потере доверия аудитории. Теперь истории недостает логики, потому что отсутствуют звенья в цепи причинно-следственной связи. Как и совпадения, дыры являются частью нашей жизни. Нередко что-то происходит, но объяснить причину мы не можем.
Нужно следить, чтобы в истории было как можно меньше логических дыр. Ну а если уж они имеются, то признать их, и может даже подшутить над ними.
Источник (рус.) : https://docs.google.com/document/d/1fZE87LWZjT0KfI_gyW2gpu6Y79z7fZJhwE4uUvYVKWQ/edit#
Второй доклад от Playrix с White nights 2019, но теперь о потроении процессов разработки.
Как уже говорилось, разработка версии продукта на поддержке занимает 4-6 и она содержит определнный набор фич. Контентные обновления, новые функционалы или к примеру редизайн. Менеджер проекта назначает на каждую фичу нескольких ГД, ответственных за неё. Они формируют видение того, как очередной релиз будет выглядеть, затем согласуют это с продюсерами.
Функции миникоманды.
Миникоманда определяет приблизительные сроки и согласует их с проджект менеджером. Также она она является источником информации о проекте для остальной компании. Оптимальный размер 3-5 человек.
Роли.
Лидер - отвечает за организацию работы по фиче, знает все приоритеты и процессы на проекте. Цель - максимальная скорость разработки.
Ответственный за качество - эксперт в геймдизайне, отсматривает реализацию фичи, разбирается что идёт не так и вносит предложения по улучшению. Цель - максимальное качество
Продюссер фичи - участвует в проектировании самых сложных функционалов, оценивает с точки зрения всей компании
Ответственный по направлению - эксперт в узкой области ( программирование, арт или допустим матч3 часть). Вносит предложения на основе своего опыта, предлагает как оптимизировать с учётом готового контента. Также разбивается в компетенциях исполнителей своего направления.
Команду подбирают из тех специалистов, которые участвуют на всех этапах разработки фичи. Один человек может быть на нескольких ролях, может входить в несколько миникоманд.
Важно четко прописывать задачи каждой из ролей.
Обычно составляют команду, чтобы сотрудники компенсировали недостатки и пробелы в знаниях друг друга. Одним из самых важных навыков является умение договариваться.
Плюсы внедрения миникоманд.
- рост специалистов благодаря работе в разных командах и обмену опытом
- отсутствие необходимости в большом количестве менеджеров и продюсеров на проектах на поддержке
- оперативность решений возросла
- уровень осведомленности исполнителей по проекту и в целом сотрудников вырос
Минусы.
- из-за ограничения размеров команды не все необходимые специалисты в нее попадают и принимают участие в выработке решений
- частые конфликты за ресурсы и приоритеты
Источник (30 мин.): пока нет в открытом доступе
Как уже говорилось, разработка версии продукта на поддержке занимает 4-6 и она содержит определнный набор фич. Контентные обновления, новые функционалы или к примеру редизайн. Менеджер проекта назначает на каждую фичу нескольких ГД, ответственных за неё. Они формируют видение того, как очередной релиз будет выглядеть, затем согласуют это с продюсерами.
Функции миникоманды.
Миникоманда определяет приблизительные сроки и согласует их с проджект менеджером. Также она она является источником информации о проекте для остальной компании. Оптимальный размер 3-5 человек.
Роли.
Лидер - отвечает за организацию работы по фиче, знает все приоритеты и процессы на проекте. Цель - максимальная скорость разработки.
Ответственный за качество - эксперт в геймдизайне, отсматривает реализацию фичи, разбирается что идёт не так и вносит предложения по улучшению. Цель - максимальное качество
Продюссер фичи - участвует в проектировании самых сложных функционалов, оценивает с точки зрения всей компании
Ответственный по направлению - эксперт в узкой области ( программирование, арт или допустим матч3 часть). Вносит предложения на основе своего опыта, предлагает как оптимизировать с учётом готового контента. Также разбивается в компетенциях исполнителей своего направления.
Команду подбирают из тех специалистов, которые участвуют на всех этапах разработки фичи. Один человек может быть на нескольких ролях, может входить в несколько миникоманд.
Важно четко прописывать задачи каждой из ролей.
Обычно составляют команду, чтобы сотрудники компенсировали недостатки и пробелы в знаниях друг друга. Одним из самых важных навыков является умение договариваться.
Плюсы внедрения миникоманд.
- рост специалистов благодаря работе в разных командах и обмену опытом
- отсутствие необходимости в большом количестве менеджеров и продюсеров на проектах на поддержке
- оперативность решений возросла
- уровень осведомленности исполнителей по проекту и в целом сотрудников вырос
Минусы.
- из-за ограничения размеров команды не все необходимые специалисты в нее попадают и принимают участие в выработке решений
- частые конфликты за ресурсы и приоритеты
Источник (30 мин.): пока нет в открытом доступе
