В этом эссе я попытался сформулировать принципы создания хорошей, запоминающейся парсерной игры. Я не стану останавливаться на моментах, которые относятся больше к литературной составляющей. Т.е. сюжете, персонажах, повествовании. А заострю внимание на вещах, специфичных именно для парсерных игр. Поехали.
Читать далее Как написать хорошую парсерную игруТак или иначе, вы должны проживать жизнь за своих персонажей, чтобы она у них была; у них нет возможности где-то еще занять мозгов, кроме как у вас.
Хорошая статья Элиезера Юдковского, известного своим романом-фанфиком «Гарри Поттер и метод рационального мышления».
Смерть (или временную спячку) текстовых квестов связывают обычно с ориентацией масс на яркие визуальные эффекты. Но есть и другое объяснение. В современных трехмерных видеоиграх у игрока есть крайне ограниченный набор активных действий. Обычно игроки знают обо всех возможных действиях, которые они могут совершить. В текстовых квестах целый ряд базовых действий был неизвестен игроку, а их открытие становилось частью игры. Очень часто решением заковыристой загадки становилось необычное действие, типа «уколоть рыбу» или «пощекотать обезьяну». Несмотря на весь творческий потенциал данного подхода, задания часто были слишком сложными – хоть игра и поддерживала сотни различных действий, оставались еще тысячи неизвестных. Как результат у игроков не было «полной свободы», которую теоретически должен был предоставить им интерфейс текстового квеста. Вполне возможно, именно эта сложность способствовала уходу жанра в небытие.
© Джесси Шелл, «Геймдизайн»
Помните, я говорил, что идеи не важны? Это потому, что разработка игры заключается в исполнении. Игра со средненькой идеей вполне может быть невероятна, если хорошо исполнена. Игра с невероятной идеей вполне может быть серой, если исполнена слабо. Хорошие разработчики заметны среди иных благодаря тому, как справляются с этой задачей.
Аджента поделилась циклом статей от сценариста BioWare. Исключительно интересное чтиво. Рекомендую.
Не пишите архитектурные среды для «чайников». Если делить разработчиков на группы, подразумевая при этом, что некоторые из них не способны к архитектурному проектированию, то впереди, скорее всего, вас ждет неудача, поскольку этим недооценивается сложность технической разработки приложения. Если вы считаете, что у этих людей не хватает ума проектировать, нечего поручать им разработку программ. А если ума у них хватает, тогда нянчиться с ними — это только ставить преграды между ними и требующимися им для работы инструментами.
© Э. Эванс, Предметно-ориентированное проектирование.
Смотрите какое дело. Предположим, есть игра, в которой в какой-то момент вам потребуется, скажем, насобирать желудей. Или разломать радиоприёмник. Или пописать в баночку. Не важно, главное, что действие совершить можно, но это не совсем очевидное действие.
Так вот. Вопрос в том, разрешать ли игроку совершать его с самого начала или только после обоснований. Например, если по сюжету потребовались батарейки, то давать ломать приёмник, а так — нет, писать «Зачем ломать прекрасный приёмник?! Я не буду этого делать!»
Ограничение действия до его обоснования служит противодействием комбинаторного взрыва мозга игрока. Когда он получает жёлуди или батарейки в самом начале игры и не знает, что с ними делать. И тычет их всюду, испытывая разочарование.
С другой стороны, возможны ситуации, когда игрок, попробовав какое-то действие и обломавшись с возможностью его совершения, больше никогда не пробует разламывать приёмник или писать в баночку.
Так что вот, как лучше-то? Если у вас есть свой вариант, пишите его в комментариях.
