Время, деньги и фан в ММО
Схема преобразования времени и денег в фан.
Наводил у себя в голове порядок, размышляя об организации игрового процесса, монетизации, ботоводстве и некоторых других вещах, и пришёл к интересной концепции. Наверняка она где-то уже озвучивалась, но я всё равно ею поделюсь.
Суть в том, что любую развлекательную игру можно представить как машину, преобразовывающую время игрока в фан. Фан — отличное общее понятие и как-то уточнять его не будем. Кто-то получает фан от исследований игрового мира, кто-то от нагибания ближних своих — для наших рассуждений это не важно.
В итоге, геймдизайн строится вокруг управления коэффициентом преобразования времени в фан. Если коэффициент слишком низкий — игрок начинает скучать и бросает играть. Если слишком высокий — игроки пресыщаются и забрасывают игру.
Эта статья — пробный подход к теме. Развитие идей можно найти в:
О системном мышлении
Системное мышление — это практический подход к восприятию мира, который значительно ускоряет способности анализировать, принимать решения и учиться. Практический потому, что сформирован практикой, а не вырос из абстрактных математических теорий.
Если вам знакома аббревиатура ТРИЗ, то я бы сказал, что методы ТРИЗ — это набор частных случаев применения системного мышления в физическом производстве.
О книге «Логика случая»
Всем, интересующимся устройством мира, рекомендую почитать «Логику случая» Евгения Кунина — книгу о современном научном взгляде на эволюцию (который уже сильно отличается от того, чему нас учили в школе).
Особенно рекомендую её программистам, которым интересно изменение софта со временем и развитие «сложности» — очень многие идеи, изложенные в книге, перекликаются с моими наблюдениями за жизненным циклом кода.
Книга изобилует химическими и биологическим терминами, но они не мешают восприятию информации, в крайнем случае пояснение всегда можно найти в википедии.
Для затравки перескажу своими словами наиболее интересные факты. Только учтите, что я ни разу не биолог и могу сильно ошибаться.
Почему разработчики не сделают эту простую штуку?
Животрепещущий вопрос, не правда ли?
Меня уже 3 года как им пытают персонально, поэтому я решил попытаться рассказать всё-таки почему. Рассказывать, конечно, буду со стороны разработчика-одиночки. В командах побольше есть некоторые нюансы, но суть та же.
Для затравки приведу небольшую иллюстрацию, смысл её, думаю, понятен.
Взгляд на проект со стороны пользователя и разработчика.
Тесты, которые тестируют тесты
Или почему в них нет необходимости.
Часто, когда рассказываешь новичкам про автоматическое тестирование, всплывает один и тот же вопрос: «А кто будет проверять сами тесты? Придётся писать тесты для тестов, потом тесты для тестов для тестов…» Все любят рекурсию и ещё больше любят уесть ей собеседника.
Странно, ни разу не попадался вопрос: «Кто тестирует тестировщиков?» — по сути, та же проблема вид сбоку.
Но действительно, почему нет необходимости тестировать тесты? (и тестировщиков)