Help creating new regional client/server builds

Development Pipeline & Plugins
, ,
1

I am wanting to know what the best way would be to support regional client/server builds which would have some differences in content, plugins/subsystems, configs etc. Currently we have been investigating meeting this goal by creating additional build targets (client/server) but I am having problems getting it set up. Is this the right approach to be taking to have alternate builds?

I also have the following requirements for the builds being produced:

  • Distinct build targets with their own names <MyProject><FeatureName>Client.Target vs. <MyProject>Client.Target
  • Easy to switch between either build
  • The different builds with have some minor code differences, but share a majority of their core functionality
  • The capability to build different configs (Development, Shipping, etc.) of each build (Server/Client)

I have attempted to add new build targets with no success. I am using Rider as my IDE and I have my project, called <MyProject>, with four build targets detailed in:

  • <MyProject>Game.Target.cs
  • <MyProject>Client.Target.cs
  • <MyProject>Editor.Target.cs
  • <MyProject>Server.Target.cs

I tried creating new build target files <MyProject><FeatureName>Client.Target.cs and <MyProject><FeatureName>Server.Target.cs, then adding Global definitions to handle any changes in the code that need to be compile with its respective build. These files were added to the Source folder of my project. However, they do not appear as options that can be switched to and built by Rider. Additionally when I attempt to generate project files after making these changes, each new target file has its own project created and is associated to this new project (the files themselves stay in the same location on disk).

I don’t know how to correctly add new build targets, any help is appreciated.

(Separate note related to generating project files)

I noticed that when I added a second build target file for the same target type if I ran Generate Project Files, the target file that came first alphabetically remained associated with my project while the other build target would have a new project created for it.

2

Hey there,

Lyra has some examples of separate target files, and you should still be able to add your own accordingly (inheriting as a good example). I’d strongly suggest maintaining a simple approach here. CustomConfig can be used to help support configuration segregation. You can also use (as you’ve alluded to) global defines here to help you gate functionality in compiled code.

I would strongly suggest using defines as a signal to your modules (*.Build.cs)), in which you can have some more nuanced behaviour around what modules to utilize (and by proxy, plugins to utilize). Alternatively, you have ExtraModuleNames available to you to fold in modules from the command line. Regarding why you may not see these reflected in Rider - this could very well just be a limitation of the rider project generation. Do you have this issue as well in visual studio, and can you still build the target (if not, please attach logs).

Regarding separate content, after speaking to my colleague [mention removed]​ the best suggestion here is to try and have one package with optional chunks, and have the code detect the region and behave accordingly at runtime. The rationale for this is that multiple packages (SKUs) have been a challenge to manage, so keeping the number as low as possible is advisable.

Julian