Прочитал статью, которой уже почти четверть века, про подход к разработке игры Half-life: The Cabal: Valve’s Design Process For Creating Half-Life.

Игра, которая по словам команды в процессе разработки была скучной и неинтересной в итоге стала хитом и сильно повлияла на индустрию. Статья пытается объяснить как же это получилось — как команда смогла сделать интересный и вовлекающий продукт?

Что мне показалось интересным:

1) Основополагающие принципы.
Команда выработала основополагающие принципы, которые легли в основу всех решений.

— Если игрок продвигается вперёд, то ему/ей надо в течении какого-то времени обязательно показать какую-то интересность — монстра, эффект, часть истории:

The first theory we came up with was the theory of “experiential density” — the amount of “things” that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on. Since we couldn’t really bring all these experiences to the player (a relentless series of them would just get tedious), all content is distance based, not time based, and no activities are started outside the player’s control. If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen.

— Любое действие игрока должно давать обратную связь в каком-то виде:

The second theory we came up with is the theory of player acknowledgment. This means that the game world must acknowledge players every time they perform an action. For example, if they shoot their gun, the world needs to acknowledge it with something more permanent than just a sound — there should be some visual evidence that they’ve just fired their gun. […] This also means that if the player pushes on something that should be pushable, the object shouldn’t ignore them, it should move. If they whack on something with their crowbar that looks like it should break, it had better break. If they walk into a room with other characters, those characters should acknowledge them by at least looking at them, if not calling out their name. Our basic theory was that if the world ignores the player, the player won’t care about the world.

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

A final theory was that the players should always blame themselves for failure. If the game kills them off with no warning, then players blame the game and start to dislike it. But if the game hints that danger is imminent, show players a way out and they die anyway, then they’ll consider it a failure on their part; they’ve let the game down and they need to try a little harder. When they succeed, and the game rewards them with a little treat — scripted sequence, special effect, and so on — they’ll feel good about themselves and about the game.

Внимательный читатель обратит внимание, что эти принципы сильно похожи на общие подходы к хорошему дизайну и вообще сейчас часто встречаются. Я время от времени играю в Зельду на Nintendo Switch (BotW и недавно вышедший TotK) — там те же штуки.

Нахождение и следование основополагающим принципам — очень мощный инструмент для продакт-менеджера. Они помогают принимать решения и делать продукт более сфокусированным, более opinionated.

Эти принципы можно находить наблюдая за какими-то существующими работающими и успешными системами (“эта штука работает хорошо — а почему?”), но они могут и просто идти от начальной идеи и желания “сделать именно так”.

И кстати, вспоминая задачу про лифты — её сильно проще решать, если понять, что люди не любят в лифтах (“когда приходишь и долго ждёшь”, “когда едешь с другими людьми”, “когда останавливается на каждом этаже”) и положить это в принципы решения.

2) Тестирование на живых игроках
Valve тестировали на живых игроках все изменения, чтобы понять — что работает, а что нет. Но особенно интересна следующая часть:

Toward the middle of the project, once the major elements were in place and the game could be played most of the way through, it became mostly a matter of fine-tuning. To do this, we added basic instrumentation to the game, automatically recording the player’s position, health, weapons, time, and any major activities such as saving the game, dying, being hurt, solving a puzzle, fighting a monster, and so on. We then took the results from a number of sessions and graphed them together to find any areas where there were problems. These included areas where the player spent too long without any encounters (boring), too long with too much health (too easy), too long with too little health (too hard), all of which gave us a good idea as to where they were likely to die and which positions would be best for adding goodies.

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

3) Все основные штуки, которые есть в Half-life, были придуманы тайным собранием, которое собиралось каждый день по 6 часов в течении 5 месяцев. В результате был создан общий дизайн-документ, который описывал всё.

Создание такого комитета — это попытка обойти ограничения иерархичных структур:

In order for highly hierarchical organizations to be effective, they require one person who understands everyone else’s work at least as well as the individuals doing the work, and other people who are willing to be subordinates yet are still good enough to actually implement the design. Given the complexity of most top game titles, this just isn’t practical — if you were good enough to do the job, why would you want to be a flunky? On the other hand, completely unstructured organizations suffer from lack of information and control — if everyone just does their own thing, the odds that it’ll all fit together in the end are somewhere around zero.

Тут хочется отметить, что это не единственное возможное решение парадокса из цитаты выше. Даже кажется это весьма оригинальное решение. Требуется определенная культура и “встроенная требовательность”, что комитет постоянно поддерживал уровень качества и не боялся конфликтов. Это подтверждает и цитата:

Through constant cycle of play-testing, feedback, review, and editing, the Cabal process was also key in removing portions of the game that didn’t meet the quality standards we wanted, regardless of the level of emotional attachment the specific creator may have had to the work.

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

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