Рубрика: теория ифни

Касаемо разработки платформ

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

© Э. Эванс, Предметно-ориентированное проектирование.

Опрос: доступность действий в парсерной игре

Смотрите какое дело. Предположим, есть игра, в которой в какой-то момент вам потребуется, скажем, насобирать желудей. Или разломать радиоприёмник. Или пописать в баночку. Не важно, главное, что действие совершить можно, но это не совсем очевидное действие.

Так вот. Вопрос в том, разрешать ли игроку совершать его с самого начала или только после обоснований. Например, если по сюжету потребовались батарейки, то давать ломать приёмник, а так — нет, писать «Зачем ломать прекрасный приёмник?! Я не буду этого делать!»

Ограничение действия до его обоснования служит противодействием комбинаторного взрыва мозга игрока. Когда он получает жёлуди или батарейки в самом начале игры и не знает, что с ними делать. И тычет их всюду, испытывая разочарование.

С другой стороны, возможны ситуации, когда игрок, попробовав какое-то действие и обломавшись с возможностью его совершения, больше никогда не пробует разламывать приёмник или писать в баночку.

Так что вот, как лучше-то? Если у вас есть свой вариант, пишите его в комментариях.

Когда должны быть доступны действия в игре?