How to manage data in similar yet unique scenes while avoiding development hell?[SOLVED]

Godot Version

Currently using 4.2.2
Can update to 4.3

Question

Context: I am making a UI(menu based) game. Like an idle/clicker game. Each scene/feature(page) has similarities but, uniqueness from one another, such as the data displayed.

Statement: I am trying to setup a data system that will load the correct data for the individual pages without repeating myself(avoiding development hell).

  • I know that I can simply repeat myself with match statements but, this will lead to development hell…Especially when we are talking about multiple pages(scenes). Let alone when I have to make changes or the like…

  • I can use @exports but if I change the variable names, the data I input in the inspector is deleted. I could use dictionaries to hold the data to prevent data loss, but that can’t be ideal. I still run into the issue of repeating myself.

  • I can use the nodes/instantiated scenes in the scene tree but if I edit the names of the nodes in the scene, it will orphan/break the nodes/instantiated scenes in that scene tree.

All of this is development hell…

Summary: How can I load page(scene) specific data without running into game development hell?

What solutions can y’all provide, if any?
Ask away with questions. I can also elaborate more, if desired.

Thank you.

1 Like

here is hope it help

also here

2 Likes

Unsure if either video uses inherited scenes here, so worth a mention. Inherited scenes allow you to have a common base and/or scripts. You can create new scenes using a base scene and inherit from its script to implement derived behaviour. An example I like to post is from a recent turn-based game where every piece in the game is the same Unit class, with just one or two units having specialised behaviour (like player controlled units).

The base class and scene can export values that you’d then use custom Resources to define, e.g. like health or stats.

3 Likes

Click here!

2 Likes

Statements

  • Scene Inheritance is a thing and is useful.

  • while(free) youtube channel has some good content.

Questions

  • With scene inheritance, if I accidentally remove the inheritance, how would I reinstate it?
    A: I don’t think it’s possible, hence the warning when removing the inheritance. Have to recreate the inheritance/scene.

  • How would I prevent the data loss with @exports in the inspector when variable names are changed in the resource/other scripts?
    A: No built in way. Have to manually create a system to prevent loss.

Solution
Create a resource, populate it with your variables n such, then create individual resource files(the .tres) for each use. Create a system to manipulate the resource properties/members as desired. I currently have mine where it gets all properties from the resource and I filter through them, collecting my custom properties/members by string name prefixes/suffixes(begins_with / ends_with).

I can use a match statement to manipulate individual resources properties where needed. This isn’t ideal but, better than making individual dictionaries or the like for each page/mob/etc. with every(repeated) property and having to change values in mass on each change.

I’m not sure if it’s possible to completely remove the need to micro manage the properties of the individual resources by code. The @export works but, the risk of losing the non default values is a concern.

Thank you all.

1 Like

If the base has been assigned values, it keeps those values. A derived scene can always change them too (and likewise, reset them to the base value). Also great if you want to apply something to all the scenes that inherit from it too, for example. I think that’s what you mean anyway, apologies if not. Give it a go, you’ll see how it works and how easy and powerful it is. Good luck!

2 Likes

If i have lets say, 100 @exports, i painfully add unique data to each @export in the inspector. I decide the @export variable names need to be changed for what ever reason, all the painfully added unique data is gone(resets back to base(default/placeholder) values. Which means I’ll have to painfully reinstate all the unique data for each @export in the inspector that had their variable name changed.

Is there a way to prevent this from happening?

1 Like

There is no good way of doing that currently.
There is this issue open that aims at solving this problem, but it’s just in the discussion phase still.

One workaround proposed was to temporarily make your script a tool script and rename your variables as such:

@tool
extends Node

@export old_property: String
@export new_property: String = old_property

Or simply store your data in a different source, like an Excel sheet or JSON file and load your data this way.
None of these solutions are ideal of course, but I think these are the best you can get right now.

2 Likes

Thank you for this.

2 Likes

make data base and then just build the system this how AAA game is made
see also this

2 Likes

Having an external database might ease some of your pain. You can store all the data that belongs in your export variables in a .json and load it in with a tool script. I also have a data heavy project and I’m considering using this VS Code extension to generate my data. The file it generates is a very tidy .json (just rename the .dpo) so It’s very nearly drag and drop to get the data into godot.

1 Like