5
\$\begingroup\$

Considering that some game platforms are under NDA and that publishing code publicly 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, it needs to 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 for which 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.

\$\endgroup\$
5
  • \$\begingroup\$ Cool question. Maybe with the use of pre-processing instructions and different targets? Would that suffice? Do you know of any actual case? \$\endgroup\$
    – Herp
    Jan 27, 2014 at 13:06
  • \$\begingroup\$ Well the problem comes when publishing the code, if the engine is open source. Preprocessor directives are still in the code. The problem here is to be able to release code while keeping what "mentions" some platforms under NDA, hidden. \$\endgroup\$
    – nialna2
    Jan 27, 2014 at 14:24
  • \$\begingroup\$ I see. Silly me. \$\endgroup\$
    – Herp
    Jan 27, 2014 at 14:46
  • \$\begingroup\$ In this case I would suggest using techniques like dependency injection to dynamically inject your references instead of statically linking your libraries in the project. \$\endgroup\$
    – Dadgron
    Jan 27, 2014 at 16:35
  • \$\begingroup\$ "Keeping it entirely separate … seems hard." Why? \$\endgroup\$
    – BRPocock
    Mar 23, 2016 at 14:07

1 Answer 1

1
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ Okay but that solution implies having a codebase for each platform. Meaning that when you want to update/maintain, you multiply the work for every platform you have to support. Sometimes two platforms may have very similar code that don't need to be separated/duplicated for each platform, but due to NDA you can't publish all of them in the same codebase \$\endgroup\$
    – nialna2
    Jan 27, 2014 at 14:23
  • \$\begingroup\$ What about an elaborate build script? With MSBuild you should be able to include/exclude references at compile time and I think also source code based on different compilation configurations. Can your Open Source source code be compiled without the NDA-covered portions? Or, can they be changed so to derive from the open source versions? If you remove NDA-covered classes from your repository, then you can re-add them only on your local machine at compile time. \$\endgroup\$ Jan 27, 2014 at 14:45
  • \$\begingroup\$ This sounds a good way to manage it. Although open source contributions would be hard to manage. Since the "open source code" would be a built version of the core code, which the contributors can't access... \$\endgroup\$
    – nialna2
    Jan 27, 2014 at 15:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .