How to know my current Compiled Game Version?

TheSirFM · September 1, 2025, 12:11am

Hello everyone!

Let me explain my question.

I have a game, and I need to package it twice to have different versions of the same game, e.g., a normal version and a demo version.

Why do I want to do this?

Because the normal version of the game should have access to everything, and the demo version only has access to multiplayer. (Only a few specific maps, but it can also connect to a map it doesn’t have access to if created by a player who does have the game.)

And I find it very inconvenient to compile the game once and then have to edit blueprints to limit the content and put it in demo mode.

I’m currently facing the problem as follows:

Library Function:
with a bool IsDemoMode?
Returns True if it’s a demo.
Returns False if it’s the normal version.

Before compiling the demo version, I set this bool to true.

It works fine, but it’s very inconvenient to have to manually set it before compiling. And I’m looking for something like the GetPlatformName node that returns what platform the game is currently running.

I was thinking of using Project Launcher, but I don’t know if it works for this task, or at least I don’t know how.
I was thinking of creating two profiles like this.

Normal Game
Demo Game

and using Project Launcher, package it. And using a blueprint node, get the version of the game I’m running. For example:

GetGameVersionMode: Returns Normal or Demo depending on which build I’m running.

Does anyone know how this is done?
How are you addressing this issue with your projects?

Thanks for your time!

nande · September 1, 2025, 8:39am

hey, i’m not sure if this is gpt spam or youre a real person. but i’ll give you a short answer and if you’re a human i’ll expand.

you can do this however you want,. there are pros and cons to each.

you can either use a #define and have a function that returns true or false depending on it. i actually use that for my demo in my game.

on my build.cs

on my syssettings subsystem

this is the normal way of doing it. requires recompilation. i like it because it’s harder to “crack”. but it takes more care to not break stuff.

for less important things i have a system for flags, is free and open source, you can use it or inspire by it.

it allow me to set up flags, that can be set via config files, or via runtime. even change them using the console.

i expose the things that i want the user to change. and the things i don’t want the user to change, i don’t show, or i hide behind a check to IsDemo.

you can also use a cvar. cvars can be changed via command line. so you can have a .bat that changes to demo mode.

i have also a “features” subsystem, which is just a tset of enums. this is for things that are on/off.

i could have used the flag system, but i loved how simple and powerful this is.

all the rest uses the feat system.

UPROPERTY(BlueprintReadOnly, Transient)
TSet<EFeat> Feats;

these are debug or “power” flags that are not shown if it’s not a debug build.

i’ve also made a plugin with tons of utils. including a function that tells you if you’re in editor, pie, or debug.