Разработчик, с которым я работаю, говорит мне, что независимые разработчики должны ориентироваться на оборудование, которому около шести или более лет (при максимальных настройках). Я понял, что нужно позволить всем, кто хочет играть в свою игру, играть в нее с приемлемой частотой кадров, независимо от того, сколько лет их оборудованию, но должны ли независимые разработчики ограничивать себя в использовании стиля искусства с низким поли, или создавать свои игры с учетом старого оборудования, в основном потому, что «большинство людей, которые играют в инди-игры, имеют старое оборудование?»
Есть ли какая-либо причина, позволяющая вашей игре работать с максимальными настройками для очень старого оборудования, даже если это уменьшит графические возможности для людей с более новым оборудованием?
Существуют ли какие-либо статистические данные, показывающие, что игры, которые легко достигают своих верхних графических ограничений на старом оборудовании, более успешны, чем игры, которые поднимают свои верхние графические пределы выше при дороговизне «менее чем лучшего» опыта для игроков на старом оборудовании ?
Любое понимание этого будет с благодарностью.
Ответы:
В эту эпоху старое оборудование стало неправильным. Старое оборудование не обязательно медленное. 6 лет - это 2009, и DirectX11 уже существует. У нас все еще нет много нового сегодня.
Вам нужно учитывать две вещи:
функции
Это уровень инструкций, который будет поддерживать оборудование, DirectX9,10,11 или что-то OpenGL (это зависит от драйверов). И набор инструкций процессора: SSE4, AVX ..
Это самая большая головная боль, обычно возникающая в процессе развития, масштабируемость с которыми сложнее, чем масштабируемость, связанная с мощью. В DirectX9 было что-то, что вызывалось
techniqueв.fxфайлах для отката в обоих случаях. Но для инструкций процессора вам нужно несколько исполняемых файлов или большие разделы ветвления в вашей программе. Или не используйте их.К счастью, сегодня даже 6 лет - короткий срок, и у вас будет доступ ко всему, что вам нужно, даже на «старом» оборудовании.
сила
Это та точка, которая должна масштабироваться, на сегодняшней машине, а не на устаревшей машине. Высокий конец 2009 года потенциально оснащен GeForce GTX280, он очень мощный и гораздо более мощный, чем ваш низкоуровневый APU AMD A6-3650 или что-то в этом роде.
Нужно понимать гигантский разрыв производительности между низкими и старшими современными машинами. Потому что это в значительной степени превышает разрыв производительности ваших 6-летних машин в высококлассном масштабе.
Таким образом, это не рассмотрение рынка относительно обновления, это рассмотрение рынка относительно первоначального бюджета покупки. И если вам нужно ориентироваться на современные ноутбуки или настольные компьютеры низкого уровня, вам все равно придется масштабироваться, причем намного больше, чем вы думаете.
Попробуйте позаботиться о разрешении, скорости заполнения пикселей и пропускной способности графической памяти. Вы играете на этих факторах благодаря количеству проходов экрана, ширине вашего Gbuffer, если у вас есть отложенное затенение (очень дорого на младших машинах), разрешению ваших текстур и их количеству, присутствующему на экране в любой момент времени t .. Многоугольник не будет проблемой, если вы не ориентируетесь на оборудование 2002 года. Сложность ALU / FPU шейдеров также не будет проблемой, если вы не нацелены на оборудование 2005/2006.
источник
Я не могу вспомнить, где я впервые услышал это, но это старое эмпирическое правило, которое не выдерживает много критических мыслей. Поистине, все сводится к бизнес-целям. Если вы не планируете продавать игру, это не имеет значения.
Дело в том, что чем больше аппаратного обеспечения вы поддерживаете, тем больше будет ваш потенциальный рынок. Однако большинство независимых разработчиков в любом случае не будут располагать ресурсами для поддержки даже самых современных аппаратных средств, потому что для того, чтобы воспользоваться преимуществами упомянутого аппаратного обеспечения, им придется потратить немало средств на контент . Любой независимый разработчик, которому нужно беспокоиться об этом, обычно имеет ресурсы, чтобы выяснить, какие системные спецификации им нужны, и это, вероятно, информация, которую вы можете купить. Например, Steam собирает эту статистику и, вероятно, перепродает ее разработчикам.
источник
Как правило, чем шире набор оборудования, на котором будет работать любая программа, тем больше у вас будет возможностей продать копию. Сколько разнообразия вы можете поддержать, во многом зависит от игры. Такая игра, как Dwarf Fortress, может быть легко масштабируемой как с точки зрения требований к обработке, так и с точки зрения графики. А FPS с реалистичной физикой вроде Amnesia не так уж и много. Мое предложение было бы написать вашу игру, чтобы она могла работать на самом широком наборе аппаратного обеспечения и при этом дать хороший опыт. Вам не обязательно поддерживать его сразу, но возможность перенастроить его на более новое / старое / просто отличное оборудование легко принесет дивиденды по мере роста вашей фан-базы и развития технологий.
Есть две вещи, которые сделают вашу жизнь намного проще, когда она заставит вашу игру работать на множестве устройств, и они имеют мало общего с возрастом оборудования, на которое вы нацелены (по крайней мере, напрямую):
1) Если возможно, отделите бэкэнд от внешнего интерфейса. Если часть, которая выполняет математические расчеты о том, какие части выполняют что и где, имеет четко определенный интерфейс для передачи этой информации в часть, которая отображает ее на экране и принимает пользовательский ввод, то вы можете легче ее настроить (обычно это интерфейс ) на новое оборудование, не связываясь с другим. Если писать так, многим видам игр можно было бы дать интерфейсы, начиная от первоклассной трехмерной графики, заканчивая анимированными спрайтами на веб-странице и заканчивая чисто текстовыми символами ASCII. На этом этапе вы можете выбрать, что реализовать, исходя из того, кто, по вашему мнению, купит игру сейчас. И вы можете перейти к новым схемам вывода по мере того, как люди проявляют интерес - без необходимости связываться с ядром игры.
2) Как можно больше, пишите переносимый код. В зависимости от конкретного поведения DirectX 9.3c или чего-либо еще, вы можете сделать это быстрее, но когда вы поймете, что должны выпустить версию для Android, вам придется переделать много работы. Выбор библиотек и языков, которые не зависят от одного поставщика и которые следуют открытым и четко определенным стандартам, серьезно снизит вашу рабочую нагрузку в долгосрочной перспективе. Помните: написание программы обычно является крошечной частью работы по сравнению с обслуживанием программы. (Если вы не придерживаетесь бизнес-модели "запланированного устаревания", но это вряд ли даст вам большую базу поклонников в долгосрочной перспективе.)
источник