разработка кроссплатформенных игр что искать?

Question

Я собираюсь начать игру через 3 недели, и мне бы очень хотелось, чтобы игра работала хотя бы на другой платформе (linux, MacOS), но моя команда считает, что это большая работа. Я согласен с этим, но хотел знать, что я должен остерегаться, но это не приведет к портированию на linux (кроме специфичных для Windows API, таких как DirectXsound)?

Я читал в Интернете, и функции "_s" Windows, такие как sprintf_s, существуют только в Windows; это правильно или они также реализованы в Linux?

Answer 1

Нет, функции _s НЕ реализованы в стандартной библиотеке gcc. (По крайней мере, очистка включаемых файлов для 'sprintf_s' вообще ничего не дает.)

Возможно, стоит посмотреть на кроссплатформенные библиотеки, такие как boost и apr , чтобы выполнить некоторые тяжелые работы.

Образец конкретных вещей для поиска:

• Вход / Выход (DirectX / SDL / OpenGL)
• Функциональность Win32 / windows.h (CreateThread и т. Д.)
• Использование элементов управления Windows в пользовательском интерфейсе
• Примитивы синхронизации (критические разделы, события)
• Filepaths (разделители каталогов, корневые имена)
• Реализации с широким набором символов (16 бит в Windows, 32 бит в Linux)
• Нет поддержки MFC в Linux (CString и т. Д.)

Answer 2

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

Я написал 3D-игру в качестве хобби-проекта с моим другом, сервер на Java и клиенты, работающие на Windows и Linux. В итоге мы использовали Ogre в качестве 3D-движка и OpenAL в качестве Sound-Engine, как независимые от платформы, так и доступные под LGPL.

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

Самым трудоёмким будет настроить весь проект для компиляции под Windows и Linux (или Mac), особенно если вы концентрируетесь на одном и только иногда проверяете другой на наличие проблем. Если в вашей команде есть человек, который регулярно проверяет эти проблемы во время их производства, у вас не будет таких больших накладных расходов.

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

Answer 3

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

Я бы также сделал его воспроизводимым на одной ОС, даже не задумываясь о портировании.

Answer 4

Я удивлен, что никто не упоминает libSDL и OpenGL, потому что большинство кроссплатформенных игр были написаны с использованием этих библиотек.

Если ваша игра 2D, вы можете использовать libSDL . Хороший пример игры, написанной на нем, - Битва за Веснот . SDL использует DirectX в Windows, это просто тонкая оболочка.

Если ваша игра 3D, используйте OpenGL . Например, Quake 3 использует эту библиотеку. Вы можете найти тонны примеров и документации по нему. Конечно, есть много библиотек, которые обертывают OpenGL, поэтому вам не нужно делать вещи низкого уровня. Посмотрите на OGRE, Crystal Space и т. Д.

Что касается базовой совместимости библиотек и функций C / C ++, то лучше установить немного Linux и просто запустить man-страницу для функции, чтобы увидеть, существует ли она. Вы можете найти это в Интернете .

Answer 5

Если вы действительно хотите легко заниматься кроссплатформенной разработкой, я бы предложил использовать один из уже созданных кроссплатформенных движков, таких как Unity, или один из компонентов Garage Games, например Torque Game Builder (2D).

У меня практически нет опыта в любом из них, поэтому я не могу сказать вам, что лучше, но демоверсия Torque Game Builder не смогла пройти первый урок без проблем, и они не отвечают на вопросы технической поддержки на своих форумах, как они Я могу сказать, что избегайте их, если вы новичок в игровом дизайне, как и я. Главной вещью в Garage Games должна была стать их отличная поддержка, я видел нулевую поддержку и на самом деле видел только кучу "Эй, кто-нибудь здесь?" посты без ответов, поэтому я думаю, что они в значительной степени разочарованы поддержкой своих продуктов.

http://unity3d.com/

http://www.garagegames.com/

Answer 6

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

Вы не должны вызывать sprintf_s напрямую, вы должны написать подпрограмму, класс или MACRO, которые могут быть изменены в зависимости от платформы. Не используйте DWORD, если вы можете использовать класс или typedef, которые могут быть адаптированы для разных платформ.

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

Answer 7

Не знаю много о windows-apis, но я установил ежедневную (или при фиксации) полностью автоматическую систему сборки на всех платформах, которые вы хотите поддерживать. Если вы разрабатываете что-то на своем Windows-боксе, которое не работает на других, ваша система сборки должна уведомить вас о «неудачной сборке на платформе x, подробности смотрите в файле журнала / attachment / whatnot». Это поймает много перекрестных проблем. Также помогут юниттесты.

Хорошая идея - ориентироваться на несколько платформ с самого начала - это другой вопрос.

Лично я бы начал разрабатывать на другой платформе, а потом посмотреть, как ее перенести в windows; -)

Answer 8

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

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

Так что на самом деле это зависит от вас.

Answer 9

Endianess - это то, на что нужно обратить внимание.

Endianess - это порядок битов в байте. Некоторые платформы с прямым порядком байтов, а некоторые с прямым порядком байтов.

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

Answer 10

Для «безопасных» функций: они нестандартные и почти безопасные:)