Как я могу узнать о разработке кроссплатформенных игр? - PullRequest
6 голосов
/ 17 июня 2009

Как таким компаниям, как Valve, удается выпускать игры для всех трех основных игровых платформ? Меня интересуют лучшие практики совместного использования кода, особенно между Windows, Xbox360 и PS3, поскольку идеальным решением является повторное использование максимально возможного количества кода вместо переписывания всего кода для каждой платформы.

Ответы [ 7 ]

6 голосов
/ 17 июня 2009

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

Обратите внимание, что модель потоков в Cell достаточно необычна, поэтому выполнение потоков "в общем" требует некоторой осторожности. Я не сотрудник Valve, и я не знаю ни одного из их секретов, но, насколько я понимаю, большинство разработчиков игр, которые хотят использовать PS3, используют очередь заданий, из которой процессоры отдельных ячеек отбирают задачи по мере необходимости. Это не обязательно лучший способ использовать Cell, но он прекрасно подходит для более традиционных моделей потоков (таких как frex, модель, которую используют оба ПК и 360).

4 голосов
/ 18 июня 2009

Существует множество статей из Game Developer Magazine и GDC на эту тему. Фактически, поскольку вы упомянули Valve, они выступили с докладом, описывающим их подход на GDC08.

Это действительно огромная тема, о которой я мог бы (и должен был) говорить часами, но резюме лифта таково:

  • Определите, какие части двигателя полностью зависят от платформы, и поместите их за абстракцию. Например, для каждой консоли необходимо переписать загрузку файлов и ресурсов; но вы можете скрыть это за интерфейсом IFileSystem, который предоставляет единый API, с которым взаимодействует код игры.
  • PS3 делает это сложно, потому что его точка абстракции должна где-то совершенно отличаться от других платформ. Даже игровые функции, такие как столкновение и навигация, должны быть написаны по-разному для ячейки.
  • Постарайтесь сохранить листовой игровой код (сущности, AI, sim) как можно более независимым от платформы ...
  • Но примите к сведению, что даже самому листу игрового кода иногда требуются некоторые специфичные для платформы #ifdefs по соображениям производительности, памяти или TCR. Многие пользовательские интерфейсы должны быть переписаны, потому что у производителей противоречивые требования сертификации.
  • Любой, кто произносит слова «я не беспокоюсь о производительности» или «память не проблема», не должен участвовать в расчетах.
3 голосов
/ 21 июня 2009

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

Я помню, что у программистов в DOS все время были нулевые указатели, потому что запись в нехватку памяти не сразу их приводила к сбою. Когда вы портируете на Amiga, Atari ST или Macintosh, бум! Я помню, как говорил программисту DOS, что у него есть пара нулевых указателей на игру, поставляемую в ареальном виде. Он подумал пару секунд и ухмыльнулся: «Это объясняет несколько вещей».

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

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

Мой опыт работы с C / C ++. Это большая проблема, если вам нужно портировать на разные языки (скажем, Java и Objective-c).

3 голосов
/ 21 июня 2009

Этот вопрос можно разделить на два отдельных вопроса. "Как я могу написать переносимый код?" и «Каковы различные требования основных игровых платформ?».

На первый вопрос относительно легко ответить. Рекомендации по абстрагированию вашего непереносимого кода описаны в разделе «Создание переносимого кода»: http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover

Реализуя теорию на практике, исходный код Quake 3 довольно неплохо делит разные платформы на отдельные области для базы кода C, доступной по адресу http://www.idsoftware.com/business/techdownloads/ Однако он не демонстрирует такие шаблоны C ++, как абстрактные интерфейсы, реализованные один раз для каждой платформы.

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

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

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

Наконец, если вы не можете заполучить консольный девкит, я предлагаю вам перенести код на Mac из Windows. Mac предоставляет вам порт ОС, гарантирующий, что вы не привязаны к Windows, а также порт процессора, если вы поддерживаете универсальные двоичные файлы. Это гарантирует, что ваш код не зависит от порядка байтов.

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

Приложение Вы писали:

идеальное решение - использовать как можно больше код как можно вместо переписывания все для каждой платформы

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

2 голосов
/ 17 июня 2009

Несколько лет назад генеральный директор Opera сказал в интервью, что ключом к разработке для независимых платформ является отказ от какой-либо одной библиотеки ОС / платформы. Он продолжил и сказал, что они разработали свои собственные библиотеки, которые улучшают производительность ОС.

Я предполагаю, что у крупных компаний будут общие, Xbox, PS, windows, FooOS, отдельные команды. Каждая платформа должна быть настроена по-разному и требует разных методов реализации. Я не думаю, что они делают один источник для всех платформ; скорее, они создают одну для каждой ОС, тем самым повышая эффективность. Я помню, что EA раньше выпускала некоторые консольные игры раньше, чем версии для ПК, и наоборот.

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

есть две крайности: создайте один источник, который подходит всем (например, java), но вы рискуете неэффективностью или пишете 40 версий; один оптимизирован для каждой платформы

1 голос
/ 18 июня 2009

Если вам нужны примеры с открытым исходным кодом, вы можете посмотреть исходный код движков Quake 1, 2 и 3. Они структурированы довольно мобильно. (Конечно, нет поддержки PS3 или Xbox360, но применяются те же принципы)

http://www.idsoftware.com/business/techdownloads/

1 голос
/ 17 июня 2009

Вернувшись, когда у меня был друг в образовательных компьютерных играх (до того, как The Learning Company потрясла сферу деятельности), он был большим поклонником создания кросс-платформенных библиотек для всего.

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

...