Якісь поради щодо створення кросплатформних ігор? [зачинено]

Чи є якісь поради / рекомендації при створенні крос-платформної гри в C / C ++?

За шарами абстракції приховати все, що стосується платформи

Це означає такі речі, як візуалізація, аудіо, введення користувача та введення файлів. Один розповсюджений трюк, щоб абстрагувати те, що без примусу до покарання за виконання часу, є заголовки платформи-агностики з певними файлами реалізації:

// FileSystem.h
class FileSystem {
public:
    FileHandle OpenFile(const char * path);
    // other stuff...
}

// FileSystemWindows.cpp
FileHandle FileSystem::OpenFile(const char * path) {
    // call windows API...
}

Потім налаштуйте збірки для кожної платформи для складання відповідно до відповідного файлу .cpp.

Зробіть так, щоб ваші контент-конвеєри читалися в незалежних від платформи ресурсах та виводили вміст, орієнтований на платформу для кожної платформи

Наприклад, напишіть ваші текстури у форматі .tga або просто .psd, а потім встановіть конвеєр, який може автоматично перетворювати їх у різні формати, необхідні для платформи.

Не припускайте конкретного плану пам’яті чи витривалості ваших даних

Платформи можуть відрізнятися в порядку байтів, прокладці, вирівнюванні та розмірі слова. Будь-який код, який піклується про це, повинен бути ретельно перевірений на всіх платформах.

Тестуйте на всіх платформах постійно

Ви будете укушені платформи конкретних помилок. Ви б швидше покусали зараз, чи правильно, коли намагаєтесь вивести гру у двері?

• Використовуйте такий формат, як opengl / sdl, який дасть вам мінімум клопотів при переході з платформи на платформу.

• Переконайтеся, що ви знаєте, які платформи ви хочете підтримувати. Не використовуйте opengl лише тому, що ви думаєте, що в майбутньому ви хочете підтримати мульти платформу. Почніть так, як ви хочете продовжувати.

• Знайте, які обмеження на апаратні засоби існують на кожній з платформ, яку ви хочете підтримувати.

Намагайтеся уникати розкидання #if defined(_FOO_) ... #elif defined(_BAR_) ... #else ... #endifпо всьому коду.

Іноді це виглядає так, що це простіший шлях, але це доставить вам неприємності в перспективі. Вам слід спробувати обмежити їх власним файлом, щоб кожна реалізація платформи була самодостатньою.

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

Існує безліч бібліотек, які самі є кросплатформенними; вам не потрібно писати безпосередньо у OpenGL, щоб бігати куди завгодно. OGRE - прекрасний приклад механізму візуалізації, який працює на будь-якій платформі, яку ви хочете назвати.

На мій досвід, найбільше турбує ваша система збирання. Якщо ви розробляєте в Windows за допомогою Visual Studio, ваш код може збиратися в Linux, але у вас буде непростий час, щоб його легко створити . Подивіться на такі системи збирання, як CMake, які можуть використовувати ті самі інструкції побудови для генерації конкретних платформних файлів проектів (makefiles на Linux, VS Projects на Windows, XCode Projects на Mac тощо).

Коли ви пишете свої функції для збереження та завантаження файлів або спілкування по мережі, не забувайте про небезпеку .

Замість того, щоб читати велику структуру за допомогою одного виклику fread / fwrite або чогось такого низького рівня, створіть ReadByte / WriteByte та ReadFloat / WriteFloat. Тоді у вас буде менше місць для внесення змін, якщо ви вирішите націлити на іншу платформу пізніше.