Стоит добавить «футуристические» функции в нашу игру, или мы должны сосредоточиться на другом месте?

Я ведущий программист в студии инди-игр среднего размера. Это наша первая игра в команде. Мы работаем над футуристической игрой FPS с планом коммерческого участия в прибылях.

В любом случае, у нас есть несколько очень хороших программистов, у которых есть возможность создавать невиданные ранее функции (настоящие реалистичные флюиды, процедурное разрушение сетки, процедурные скайбоксы и т. Д.). И мне интересно, есть ли смысл реализовывать эти вещи? Они занимают много времени, но выглядят блестяще. Мы стремимся к 12-месячному циклу разработки. Поэтому мы должны сделать это или просто сделать стандартную игру.

Не пытайтесь сделать это, потому что вы знаете, что можете это сделать.

Геймплей должен быть первым, все вещи (даже графика) вторичны. Если игра веселая и приятная, но с плохой (или не очень новой) графикой, она все равно будет веселой и приятной, и люди будут играть в нее, а также ваш метакритик будет хорош. В противном случае, если игра обладает потрясающей графикой и функциями (реалистичные флюиды, процедурное разрушение сетки и т. Д.), Но не является увлекательной или сложной для игры (плохой контроль и т. Д.), Люди не будут играть в нее. Нет игроков = нет денег, а также плохой метакритик.

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

Кроме того, избегайте попыток построить игровой процесс вокруг одной из этих потрясающих функций, если это не имеет смысла или вы думаете, что это не будет весело. Например: вы можете подумать: «У меня есть процедурное уничтожение сетки, поэтому давайте заставим игрока уничтожить все, прежде чем он сможет продолжить продвижение в игре (чтобы он мог видеть, что сетки уничтожаются процедурно)».

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

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

В идеале у вас будет время провести бета-тестирование с кандидатами на выпуск, поэтому большинство работ, за исключением экстренных исправлений ошибок и настройки, прекращается на 50 неделе.

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

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

Кстати, смоделированные объемы жидкости, процедурное разрушение, динамические скайбоксы и т. Д. - все это было сделано в коммерческих играх, и причина, по которой вы не слышите о них так много, в том, что сама игра всегда была более важной.

Желаем удачи, все, что вы делаете, будет захватывающим!

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

Но если вы должны сделать что-то таким образом, тогда выберите ОДНУ классную вещь. Не все, даже не два - Никогда не вводите слишком много факторов риска одновременно. И тот, который вы выбираете, ДОЛЖЕН быть как-то центральным в игровом процессе, потому что все остальное просто пух. Когда вы Blizzard, вы можете позволить себе сидеть сложа руки, добавляя аккуратные функции - хотя их решения всегда ориентированы на бизнес, ИМХО.

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

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

«У нас есть несколько очень хороших программистов, у которых есть возможность создавать невиданные ранее функции»

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

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