Noob question: Can the Godot system support parallel versions of the codebase in the same compiled product?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By DavidPesta
:warning: Old Version Published before Godot 3 was released.

I believe I have some development requirements that are a little peculiar, but necessary for what I am doing.

Let’s say I have two game modes:
“Demo” and “Full”

(There’s actually many more than this, but those two serve as a good mental model for my question.)

Both modes “Demo” and “Full” share the same assets (images, music, etc).

But, both modes have a different codebase. In fact, the codebases are completely incompatible with one another, though some of their objects are analogous and have the same names. A lot may be very different about these similarly named objects between modes.

Does Godot make it possible for these two codebases to coexist separately, and only access one or the other in the runtime if the condition for that mode is met?

My concern is, if some objects between the two are analogous and have the same names, there might be a name collision in the project and it won’t build or work properly.

I might be able to get a little more specific with this example.

Can you foresee a Godot workflow that allows for something like the following:
“version1” codebase is copied to “version2” where many improvements are made. “version2” codebase is copied to “version3” where many improvements are made. And on and on. But, “version1”, “version2”, and “version3” all remain perfectly accessible in the same runtime and earlier versions continue behaving exactly as they did before the later versions were added.

I know this may sound like a strange requirement, and I apologize for that, but is this possible?

Many thanks in advance for your answers!

:bust_in_silhouette: Reply From: Zylann

It looks like you are describing version control, which is doable with software like Git, Mercurial, Perforce etc.

In Godot 3 there is a way to specify multiple export types (PC, Android, Android HQ, Android demo, anything you want), and I believe each of them can choose or exclude some files of the project but I’m not sure.

Other than that, it’s up to you to organize this, notably using the features Godot provides (it needs good knowledge of the engine before you go into this). Scenes can inherit others, they can be loaded dynamically, scripts can inherit too, load and compose other scripts if needed (since scripts are resources, just like scenes), be put in different folders if they have the same name with some conventions etc.
You would have the same issues with a project made in any other framework anyways.

Though if you want any versions to stay accessible and ALSO replicate into their newer versions automatically… then honestly this extends far beyond just Godot, it’s something very custom (and an uncommon decision I have to admit), the only idea I have in mind is to use inheritance (which Godot supports both with scripts and scenes, but it sounds quite dirty if done on “versions” because you could end up with a reeaaaaaallly big inheritance chain), use a homemade asset convention, or again, make a clever use of version control software.

Note: after re-reading the question I see that you want to have all those versions into the same executable… so it makes use of version control software even trickier. So I will simply emphasise that you basically need pretty special organization. Make yourself familiar to all engine features first, then you’ll have the knowledge to apply your rules to setup your project organization, and then, you will be able to see what are the good sides and eventual problems that could rise.

You really took the time to address my question, and I appreciate it. Does your Godot experience tell you that it is practical for me to write an automated script that changes Godot files so that all object names change? I could append “v1_”, “v2_”, etc to the beginning of all object file names for each of the different versions.

Another, perhaps related question. And maybe a solution. Does Godot make possible a way to create a tiny program that progressively downloads game areas like “containers” from my own server? I’ve noticed a few apps that have the ability to download additional content on the fly and then be able to access that content after it is downloaded. The parent app never needs to be updated. Something like this might be ideal for me. And it might solve the problem if each “container” is a different version of the same game.

By the way, I love Git and I use it extensively. But this isn’t a question about version control. All in-game versions will exist inside of the same Git version. My finished compiled app will know nothing of my use of Git. I want the player of the game to be able to switch between different in-game versions at any moment while they are using it.

I know that sounds strange, but there is a good reason why I want to be able to do this.

DavidPesta | 2017-11-12 13:40

Basically you want to duplicate everything?
An option could be to do separate pck files for each version and have a script that loads the corresponding resource.
The problem is that you want to keep the old files in the same git version, could be easier with branches and just pack “patches” (loading pcks overwrite resources).

eons | 2017-11-14 09:34