Нужен совет по тестированию балланса игры
Я backend разработчик (ОК, архитектор, но в рамках этого сайта, без разницы), 20+ лет пишу приложения для бизнеса. Регулярно стараюсь делать pet проекты на новых для себя технологиях.
Этим летом взялся делать игрушку кликер на Angular. Я большой фанат Kittens Game.
Хочется попробовать сделать что-то похожее, с кучей разнообразных механик. Не с целью как-то заработать, а просто получить опыт работы с новой областью. Я понимаю, что без опыта работы в индустрии сделать что-то сколько-то не стыдное сложно, но я стараюсь делать "как по настоящему".
Собственно вопрос. Я успел накрутить некоторое количество механик. Во всех них заложенно какое-то количество цифр. Лесопилка стоит столько-то, скорость производства такая-то и так далее.
Я примерно понимаю как все в итоге должно быть сбалансированно. Радость от того, что что-то новое построилось, открылось или проапгрейдилось должна приходить примерно в одинаковые промежутки времени и это должно быть от 30 до 60 сек (как я думаю).
Как тестировать? У меня есть юнит тесты движка, которые прогоняют разныне сценарии и проверяют, что все механики работают. У меня есть Selenium тест который гоняет end-to-end тест от начала до строительства самого топового здания которое я сделал на текущий момент.
Как лучше тестить субъективные ощущения от игры? Прогон с начала до конца сейчас в ручную с автокликером сейчас занимает десятки минут. Делать дебаг кнопки которые подводят игру к ключевым точкам и потом пробовать играть - мне кажется это слишком исскуственно будет.
В принципе можно плюнуть, накрутить механик, поиграться с технологией и заморозить проект. Но хочется попробовать сделать какой-то кусок работы "по настоящему".
Накидайте каких-то советов - в какую сторону посмотреть.
A/B testing na lyudyah
до этого еще добраться надо - сейчас все на ранней стадии - там совсем не интересно пока. Мне кажется заманить людей тестить ранюю альфу кликера нет вариантов.
Все просто - самому никак. Ошибки восприятия, замыленность взгляда - есть у всех, даже у топовых студий (прикинь 2-3 года фултайм работать над 1 проектом). Поэтому они гоняют на фокус-группах, снимают метрики, вплоть до записи процесса игры и лица игрока. Даже ААА игры выходят скучными, хоть в них и поработали над графикой и миром, потому что геймплей оценить настолько сложно.
Для решения этих задач на начальных этапах:
1. Делают вертикальный срез игры (vertical slice). Он демонстрирует все основные механики игры в укороченном виде. Не упрощенном - именно укороченном.
2. Тестируют на фокус-группах, или хотя бы просто на желающих.
Не понравиться может что угодно: баланс, сеттинг, анимация, звуки, визуальный стиль, проблемы UI. Без нормального теста от немотивированных игроков не поймешь. Близкие друзья и родственники - так себе вариант, для мамы ты всегда самый хороший.
В твоем случае, стоит сделать систему событий/контрольных точек, которые будешь отслеживать на бэке, и дальше по ним строить метрики и анализировать. До какого момента доходят игроки? Когда обычно бросают? Сколько времени занимает процесс от точки 38 до 39 - столько же, сколько ты ожидал? Продолжительность игровой сессии в зависимости от этапа игры? Заходят ли каждый день? К слову, так работает весь мобильный геймдев.
Спасибо! Про вертикальный срез это прям интересная фишка, надо подумать как лучше.
Про тестирование с другими пользователямя, фокус-группы и все такое я в общем знаю, как устроен PDLC процесс для средних и больших команд я в целом понимаю, без учета игровой специфики. Беда в том, что это уже надо браться всерьез, а у меня план поковыряться еще несколько месяцев и бросить.
У меня есть фокус группа - дочки - они по определеню скептически отнесутся, еще одна каша от родителей. Но фокус группа весьма ограничена.
Попробую подумать в сторону вертикального среза.
Я примерно понимаю как все в итоге должно быть сбалансированно Радость от того, что что-то новое построилось, открылось или проапгрейдилось должна приходить примерно в одинаковые промежутки времени и это должно быть от 30 до 60 сек (как я думаю). Как лучше тестить субъективные ощущения от игры?
Яркий пример почему программист в одиночку (за редким исключение) не сможет создать успешный проект без геймдизайнера.
Самый простой совет, не изобретай велосипед и копируй то, что работает у твоих успешных конкурентов, если не хочешь тратить время на проработку игровых механик.
Ну это банально не интересно.