Future-planning when I make my projects mostly revolves around doing a little work right off the bat to avoid tedious work later on. One example I’ll give here is for those little buttons you see in the margins of the game that tell you what buttons do what. You’ll have seen them in Piczle games. “A to draw” kind of thing, “+ to pause”. Piczle Cross Adventure was developed with the idea that it wouldn’t just appear on the Nintendo Switch. However, the idea of manually changing all those graphics so that, say, a theoretical Playstation version would use graphical representations of the proper buttons, or a PC version would show keyboard keys drove me to create a little system using Unreal’s powerful BluePrints that handles all that dynamically.
There are a few steps in this process which I’ll walk through one by one. Let’s start with the assumption you want to keep all SKUs within one single project. Having to curate several different projects for several different SKUs would be a nightmare for small indie development. So I create an eNum (previously explained here) for each platform I think or hope to release the project on. I then add this as a variable in my game instance or game mode. For each SKU you just set the relevant platform, or to keep things visual you can set it in the Event Init.
Secondly, create all the button graphics. This will be a tedious process, but at least you only have to do it once. Import them all into your project, keeping them neatly organised by proper naming or putting them in subfolders.
Now, here comes the “trick”. Create a Material Parameter Collection and give it a scalar parameter called, let’s say, “platform”. Now create a master material for your button help graphics and drag this parameter collection straight into its material blueprint. Within this material I use this “platform” scalar parameter to choose between 1 of 4 possible textures.
These 4 textures are made into parameters. In this quick test example I created only masks for the buttons so I can also change the colour of the button help, but you could grab full colour textures and their individual alpha channels using this method as well if you want.
Now from this material I create a material instance for the “A button”. Within this instance I set the 4 texture parameters to point to the Switch version of the A button graphic, the XBox one, and whatever platform you think you’re going to build for in the future. This part takes a little time and is somewhat tedious, but once it’s done it’s done forever!
When you’re creating your interface, instead of pointing to the textures of these buttons, you refer to the material instance instead.
Now all you have to do is link the “platform” variable to the scalar parameter value of your parameter collection and every instance in the game currently active or yet to be rendered will switch to the relevant platform. If you’ve set your “platform” variable to Playstation you’ll see the X button instead of the Switch’s B button for example.
Even better, if you want to switch live, for example your PC version can use the XBox buttons if the player is using a controller but PC keys if they switch to mouse/keyboard input, you can link the below function to any input change and right in front of their eyes the button help graphics will change to the relevant ones for their currently used input.
The joy of using UE4 and BluePrints is the visual nature of the scripting. However things can get complicated fast so the more aspects you can slim down to single variable changes the better. With these switching button graphics, for example, I can mostly* ignore platform when I develop and test and then from the same project make builds for each SKU with a simple, single change in a drop-down eNUM variable.
(* Mostly, of course, as there are plenty of other pitfalls and tweaks one needs to be aware of. So again, putting tedious tasks like these behind you with a simple, variable-driven solution frees up your brain to tackle the more technically challenging differences between the various platforms)