Posted On: 2025-07-07
In my previous post, I covered how to automatically download Godot when building a project. Since writing that, I've expanded upon that approach, adding support for more operating systems, Godot versions, and eliminating the need for any manual setup. The result of that effort is Autodownload Godot, a project template that you can simply fork/clone, and it will automatically install Godot in your project.
The documentation covers the (simple) instructions for how to use it, as well as the various features it provides (automatic installs, one-button launching from IDE, ability to switch Godot version using a config file, etc.) Rather than repeating myself, the bulk of this post will dig into the rationale behind why I used this particular approach.
While trying to add support for multiple operating systems to my previous post, I quickly found myself in need of multiple configuration files.
Each permutation of OS and build architecture needed its own details (file to download, hash to check, etc.) and beyond those predictable things, there were
a number of subtle differences that significantly increased the complexity of getting the right file(s) for the user's current OS.
Rather than provide all the files and expect the user to Import them manually, I settled on providing a template: a simple (blank) project that a user can immediately build to get Godot.
Once I'd settled on using a template, the scope expanded to include a few Godot-related configuration settings as well. Godot's documentation has a section for setting up an external editor, but those instructions are simple, project-agnostic, and dependent on where Godot itself is installed, so I opted to set up the template to take care of that. Adding the option to choose whether to run the project or the editor seemed like a reasonable addition as well (since the user isn't the one downloading the editor.) The scope for the template does not, however, include exporting the project: unlike the editor, the export templates are quite large (~2GB for 4.4), so it's important that users only download them once, and only when they really need them. For now, the template doesn't do anything for this, so users need to use the editor's built-in workflow, which is well documented and fairly simple.
The repository is set up as a regular repo rather than a Template Repository. Doing this reduces vendor lock-in (Template Repositories are for creating new repos on Github), but it also makes sure that the update process is a simple one: as new versions of Godot are released, I will be adding them to the repository, and the easiest way to get those new versions as a user is to use Git to pull changes. Sticking to a regular repo seems to be the best way to encourage that particular workflow.
The best way to know that a tool works is to use it yourself (a common practice with an odd name: dogfooding). I will be doing exactly that with Autodownload Godot: going forward, any time I want to make a new Godot project I'll be forking that template.
What's more, I have an existing project that uses the approach covered in my previous post - so for that project I'm testing out a workflow for
adding the template into an existing project: merging it in using the --allow-unrelated-histories flag. (Note that I am still early in testing this, so no promises that it's actually a good idea.)
Hopefully this has been an interesting read regarding the background details for Autodownload Godot. I hope you give it a try with your next Godot project, and if you have any thoughts or feedback, please let me know, either directly or via the issues section on the repository.