Как вы решаете, когда ваш список функций достаточно длинный?

Я немного знаю об этом вопросе, но нахожу, что существует довольно много разных мнений по этому вопросу?

Я знаю с точки зрения игроков, что больше вариантов почти всегда хорошо. Но, с другой стороны, если в нем много игроков, это означает более высокую сложность (мета-игру) как для разработчиков, так и для игроков.

Сложность разработки и временные ограничения всегда идут рука об руку. Другой будет ограниченность ресурсов и платформы. Возможные экономические последствия сдерживания на потом также иногда являются причиной.

Так что, если не считать вышеизложенного, то, как люди здесь сталкиваются, когда функции должны быть сокращены или должны быть выпущены позже?

Я бы сказал, что для нас это двухэтапный процесс:

• Установите цели игры.
• Определите, какие функции помогают нам достичь этих целей.

Список возможностей достаточно длинный, когда эти две точки совпадают. Так:

1. Установите наши цели - выясните все, что мы хотим, чтобы игра сделала для игрока / рецензента / кого бы то ни было, а затем измерите их. Например, с нашей последней версией ( см. Альфа-тест vid здесь ), мы хотим сделать это:

• Визуалы: мы хотим, чтобы в каждом обзоре упоминалось, что визуалы необычны и сексуальны, особенно для инди-фильма. Это важно для нас, потому что геймеры часто используют свои глаза в качестве быстрого показателя качества (хотя, конечно, это только один из многих!), И мы хотим, чтобы это привлекло их внимание.
• Исследование: Мы также хотим вознаграждать людей за изучение игры. Чтобы измерить это, мы хотим, чтобы примерно пятая часть игрового времени была потрачена на аккуратные мелочи вне основного игрового процесса. Это важно для нас, потому что (IMO) большая часть удовольствия от игры выходит за рамки ожидаемых, основных областей (мы думаем о том, как нас интересует щелчок по частям в Starcraft).
• Сообщество: Мы хотим, чтобы каждый рассказал хотя бы одному другу об игре.

2. Определите функции, которые помогают нам достичь этих целей - они почти естественно выпадают из вышеперечисленного. Итак, функции, соответствующие приведенным выше примерам, могут выглядеть так:

• Визуальные эффекты. Если мы хотим создать сексуальную визуализацию в маленькой студии, мы не можем идти вразрез с EA или Sony по реалистичности. Таким образом, чтобы приблизиться к цели замечательных визуальных эффектов, одной из особенностей игры является сюрреалистическая эстетика. (Исходя из этого, мы можем определить, какие инструменты нам нужны, и т. Д.)
• Исследование: из этого вытекают следствия игры. В нашем последнем названии мы опускаем краткую ссылку на сомнительный поиск Рио моряков в Шенмуе . Это был глупый отказ, но людям понравилось и говорили об этом!
• Сообщество: Мы задаемся вопросом, как сделать игру, о которой стоит рассказать другу. Конечно, делать это весело # 1. Но мы также можем награждать игроков специальным предметом или уровнем, если они пишут об этом в Твиттере. Покемон сделал так, чтобы друзья подхватили игру - есть некоторые существа, которых вы можете получить, только общаясь с другими людьми.

Когда мы проходим этот процесс, это помогает нам определить:

• Сколько нам нужно реализовать для минимально жизнеспособного продукта ( MVP ).
• Что самое важное, что может подождать, и что мы можем отбросить.
• Когда у нас наконец есть все функции, которые нам нужны.

Стоит отметить, что мы не рабски придерживаемся этих правил! Чаще всего некоторые удивительно интересные вещи возникают в результате прототипирования в середине проекта и просто в целом. Особенно для небольших игр, таких как наша.

Сложность не делает вашу игру веселой.

Правильное сочетание и баланс элементов игрового процесса делает. Игрок должен быть доведен до уровня своего мастерства и получить чувство мастерства от преодоления испытаний.

Ваш список функций должен меняться всякий раз, когда вы чувствуете, что текущий игровой процесс не веселый. Эти изменения должны быть сделаны в рамках вашего бюджета / временных ограничений. Убедитесь, что любые изменения, которые вы вносите в свою игру.

Кроме того, прототип рано, не просто написать огромный список функций и предположить, что все это будет весело, если собрать их вместе.

Совершенство достигается не тогда, когда нечего добавить, а когда нечего отнять.

- Антуан де Сент-Экзюпери

Когда время и усилия, необходимые для их включения, превышают ценность, которую они добавляют в игру .

Например, если вы создавали спортивную игру или что-то, где игроки, вероятно, захотят продемонстрировать свои навыки, многопользовательская игра является обязательным условием. Герой гитары не был бы таким же без него. Тем не менее, исключительно индивидуальная игра, в которой вы начинаете играть самостоятельно, следуя истории или сюжету, не требует многопользовательской игры. Обременительная многопользовательская система в Grand Theft Auto San Andreas является свидетельством этого (хотя эта компания, вероятно, не находила многопользовательскую игру слишком сложной).

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

Дело в том, что дополнительные функции не являются основным элементом игры. Захватывающий сюжет в сочетании с приятным игровым процессом.

В то время как есть степень, в которой разнообразие функций велико (возможность делать тонны случайных вещей в игре GTA-ih, иметь тонны разнообразия в оружии и аксессуарах в RPG или игре Call of Duty-ish и т. Д.), Я думаю, что более минимальный геймплей, сфокусированный на нескольких основных функциях, может быть очень эффективным.

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

Я думаю, что строго придерживаться минимального списка возможностей и по-настоящему выделить несколько основных функций позволяет сделать проект более выполнимым и зачастую более приятным (если в Portal добавлены элементы RPG, последовательности движений, замедленная съемка и любые другие «интересные» функции ", это было бы так же хорошо? Механика ядра была бы так же отполирована?).

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

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

С точки зрения дизайна, функция, которая была добавлена ​​в тот момент, когда «особенность x была бы хороша», добавит много времени на разработку, может плохо интегрироваться с кодом и может не полностью соответствует остальной части вашего дизайна.

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

В качестве общего руководства я стараюсь придерживаться следующих правил:

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

• Если проект приближается к выпуску, рассмотрите возможность составления списка функций для добавления в новую версию.

• Если вы обнаружите, что появляется множество функций, которые вы действительно хотите реализовать, возможно, вам следует вернуться к дизайну и посмотреть, почему эти новые функции не рассматривались ранее, возможно, из-за отсутствия усилий, потраченных на фаза проектирования.

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

Держите списки короткими, будьте проворны

Не создавайте списки функций вообще, или, если вы делаете, создайте их очень короткие, стоит всего несколько недель разработки.

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

Как оценить индивидуальную особенность

Кроме этого, я бы согласился с критерием bennybdbc: «Когда время и усилия, необходимые для их включения, превышают ценность, которую они добавляют в игру».

Тем не менее, вы также должны рассмотреть «внешний» мир:

• у вас заканчиваются деньги или не хватает времени, указанного в контракте?
• у вас заканчивается медиа-пространство для публикации (полный DVD)
• Вы исчерпываете пространство для производительности (из-за новых функций игра будет работать слишком медленно)?
• скоро выйдет конкурирующая игра?

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

Когда у вас кончатся бумаги, чтобы написать это.

Определенным пределом будет размер носителя; Например, вы не можете разместить 10 ГБ на DVD-диске объемом 4,7 ГБ.

Вам не нужно слишком много функций, чтобы слишком усложнить игру. Лучше всего задаться вопросом: «Будет ли это значительно интереснее для игрока? Не слишком ли много времени на разработку? это вообще возможно?