Почему так сложно портировать игры на PC — кратко и просто о долгом и трудном. Портирование программного обеспечения
Портирование игр - это действительно нелегкая задача для разработчиков, даже если речь идет о выпуске игры на ПК, где она, собственно, и разрабатывалась. И в этой статье один из основателей студии Disparity Games Джейсон Старк (Jason Stark) расскажет, с какими трудностями сталкиваются его коллеги по цеху.
Вопросы сооснователю Disparity Games задавали журналисты сайта PC Gamer. Материал подготовлен на основе англоязычной .
Как портируют игры на ПК
Геймеры спрашивают, почему разработчики просто не могут выпустить ту версию игры, которую они делали на PC во время тестирования. А когда они делают это и выпускают забагованный билд, те же геймеры сетуют на ошибки и винят девелоперов в лени.— Джейсон Старк, сооснователь Disparity Games
Чтобы понять всю сложность процесса, достаточно просто представить, как много компонентов имеет любой современный компьютер. Различное «железо», тысячи версий драйверов, и иногда очень трудно предугадать, как их связка поведет себя в тех или иных условиях.
Даже хорошо оптимизированные и отлаженные игры часто работают не так, как нужно, если компьютер имеет специфический набор ПО и комплектующих. В этом смысле вопрос «хорошего» или «плохого» порта - это скорее вопрос вложения денег и времени: сколько ресурсов готов потратить разработчик, чтобы обеспечить наибольшую совместимость? Впрочем, абсолютный идеал все равно недостижим.
Перенести игру на консоли тяжело, но в случае возникновения бага на одном Xbox One, ты будешь знать, что то же самое будет на всех остальных Xbox One.
Больше платформ - больше проблем
При портировании игры разработчик фактически создает ее уникальную версию. Это означает, что выбор каждой дополнительной платформы для выпуска игры увеличивает релиза на порядок. Это умножение, а не сложение. В случае нескольких платформ нужно не только выпускать, но еще и быстро реагировать на всевозможные проблемы, оперативно решать их.
Каждый патч или обновление нужно тестировать на каждой платформе отдельно. И только если ни на одной не возникло проблем, выпускать это в «паблик». Ведь безобидный «фикс» на одной платформе может вызывать критический сбой на другой. Нужно учитывать кучу факторов и особенности архитектуры каждой среды.
Создание ПК-порта игры с прошлого поколения консолей тоже довольно проблемное дело. Проект, который ранее запускался в 30 fps, далеко не всегда можно быстро «завести» в 60. А игры из прошлого десятилетия нельзя по мановению руки адаптировать к 4K-разрешению, как бы просто это не казалось.
По факту многие игры создавались именно под 30 кадров в секунду, на основе этого фреймрейта писалась их логика. Например, в смена частоты на 60 fps привела к удвоению урона, так как боевая часть учитывала смену кадров.
Также многие помнят баг, из-за которого в PC-версии оружие портилось в 2 раза быстрее. Чтобы исправить эту простую, казалось бы, проблему, разработчикам из From Software потребовался год!
Когда проще сделать игру заново
Чтобы некоторые игры, приходится их переписывать буквально с нуля: изменять программный код, переделывать графические элементы. Такое произошло, например, с PC-версией . А переиздание вообще пришлось делать с заново, так как большая часть исходного кода была утеряна.
Короче говоря, портирование - это довольно . Но вместе с этим разработчик должен стремиться к тому, чтобы все версии одной и той же игры были похожи по своему функционалу и внешнему виду. При этом зачастую это невозможно на практике из-за кардинальных различий между платформами. А также из-за необходимости соблюдать лицензионные соглашения.
Вы редко слышите негативные рассказы о портировании игр, потому что в интересы разработчика не входит посвящать третьи лица в требования платформодержателей. Им не хочется читать критику в свой адрес.
Особенности продвижения
Если на минутку забыть о технических вопросах, то выпуск игр на разных платформах все равно является очень трудным делом. Ведь если игра выходит на системе, ее нужно продавать тем, кто этой системой пользуется. Нужно искать популярных «ютуберов», налаживать связь с сообществом игроков, делать промо-материалы для каждой платформы в отдельности.
Например, в коллективе из 20 человек вопросами продвижения могут заниматься трое. Они не участвуют в разработке как таковой, только занимаются изданием, маркетингом и продажами. Для маленьких студий вопрос выхода на нескольких платформах - это серьезная головная боль: рук не хватает.
К тому же никто не отменял непреднамеренных вещей вроде выпуска портов разного уровня качества. Это иногда выходит само собой, но игроки почти всегда начинают обвинять разработчиков в том, что они «продались» и перетянуть игроков на другую платформу. Хотя на самом деле большинство разработчиков хотят выпустить хороший порт для любой системы, просто не всегда это получается.
Впрочем, бывает и обратное, когда выходит переиздание какой-то древней игры и она пробивает чарты продаж. В таких случаях игроки готовы платить хорошие деньги, чтобы получить улучшенную версию любимой игры, так как это отличный способ отблагодарить девелопера за хорошую работу.
Отличающейся от той среды, под которую она была изначально написана с максимальным сохранением её пользовательских свойств. В этом основное отличие понятий порт и форк - в первом случае все пользовательские свойства пакета стараются сохранить, а во втором - это базирующаяся на общей основе самостоятельная разработка с новыми полезными свойствами.
Процесс портирования также называют портированием или переносом , а результат - портом . Но в любом случае главной задачей при портировании является сохранение привычных пользователю интерфейса и приёмов работы с пакетом и его свойств. Добавление новых или удаление части имеющихся свойств при портировании программных продуктов не допускается.
Портирование - включение кода программы в работу Аппаратно-программного обеспечения.
Портируемость (переносимость, англ. portability ) обычно относится к одной из двух вещей:
Необходимость в выполнении портирования возникает обычно из-за различий в системе команд процессора , различий между способами взаимодействия операционной системы и программ (API - Application Program Interface), принципиальных различий в архитектуре вычислительных систем, либо по причине некоторых несовместимостей или даже полного отсутствия используемого языка программирования в целевом окружении.
Международные стандарты (в частности, продвигаемые ISO) значительно упрощают портирование , благодаря тому что они описывают среду исполнения программ таким образом, что различия между платформами становятся минимальными. Часто портирование программ между платформами, реализующими один и тот же стандарт (такой как POSIX .1 ) сводятся к перекомпиляции программы на новой платформе.
Существует также всё расширяющийся набор инструментов, облегчающих портирование, например, таких как GCC , предоставляющий неизменный язык программирования на различных платформах.
Некоторые языки программирования высокого уровня (Eiffel , Esterel) достигают портируемости путем трансляции исходного кода в промежуточный язык, имеющий компиляторы для многих процессоров и операционных систем.
Термин портирование часто применяется к компьютерным играм , а именно, к процессу переноса компьютерной игры с первоначальной целевой платформы (персонального компьютера или игровой приставки) на другую платформу. Ранние порты видеоигр, по сути, были результатом значительного или полного переписывания программы, но всё больше современных игр разрабатывается с использованием программного обеспечения, позволяющего генерировать код как для PC так и для одной или нескольких игровых консолей.
В зависимости от того, для чего первоначально разрабатывалось то или иное программное обеспечение , его называют родным или портированным. Родное (англ. native ) ПО разрабатывается сразу для той платформы (аппаратного обеспечения и/или операционной системы), о которой идёт речь. Портированное (англ. ported ) ПО разрабатывается для одних платформ, после чего переносится для работы на других платформах.
Примеры
См. также
Примечания
Литература
- Andrew S. Tanenbaum (1984): Structured computer organization 10th Print. ISBN 0-13-854605-3 .
- Brian Hook. Write portable code: an introduction to developing software for multiple platforms - No Starch Press, 2005; ISBN 1-59327-056-9
Wikimedia Foundation . 2010 .
Смотреть что такое "Портирование программного обеспечения" в других словарях:
В программировании, под портированием понимают адаптацию некоторой программы или её части, с тем чтобы она работала в другой среде, отличающейся от той среды, под которую она была изначально написана. Процесс портирования также называют портингом … Википедия
В программировании, под портированием понимают адаптацию некоторой программы или её части, с тем чтобы она работала в другой среде, отличающейся от той среды, под которую она была изначально написана. Процесс портирования также называют портингом … Википедия
NetBSD Packages Collection (pkgsrc) система управления пакетами, позволяющая устанавливать, обновлять и удалять программное обеспечение посредством одной команды. После сборки программного обеспечения, управление им осуществляется с помощью… … Википедия
Тип управление пакетами Разработчик Alistair Crooks, Hubert Feyrer и Johnny C. Lam Написана на C Операционная система Unix подобные Лицензия B … Википедия
Высокоуровневый язык программирования язык программирования, разработанный для быстроты и удобства использования программистом. Основная черта высокоуровневых языков это абстракция, то есть введение смысловых конструкций, кратко… … Википедия
Высокоуровневый язык программирования язык программирования, разработанный для быстроты и удобства использования программистом. Основная черта высокоуровневых языков это абстракция, то есть введение смысловых конструкций, кратко описывающих такие … Википедия
Высокоуровневый язык программирования язык программирования, разработанный для быстроты и удобства использования программистом. Основная черта высокоуровневых языков это абстракция, то есть введение смысловых конструкций, кратко описывающих такие … Википедия
В зависимости от того, для чего первоначально разрабатывалось то или иное программное обеспечение, его называют родным или портированным. Родное (англ. native) ПО разрабатывается сразу для той платформы (аппаратного обеспечения и/или операционной … Википедия
На конференции разработчиков игр (Game Developers Conference - GDC), компании Valve и Nvidia выступили с докладом, посвящённым портированию игр под Linux. Презентация с данного мероприятия на сайте Nvidia.
Наиболее интересные моменты:
- В качестве мотивов почему следует портировать игры на Linux, упоминаются:
- Открытость операционной системы Linux и экосистемы.
- Довольно быстрый рост популярности Linux в качестве игровой платформы.
- Логичный промежуточный шаг при портировании игр на мобильные платформы, где также доминируют стандарты семейства OpenGL
- Производительность.
- Под Linux официально доступен Steam.
- OpenGL предоставляет доступ к возможностям оборудования, оперируя при этом сугубо возможностями оборудования, а не версиями ОС или чем-либо ещё. В частности, в Китае в данный момент все ещё очень много пользователей с ОС семейства Windows XP, которые не могут пользоваться Direct3D 10/11. Тем не менее, при использовании OpenGL будут доступны полные возможности оборудования, в том числе и в данной версии ОС. Это позволит использовать возможности современного оборудования даже указанным пользователям.
- Публично доступные спецификации стандарта.
- Спецификации развиваются комитетом, в котором может принять участие любая заинтересованная сторона, для этого не требуются огромные суммы денег.
- OpenGL проще расширять, любой вендор может предложить свои расширения.
- OpenGL очень богат по своим возможностям.
- Для управления окнами настоятельно рекомендуют использовать SDL, относительно небольшую и кроссплатформенную библиотеку на Си. SDL берет на себя все что касается работы с окнами, независимо от ОС, в том числе и на мобильных платформах. Valve пользуется данной библиотекой при портировании своих проектов, что доказывает пригодность библиотеки для достаточно требовательных применений. Кроме того, основной разработчик libsdl в настоящее время работает в Valve.
- Проблемы с которыми столкнулись в Valve:
- Файловые системы в unix-подобных ОС по умолчанию чувствительны к регистру имён файлов, тогда как в Windows файловые системы по умолчанию игнорируют регистр. Для игр это, как правило, не является проблемой так как игровые ресурсы обычно поставляются в платформо-нейтральных контейнерах. Тем не менее, в процессе разработки это может быть проблемой. Наиболее простым решением является перевести имена всех ресурсов в нижний регистр.
- Ошибочные define`ы, например предполагающие, что на Linux может быть только выделенный игровой сервер и более ничего.
- Проблемы с локалью могут вызывать проблемы в функциях printf/scanf. Решение: установить локалью en_US.utf8, а локализацию предоставить самому приложению. Так как в некоторых случаях локаль en_US.utf8 в системе может отсутствовать, следует предусмотреть вывод предупреждения в данном случае.
- Шрифты: рекомендуется использовать библиотеки freetype и fontconfig. Тем не менее, может потребоваться пересчёт размера шрифтов.
- Использование RDTSC (прецизионный таймер, основанный на счётчике тактов современных CPU х86). Вместо него рекомендуется использовать вызов clock_gettime(CLOCK_MONOTONIC), не зависящий от архитектуры процессора.
- Использование raw mouse input, когда весь ввод мыши монопольно отправляется одной программе. Это очень хорошо работает для игр, однако некоторые оконные менеджеры при этом также перенаправляют и весь клавиатурный ввод. Это, в частности, может отключить работу alt-tab или аналогичных по смыслу горячих клавиш для переключения задач, что способно вызвать неудовольствие пользователей в некоторых ситуациях.
- Более шероховатая поддержка многомониторных конфигураций. Тем не менее, libsdl способна взять большую часть проблем на себя.
- Инструментарий:
- Steam Linux Runtime и SDK предоставляют разработчикам игр ABI, не зависящий от дистрибутива.
- Компилирование и отладка:
- gcc - для компилирования.
- gdb - для отладки.
- cgdb - интерфейс на основе curses
- ldd - отслеживание зависимостей бинарного файла от библиотек (эквивалент dumpbin).
- nm - предоставляет информацию о символах, используемых программой.
- objdump - дизассемблер и инструмент для просмотра подробных деталей о бинарных файлах.
- readelf - инструмент для получения подробной информации об ELF файлах (основной формат исполняемых файлов в Linux).
- make - средство сборки проекта.
- Анализ производительности - CPU:
- perf - свободный профайлер под Linux, использующий performance counters современных процессоров
- vtune - инструмент от компании Intel, также существующий и в версии под Linux.
- Telemetry - многие коммерческие разработчики игр уже и так используют данный инструментарий.
- Примерное соответствие OpenGL и Direct3D:
- Direct3D 9 примерно соответствует возможностям OpenGL2. Начиная с этой версии доступны шейдеры.
- Direct3D 10 примерно соответствует семейству OpenGL3, появилось более актуальное API. Реализованы геометрические шейдеры.
- Direct3D 11 примерно соответствует OpenGL4. Поддержка тесселяции и произвольных вычислений на шейдерах.
- Ключевые отличия Direct3D от OpenGL с точки зрения разработчика:
- В OpenGL у потоков есть локальные данные, поэтому:
- У потока может быть только один текущий контекст.
- Контекст может являться текущим только для одного потока.
- Вызовы в OpenGL из потока без текущего контекста согласно спецификации не должны иметь никакого эффекта.
- OpenGL основан на Си. Объекты передаются хэндлами.
- Многие функции вообще не требуют указания хэндла и оперируют на выбранном в данный момент объекте.
- Как правило хэндл имеет тип GLuint.
- OpenGL поддерживает расширения.
- Несмотря на то что OpenGL довольно многословен и на первый взгляд требует больше вызовов, он показывает впечатляющую эффективность и производительность.
- В OpenGL отсуствуют проблемы с потерей устройств.
- В OpenGL у потоков есть локальные данные, поэтому:
- Расширения OpenGL:
- Есть специфичные для поставщиков расширения с префиксами NV|AMD|APPLE. Тем не менее, ряд из них был реализован сразу несколькими поставщиками. Например, NV_bindless_texture.
- Расширения с префиксом EXT реализуются сразу многими поставщиками. Например, EXT_separate_shader_objects
- Расширения с префиксом ARB были рассмотрены и приняты комитетом развивающим стандарт. Например, ARB_multitexture.
- Базовые расширения (Core extensions): базовые возможности из более поздних версий стандартов OpenGL представляются как расширения относительно прошлой версии стандарта.
- Есть зависящие от специфики платформы расширения: WGL, GLX, AGL и EGL.
- Советы разработчикам:
- Поиск в интернете имеет смысл делать как с префиксом GL_ или gl у соответствующего вызова так и без него.
- Чтение спецификаций стандарта себя оправдывает многократно.
- Если вам не нравится текущее направление развития OpenGL, присоединитесь к Khronos Group и постарайтесь оказать влияние на развитие стандарта. Лучше всего определять свое будущее самому.
- Core vs Compatibility: Некоторые производители утверждают что использование core-профайлов будет быстрее чем compat-, однако по факту подтверждение данного тезиса обнаружить не удалось. Поэтому можно пользоваться тем, что проще и удобнее конкретному разработчику. * Наиболее полезные расширения OpenGL по мнению разработчиков: EXT_direct_state_access, EXT_swap_interval (и EXT_swap_control_tear), ARB_debug_output, ARB_texture_storage и ARB_sampler_objects. Кроме того отмечаются NVX_gpu_memory_info и GL_ATI_meminfo позволяющие получить информацию о использовании памяти GPU.
- Самые проблематичные места в плане производительности:
- Вызов MakeCurrent очень дорогой. Следует избегать его вызова даже 1 раз на кадр.
- Современные драйвера как правило используют более 1 потока. Программа по факту взаимодействует с относительно тонкой прослойкой которая может распределять работу на несколько потоков. Некоторые вызовы заставляют производить полный сброс буферов и ресинхронизацию между потоками что сильно просаживает скорость операций.
- Наиболее проблемными оказались функции glGet() и glGetError() (вместо этой функции рекомендуется использовать ARB_debug_output)