Как игровые компании обрабатывают программирование для нескольких платформ?

Игровые компании делают это двумя способами:

1) Написание / использование мультиплатформенного движка 2) Перенос игры

Мультиплатформенный движок будет содержать абстракции для действий, зависящих от платформы (выполнение вызова Windows API, рендеринг в DirectX против OpenGL и т. Д.), Чтобы всю работу можно было выполнить один раз, а затем построить для обоих. машины. Обычно это вопрос написания простых методов оболочки для таких вещей, как вызовы Direct3D и тому подобное.Большинство новых игровых движков создаются с нуля с поддержкой мультиплатформенности. Другие добавляют поддержку мультиплатформенности.

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

По разным причинам портированные игры могут страдать от проблем с производительностью, как правило, несмотря на нечеткую графику. Взгляните на The Orange Box для PS3 или CoD: Modern Warfare для Wii, чтобы увидеть два примера сбоя портов. Для OB Valve передала на аутсорсинг задачу переноса игр в EA. Во втором случае Activision решила, что имеет больше смысла переносить игру на движке, разработанном для более мощного оборудования, на более слабую платформу, вместо того, чтобы строить игру на новом движке, разработанном для получения максимальной отдачи от Wii.

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

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

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

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

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

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

Я предполагаю, что отдел искусства и медиа одинаков для всех платформ.

Игровые компании используют коммерческое промежуточное ПО, такое как RenderWare, которое стоит недешево. Большинство игровых платформ также поддерживают среду C ++ для компиляции кода. Кроме того, большинство консолей поставляются с версией для разработчиков (например, для PlayStation), и есть симуляторы для тестирования большей части кода. Это промежуточное программное обеспечение теперь принадлежит EA (которая похожа на гигантского игрока в этой области). Создание 3D-игр - это не просто фреймворк. Большая часть игры создается из дизайнерского документа, который документирует ход игры и игровой процесс. Обложка выполняется в другом программном обеспечении (например, Maya и Lightwave) и в «моделях», которые являются игровыми персонажами.

Несмотря на то, что это может показаться ужасно большим объемом работы, когда дело доходит до кодирования, это не так уж и важно. Написание основных функций занимает неделю или восемь, остальное больше приходится на дизайн и планирование. Просто помните, что 3D составляет только 10% всей игры. Это мои два цента как бывшего разработчика игр.

Не обязательно связано с видеоиграми, но лучшее руководство по созданию многоплатформенного программного обеспечения я видел в GOF (http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612). Прочитайте пример по оконной системе.

Я бы сказал «в основном они этого не делают». Все деньги вкладываются в Windows или консоли, и многим консолям нужна эксклюзивная лицензия. Я видел несколько портов, но они всегда являются отдельной базой кода, разветвленной от предыдущей версии.

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

Однако, есть большая часть кода, который должен быть написан (и протестирован), который уникален для платформы. Например, большинство (если не весь) код, связанный с графическими картами, должен быть разным для Xbox 360 и PS3.

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

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

Однако это никогда не бывает идеальным. Вам всегда придется переносить часть кода. Если только вы не используете Adobe AIR, но ваша игра предназначена для консолей (а кто использует Adobe AIR для разработки НАСТОЯЩИХ игр?)

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

Например:

• XNA Framework может работать в Windows, Xbox и Windows Phone с почти одинаковой кодовой базой. (Примерно на 90% один и тот же код C # может работать на всех платформах.)
• Unity 3D поддерживает ПК, MAC, браузеры, iPhone, Wii, а также скоро будет поддерживать Android.

Существуют и другие подобные фреймворки.

Кроме того, большинство популярных игровых движков (например, Unreal и др.) Перенесены на несколько платформ.

Я помню, как читал интервью (или, возможно, это был план. файл / блог) Джон Кармак дал несколько лет назад. Он обсуждал разработку для нескольких платформ. (Если мне не изменяет память, это было примерно в то время, когда они выпускали игры для мобильных платформ). Он дал совет всегда нацеливаться на платформу с самыми низкими системными характеристиками, которые вы планируете поддерживать в первую очередь. Он аргументировал это тем, что масштабировать гораздо легче, чем уменьшать. Если вы сосредоточитесь на новейшей высококачественной графике, вы, вероятно, попадете в зависимость от функций, доступных только на высоком уровне. Это делает очень трудным сокращение масштабов для основных и низкопроизводительных систем. В любом случае, я подумал, что это очень хороший совет.

Очень часто используется #define (например, в коде C ++), поэтому перед компиляцией для указанной платформы включается или используется соответствующий код. В больших проектах иногда части игры совершенно разные, написаны в разных IDE и скомпилированы в разных (зависящих от платформы) компиляторах.

Пример из моего опыта: Когда я работал над игрой для Nintendo Wii, мы использовали игровой движок Torque. Мы программировали на ПК и компилировали код для ПК. Когда некоторые функции были готовы, мы использовали Metrowerks CodeWarrior (со специальным набором библиотек и т. Д.), Чтобы скомпилировать его для Nintendo Wii, отправить в devkit и затем запустить с консоли Nintendo Wii.