# Any tips for creating cross-platform games? [closed]

Do you have any tips/recommendations when creating a cross-platform game in C/C++?

Hide anything platform-specific behind abstraction layers

This means stuff like rendering, audio, user input, and file IO. One common trick to abstracting that without inducing a run-time performance penalty is platform-agnostic headers with platform-specific implementation files:

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

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


Then configure the builds for each platform to build against the proper .cpp file.

Make your content pipelines read in platform-independent assets and output platform-specific content for each platform

For example, author your textures as .tga or just .psd, then have a pipeline that can automatically convert those to the different platform-specific formats you need.

Don't assume a specific memory layout or endianness in your data

Platforms may vary in byte order, padding, alignment, and word size. Any code that cares about that must be thoroughly tested on all platforms.

Test on all platforms, all the time

You will get bitten by platform-specific bugs. Would you rather get bitten now, or right when you're trying to get the game out the door?

• lack of #ifdef PLATFORM_WIN ftw – tenpn Jul 18 '10 at 14:16
• You'll never escape that. You can just hope to minimize it. – munificent Jul 18 '10 at 18:06
• A good way to do that is to move all the platform specific code into a set shared libraries with the same interface then you can limit the #ifdef's to bootstrapping the correct library for the platform. – Neel Jul 22 '10 at 10:44
• +1, great comment. Remember that even the STL is platform-dependant (and yes, some functions do different things on different compilers). – Simon Aug 12 '10 at 6:18
• Surely calling an extra function will decrease performance? The CPU has to load or move data from registers or worse, memory which is still slow. Wouldn't a system call suffice? – TheBlueCat Jun 9 '13 at 18:49
• Use an api like opengl/sdl which will give you minimum hassle when going from platform to platform.

• Make sure you know what platforms you want to support. Don't use opengl just because you think you might want to support multi platform in the future. Start as you mean to go on.

• Know what hardware limitations are on each of the platforms you want to support.

• The second point cannot be stressed enough. Make sure you know who the game is aimed for (meaning that, if it's a casual game, you'd want to have it on at least OSX and Windows, thus OpenGL would be the best option). As for the third point - and this is where the engine comes into play - is also important. It would be illogical to use a feature-rich, resource-heavy engine like Unreal to make a DS game. The point is also related to what I said regarding the second one: Establish who the game is aimed for. If you're going for a casual game, most people's computers won't handle, say, particles. – Paker Jul 14 '10 at 20:58

Try to avoid scattering #if defined(_FOO_) ... #elif defined(_BAR_) ... #else ... #endif all over the code.

Sometimes it looks like the it's the easier way, but it will give you troubles in the long run. You should try to limit them to their own file, so that every platform implementation is self contained.

Adding a platform should be mostly about adding new implementation files, and just modify the few needed existing ones.

There are plenty of libraries that are themselves cross-platform; you don't need to write directly in OpenGL to run anywhere. OGRE is a great example of a rendering engine that works on any platform you'd care to name.

In my experience, the biggest concern is your build system. If you develop on Windows with Visual Studio, your code might compile in Linux, but you'll have a tough time getting it to build easily. Look at build systems like CMake that can use the same build instructions to generate platform-specific project files (makefiles on linux, VS Projects on windows, XCode Projects on Mac, etc).