How to work on procedural assets

Kequc

Almost my entire game is generated procedurally and it's really hard to work because it's essentially an empty scene. Is there a way I can have the editor load in some dummy data and display basically any level so that I can see what I'm working on more easily? Maybe there's a tutorial about best practices.

llasram

@Kequc -- I'm aware of two faclities that help here:

If you have the main editor menu option "Debug"->"Sync Script Changes" turned on (and I believe it is by default), then whenever you save in the editor while an attached game scene is running, the editor will sync all code changes to the game process. Depending on the way your code is written, you'll either start to see changes right away, or may need to bind a key to force-reload the current scene etc.
Once you have code working how you like, you can put some of the behavior into a tool script which runs in the editor. The workflow for reloading tool scripts (closing the script and force-closing all scenes referencing it, then reopening) makes it awkward for code iteration, but I've found them useful for showing the effects of changing export variables, or for drawing the general shape/bounds of generated scene subtrees.

Good luck!

Kequc

The documentation about tool makes me a bit nervous, especially all the warnings about instancing nodes and adding them to the tree, needing to set their parent (?) afterwards. So on. Doesn't seem to be clearly documented how to remove nodes from the tree in the editor before running the scene and so on. Maybe I should just suck it up and keep thinking about my game abstractly.

dotted

You may be thinking "owner". Owner is important if you wanted to save the product scene tree (via the editor I think)

Of the warnings I have seen, they basically tell you to make sure your script works before adding 'tool'.

At worst if it breaks, you'll have to kill the editor and comment out the tool keyword the offending file.

You can also work with a Session design, where a Session node works as a tool and loads the scene from resource paths you define (or from data).

You can hack up some simple test in your session node to detect if you change a packed-scene or the data in the editor, and have it apply data, or use a boolean to trigger an update (which you first clear when it goes true)

Kequc

Something I've just tried is creating a tool node at the base of my scene, it's job is just to populate the editor scene with some stuff. But unfortunately to get anything to work it seems like I also need to give all of the other nodes the tool keyword. Otherwise I'm getting "cannot call such and such on null" where null should be a node in my tree with a script on it.

I don't feel comfortable throwing the tool keyword around so liberally.

Megalomaniak

Beyond really simple things you should probably be making editor plugins instead.

llasram

@Kequc -- Yeah, I've experienced some of the same awkwardness, but I've come to believe that awkwardness is mostly the editor making explicit an important distinction between two distinct purposes in-editor code can serve:

Visualizing run-time behavior; or
Enacting edit-time behavior.

I really like the example in the docs of a tool script drawing the firing arc of a cannon. Even though both the visualization and the behavior require many of the same calculations, they are clearly distinct. And a tool which placed canons in the current scene to be saved with the scene would be another thing entirely!

Can you give more detail about your current problem and what you are running into?

Kequc

Sure if you'd like! Although I'm not sure we'll be able to do it.

I'm building a 3d island out of simcity2000 style terrain, just very blocky slopes. You can preview what I'm talking about.

When the scene loads, an object containing all that tile data is passed to a render function. Which instances layers of the island, each their own scene, and populates each of them with polygons. So there's a couple of layers of scenes within scenes.

I can instance a scene and add it to the tree in the editor. But those instances also need to contain the tool keyword otherwise functions within scripts there won't work. Ultimately all I was really interested in was drawing some geometry in the editor, for the purpose of reference while I work on some other elements. But I'm thinking it's not worth polluting the code.

I attempted to have a separate node that only really run while in the editor to handle all of this. That would keep it separate but doesn't seem to be the way this works.

llasram

Oh, that's interesting! (And BTW, your video link is for the management page, but I was able to figure out what it should be.)

But -- now I'm even less clear on what you want to do with it in the editor hah.

I see two extremes:

If you mostly want to generate islands as a way of aiding in developing unique fixed content, then they do belong in the editor, and everything about this generation should run in the editor.
If you mostly want to generate islands at game-run time, then I don't understand why you want them in the editor at all, since you aren't then going to... er, edit them.

Maybe turning this around, what is it about interacting with a running scene using the editor scene and script sync features that isn't working for your workflow? From you've described so far, this sounds to me like exactly what you'd want -- you can iterate on code, updating the display of the generated content live, and inspect the live generated scene tree. So I'm probably missing something?

Kequc

In that case maybe I'm using the editor wrong altogether. My understanding is there isn't much point in making changes to your scene or code while the game is running. I'm just always starting and stopping the game to see if anything I've done works.

The islands are generated in game, I'm not pre-calculating assets. But I'm doing a lot for example with regard to gui elements that are cast on the island. So I have to guess a lot, I have to fiddle with transforms. I need to try and figure out where things will show up in the scene.

I'm not making changes to the island in the editor.

I'd be using it as a guide. Maybe I should figure out how to render something in the editor and then somehow keep it for dev purposes. The island is rendered using gridmaps which I don't think will be especially simple to take a "snapshot" of and save the resulting mesh.

So I'm stuck just starting and stopping the game all the time.

llasram

@Kequc said: My understanding is there isn't much point in making changes to your scene or code while the game is running. I'm just always starting and stopping the game to see if anything I've done works.

I'm honestly not finding official documentation on the sync features, at least with a quick Google search, but here's the GDQuest "Sync Script and Scene Changes" video. It's pretty magical.

If you're generating a big chunk of your scene tree dynamically at runtime then you might need to reload the scene. I've been defining a new debug_reload input action then having a node in my static scene tree which is mostly just:

func _input(event: InputEvent):
    if not event.is_action_pressed("debug_reload"):
        return
    get_tree().set_input_as_handled()
    get_tree().reload_current_scene()

The islands are generated in game, I'm not pre-calculating assets. But I'm doing a lot for example with regard to gui elements that are cast on the island.

Yeah, this seems like a kind of thing where you want a hybrid workflow: edit the GUI itself in the editor, syncing instanced scene tree changes live, and then have something in place that re-runs the code figuring out where to place the GUI as it code-syncs, by either re-running it periodically or tying it to a set of more specific computations bound to an action like the whole-scene reload above.

Definitely tighter iteration options than just re-launching the scene for each change!

Kequc

Huh neat. So I have been using the editor wrong altogether. I never even stopped to consider what those checkboxes might do, thanks for letting me know I'll definitely experiment with that information. I wonder if I can explicitly reload specific scenes within my scene too, maybe there's a helper for that? I can just script it to reload manually too.

At least there's options. Starting and stopping my scene all the time and trying to get things right that way was starting to be a drag I'm really happy to see there are alternatives.