Game Engines: how to keep different platforms code in separate plugins?

| | August 6, 2015

Considering that some game platforms are under NDA (mostly, the good old console trinity) and that publishing code using their SDK is not allowed, how do game engine usually manage keeping plugins for different platforms separated?

For example if I make a plugin for PS3 export, that will be distributed only to people that do have the PS3 license.

Platform code can happen in many places of the code, and keeping it entirely separated from the core engine seems really hard/impossible to manage to me.

Edit for example:

If I make an open source game engine that users are allowed to see the code, it means that the core engine is entirely viewable. Using preprocessors or anything like that would allow people to view code subjected to NDA, which doesn’t work.

So, the platform-specific code needs to be totally separate from the core engine, but the core engine needs to be able to use it. The most obvious solution is to duplicate implementations of system things for every platform, and when using a plugin you select which implementation you use, but it seems very hard to maintain.

Also, in my case preprocessors directives are not available. I am looking for a more general way of architecting the codebase to deal with these matters

One Response to “Game Engines: how to keep different platforms code in separate plugins?”

  1. Here’s how I did in my current project. I am developing a 2D User Interface library as part of my 3D engine. I am targeting several Windows environments: Windows 7/8 Desktop, Windows Store, Windows Phone OS. Although they are all based on Microsoft technologies, they are sufficiently distinct that they require different implementations. Such as the differences between net4x APIs and the RT PCL subset

    In the case of my UI library, I have a main assembly that handles the internal logic of the UI controls (and it is a PCL library). For example it defines what happens when a control is intersected by a point (an intermediate, platform-agnostic point structure, not related to any real-world platform implementation), how to layout them and so on. It provides base classes for all controls supported by the library. There is a LabelBase, ButtonBase, PanelBase, and so on.

    Then I have different subassemblies: one for net4x/RT and one for Windows Phone. The first is able to use Direct2D for the actual rendering. As D2D is not yet available on WP8 (at least through SharpDX), the WP8 assembly builds control shapes manually by computing the needed vertices (or using “baked” pre-rendered controls). All controls in the platform specific assembly inherit from the abstract control in the main one. Basically they just add the functionality needed to render themselves through two base methods (i.e.: Initialize and Render or something of that sort).

    I use a similar logic for initializing the application. The .Windows assembly uses a form, .Windows8 uses XAML, WP8 uses something specific for that platform and so on. Networking is also supported through platform specific assemblies.

    I think that using preprocessor directives on a large scale soon gets messy and I don’t really like that. I only use it when it is unavoidable. For example right now you cannot have a PCL assembly that supports Desktop/Store/WP8. So the main assembly still needs to be recompiled, but that can be handled relatively easily through VS.

Leave a Reply