Provide a "Getting Started" Godot project

[oparisy]

It would be nice for this project to provide some "Getting Started" Godot project. So I guess at a minimum a project.godot file, a scene and a script demonstrating using one of the provided example element? Something similar to this maybe?

I reckon that Exemple.h is from the godot-cpp tutorial (which is nice because it covers many constructs), and so that it does not serve a specific purpose. I understand also that GDextensionTemplate is "power user" oriented, so that you may expect users to start modifying and integrating it right away in their own project.

But still it would be useful to be able to make sure that compilation went properly by being able to open a provided Godot project. Also starting from a complete, working project is easier even if it's a template destined to be modified and built on.

[oparisy]

As an example it was frustrating to finally get compilation working after iterating with you, and to have nothing to "open" in Godot as a result 😃

[asmaloney]

I had considered this initially, but decided that it fell more on the "example" side than the "template" side. I didn't really want to include "extra stuff" in this project that would just have to be removed, but also didn't want to create an entire new repo for an example.

I can see value in providing a test project even after this template project has been "instantiated" though (the "testing" side). Still working through the development workflows as things change in Godot and godot-cpp.

I'll revisit this to see what might work.

Thanks again for the input! Much appreciated.

[gcardozo123]

I didn't really want to include "extra stuff" in this project that would just have to be removed, but also didn't want to create an entire new repo for an example.

Totally understandable. I'm thinking another nice-to-have would be including Godot itself in the VS solution. I was imagining the following workflow, once you have everything locally built (godot, godot-cpp and your extension), you would:

1. Run Godot inside the Visual Studio solution with the debugger attached;
2. Load your game project that uses your own gdextension;
3. Develop your game and be able to debug your gdextension from within Visual Studio.

This way you would be able to develop/debug your game alongside your extension. And even poke inside godot itself if needed.

Maybe adding Godot as a submodule inside GDExtensionTemplate/extern and some CMake wizardry would do it. But I also noticed that Godot CMake files may not play nice, it could require maintaining your own fork of it. Not sure how much you'd be fine with that.

Is this the kind of workflow you're envisioning or would you suggest something different?

Anyway, really nice repo. Keep it up!

[asmaloney]

Thanks @gcardozo123!

I use Qt Creator to do what you're describing. I have a workspace with multiple projects open like this:

I can edit godot code or my extension code and run godot with the right switches to launch my test project - with or without the debugger.

With VS Code you can do the same thing, but it's much less integrated and frankly a pain.

(I tried using VS Code for this and other C++ projects and it's just... not very good for it. I don't have Visual Studio itself, so I don't know how that might work there. I think you can have a workspace with multiple solutions like I do with Qt Creator?)

I don't think including godot itself as a submodule is a good idea. That would add a lot of extra download/overhead for something that's not technically an extension dependency. This is essentially why GDExtension itself exists. I think the model you outlined is the right one, but that your workspace should be set up as above.

Right now the main issue with the workflow is that we can't "hot reload" our extensions which means relaunching godot between changes to our extensions. This is a huge time sink.

Is this the kind of workflow you're envisioning or would you suggest something different?

That's the workflow I currently use, but I was really talking about simply including & generating a test project with the extension repo.

In the build process it would copy the template test project to a configurable location, and copy all the extension stuff to the right place. I could probably add another cmake target to run it too if I add a configurable path to godot itself.

This would remove the extra step of creating your own test project from scratch and figuring out how to run it.

[gcardozo123]

I think you can have a workspace with multiple solutions like I do with Qt Creator?

That's right, I can probably compile Godot and add as project (.vcxproj) to the Visual Studio solution.

Right now the main issue with the workflow is that we can't "hot reload" our extensions which means relaunching godot between changes to our extensions. This is a huge time sink.

Oh, I didn't think about this before, sounds really bad. I wonder how Unreal works around this, as you can script your game in C++ there.

[kelteseth]

See my MR #61 this makes it super easy to getting started. The only thing yet missing is setting the build output to your Godot project `"C:\Code\Godot\build_MyGodotProject\GDExtensionTemplate\GDExtensionTemplate.gdextension".