Cleanup Project of temporary/obsolete items

Godot Version

4.3 stable steam

Question

I have quite a simple question. How to cleanup a project folder?
I’m still figuring out how stuff works. Import from the assets library, work with the tools, have something generated and sometimes it goes wrong and I try to delete stuff from Godot which is not always possible. Then I close the project and remove stuff manually in windows. Reboot the project. It ‘recovers’ itself and I continue.

But today I discovered that my project is already 1.6Gb on data. As I only have a small amount of scripts and assets this made me curious. So I created a copy of the complete folder and started to ‘throw stuff away’ within windows. Restart the project and everything still looks to work, only I managed to remove approx. 1Gb on obsolete data. How to do this in a ‘correct’ manner? Is there a cleanup function? Or can I create a ZIP from the project which only includes the used stuff. As I’m will be adding/removing a lot of trash for testing I do not want to have a project of 15Gb in half a year, with only 800Mb on actual content :slight_smile:

1 Like

Not sure if it’ll work for you but try this, when you import assets, Godot creates additional files (like .import files) and cached data. If you manually delete assets from the file system, their corresponding .import files might remain.
Just delete .import files for assets that no longer exist in the project.

There’s also to manually delete the .godot folder in your project directory. This folder contains editor-specific data and cache files. Deleting it will not affect your project, but the editor will regenerate it as needed.

2 Likes

In my experience this can be a nightmare! What I do now is that I have a clear distinction between build types. First is prototyping, then production.

Prototyping is where you are now, with tons of additional files, test scenes, assets all over the place, probably additional scripts hanging around and basically a big plate of spaghetti. That is brilliant though, you have been trialling, learning, developing, exploring, changing things, this is what prototyping is all about.

Then comes the production build. It can seem more boring than the prototyping stage but it has it’s own sort of elegance and challenges. This is where you are creating the version you are going to share or sell. The clean one. What you are essentially doing is re-creating your own game from scratch, but this time, your only focus is on clean and maintainable code and structures. Nothing should be brute copied from the original. Every script should be checked and re-factored, every asset stored in your now perfect folder structure and only if needed. Creating this beauty of a version does not take as long as it sounds like it might, but it does take time, it is not a job completed in a day (at least usually). You are not adding anything now. Get a good idea suddenly, too late. That was for prototyping, not production.

The decision to move into production stage is a big one. You are happy with your game and it is feature complete. Now you can start building the clean version.

So cleaning up a project folder is no longer a problem. You don’t have to any more. Because this is not your production version.

Think about it like this. When a new machine is invented it is created in a workshop, probably with bits all over the place, oil on the floor, early versions sitting in corners, failed versions lying around in heaps, scrap piles, useful bits here, bits that need further exploration over there etc. But now the prototype machine is built! It works and does the job it was intended to do perfectly. Now do you just clean up your workshop and start production, or do you go and find new premises, set up a production line, get your staff trained, get all the bits you need in order and tidy. Prototyping is not production, and production is not prototyping. Prototyping is messy, fast coding to try stuff out, dirty loops and crude data structures etc. Production is clean, reliable, tested, safe and free from clutter (and maintainable). Production is pure.

So when you are ready, don’t bother wasting time ‘cleaning up a prototyping folder’, just start a new project and build your production version from scratch.

Hope that helps.

Hi Paul

Off course this is what I will be doing at the end, but if the mess in your workshop is too big that you almost cannot walk around anymore, and your workbench only has room left for your cup of well deserved coffee, do you close the door and move to a new building? or do you want to just clean the workshop? :wink:

Cheers

Ludo

2 Likes

Hi Troglodyte

Thanks for the suggestion. It sounds as a good ‘workaround’ :slight_smile:

Regards

Ludo

1 Like

This isn’t exactly a set-in-stone rule, and the prototype → production model isn’t either. It’s a little more complex than that.

While yes, a working prototype of a feature does gets refined into a production ready product, that doesn’t mean the finished product is in it’s final form or can’t be changed. Certain types of games are built off the idea of public iteration over time with updates.

The biggest example being live service games. I very much enjoy playing and making these games. This is because if an execution of an idea doesn’t stick the landing, the developers (me) can work with the players to make something better.

And adding on content with updates isn’t exclusive to live service games either. Lots of single-player games get expansive DLC that add fresh new content and can even update old content.

This strict “prototype or production” rule only really applies to standalone experiences that can only be novel on the first playthrough. Even then, if something doesn’t work, it isn’t too late until that game is released. (Or the deadline is hit)

All of this is within reason of course. You can’t just change the whole genre, core gameplay, and identity of a game via updates (cough cough Fortnite cough Call of Duty cough). But I think you get my point.

It’s never too late until you say it is*. (*At least for independent developers)

1 Like

@Demetrius_Dixon
Yes, you are absolutely right of course, and that is a great point. I think my strictness around this is a little too rigid, but for me personally it helps me greatly if I try to stick to this rigidity as I do have a tendency to let project creep keep me embroiled in ever expanding functionality. And my experience is solely limited to solo dev. But what you say is absolutely right, “It’s never too late until you say it is.”, and that is why I love solo dev so much!

@ljlhouben
Sorry, re-reading my post it does sound a bit patronising, didn’t mean it that way. And yes a clean workshop is important. I think it is because I learned the hard way that when I returned to a game for maintenance and a potential update, I could not believe the mess and spaghetti code I had left in there, so much so that I have had to abandon any future development on that game as it needs an almost complete re-write.

This may help to answer your original question:
I maintain separate ‘prototype’ and ‘development’ branches in my version control system. I primarily work on the development branch, implementing and testing new features. Once I’m satisfied with the stability and functionality of these developments, I carefully merge the changes into the prototype branch, which serves as a cleaner, more polished version of the prototype game. This helps to keep my workshop tidy :slight_smile:

1 Like

@pauldrewett
No issue :wink: I’m a programmer for industrial controllers and 10 years ago I worked in a big company were we had multiple projects on multiple libraries. Then you need multiple branches and release strategy too :slight_smile: So I was talking about my development project. When I finish something, then I add it to my main project. Within the Beckhoff PLC we can clean the project from obsolete things by creating a ZIP package of the compiled project. Everything that is not in the ZIP you don’t need and can be removed :smiley: So I was wondering if there was a similar trick in Godot.

1 Like