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

17

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

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

Muzz5
источник
3
«Мы работаем над футуристической игрой FPS». Никогда не видел ни одного из тех, кто раньше </ sarcasm>. Я не совсем уверен, что прямая конкуренция с тысячей и одной «футуристической FPS» игрой - это надежная бизнес-модель для инди-студии среднего размера.
Николь Болас
3
@NicolBolas Жанр не имеет никакого отношения к инновациям. Тема их игры - их собственная забота, если они хотят сделать это, вы можете быть уверены, что они собираются это сделать. Есть инновационные игры, созданные в каждом жанре как инди, так и крупными студиями. Другими словами, они либо вводят новшества в рамках своего жанра, либо нет, и это все, что имеет значение.
инженер
Примечание: процедурные скайбоксы звучат потрясающе ... всегда удивлялись, почему во многих играх есть "статичные" скайбоксы или скайбоксы с несколькими слоями облаков, дрейфующих над ними, вероятно, потому, что большинство людей этого не замечают и ресурсы может быть использован для чего-то другого ... но это кажется хорошей вещью
Хольгер

Ответы:

28

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

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

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

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

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

Байт укротитель
источник
15

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

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

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

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

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

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

Патрик Хьюз
источник
1
Я хочу добавить, что иногда внешний вид игры является частью того, что делает ее забавной или выделяющей ее и, следовательно, захватывающей! Я не хочу, чтобы вы думали, что визуально скучно хорошо только потому, что на это уходит меньше времени =)
Патрик Хьюз
1
Я бы сказал, что это оптимистично. Полировка в ИМО займет больше 4 недель. Если вы хотите, чтобы он был «идеальным», это может занять месяцы тестирования и подстройки. Особенно, если это многопользовательская игра.
Питер Олстед
@Psykocyber Очень верно! Но куча «очень хороших» программистов уже должна заниматься гибкой итеративной разработкой такого проекта, и я рассчитывал на это. Это также выходит за рамки вопроса. Ребята, начните новый вопрос: «Какова эффективная парадигма разработки для небольшой, ориентированной на технические достижения студии, которой нужно следовать, чтобы надежно выпускать полированные игры в короткие сроки?» Или как то так =)
Патрик Хьюз
14

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

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

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

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

инженер
источник
+1 млн «вовремя и под бюджетом» Я желаю я мог бы сделать это.
Стивен Фурлани
13

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

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

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

SimonW
источник