I’m obviously just stating the obvious. This engine needs an auto save.
well, that may create even more issues, some times you want to mess with a scene do some stuff experiment but not save. Because unity will save over the same scene file this autosave may be problematic. You may say, why not save the scene incremental so why not they do this? I don’t know.
Now with this interface lock bug where unity show a loading bar for minutes or tens of minutes, some times unity did not save the scene even if I specifically save it using the shortcut and the file menu. The asterisk that show if a scene is still modified and not changed was gone so I closed unity the open it again next. Guess what, scene was not changed.
This made me very paranoid, now I can’t trust unity actually saving the scene
I’m sorry you’ve had this issue. We have multiple teams of engineers, artists and level designers, all working in different projects on different tickets, and knock on wood, we have had very few issues.
That said, we are using industrial-grade source control and we have trained everybody to constantly save and creep-commit in small increments, whenever there is a unit of save-able or merge-able work.
Please consider using proper industrial-grade source control in order to guard and protect your hard-earned work.
Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.). Our teams could not function without git.
As far as configuring Unity to play nice with git, keep this in mind:
Here’s how I use git in one of my games, Jetpack Kurt:
Using fine-grained source control as you work to refine your engineering:
Share/Sharing source code between projects:
Setting up the right .gitignore file:
Generally setting Unity up (includes above .gitignore concepts):
It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place.
Agreed! This engine needs an auto-backup with time slices, just as 3ds Max has, and every serious creative app should provide.
This is really going to bake your noodle…
… Unity incidentally makes backup scenes, when you hit Play, which you can get at. However, it’s as hostile to the user as it can be, because it’s Unity…
You must NOT restart Unity after a crash, to access this:
here it is in pictures:
and also here:
I understand… but this way of working NEVER accounts for the flow states creatives deliberately seek to attain, and the exponentially effective creative exploration that occurs once in a flow state of creative endeavour.
A creative app should permit, encourage and empower flow state creativity, and proactively, discreetly, protect against problems.
Yeah, you are absolutely totally 100% correct in this. I wish it could “just be magic,” but I’ve always had a distrust of super-automated backup / journaling systems, because there’s always that moment of “Wait a second, where did my XXX go?” and then you realize it’s been gone for maybe 20 minutes and you’re not really sure… or was it 2 hours ago it disappeared? Was that a bug? A fatfinger? Or was that the one I intentionally deleted when I switched to using the YYY … no wait, I didn’t delete it, I don’t think? Oh man, where is my XXX!!!
I find that FAR more disruptive than clicking the git window and capturing units of work, even if that includes selectively picking a few files (or even specific lines of source code) to commit.
This is why I suggested and used as an example, 3ds Max. You can set 3ds Max’s time granularity of autobackups, and the number of them.
So, for example, if you’re going mad with modelling, you might set it to 5 minutes apart for autosaves, and all 10 of them. Meaning 55 minutes of backups while you go bezerk modelling.
Or, if you’re experimenting with rendering settings, it might be 20 minutes between autosaves.
And, you can open more than one of them at once, in unique instances of 3ds Max, so you can find that one that has whatever changes you wanted… plus there’s xRef workflows, where you work on part of a scene in a project that’s only part of the scene… etc.
Empowering creatives in terms of UX are all solved problems. But (it’s quite obvious) Unity doesn’t do research into conventions and considerations within other creative spaces, even those (like modelling) that feed directly into working with Unity.
IDEA:
Use the DOTS approach to create System (of the ECS type) in the Editor, that journals the Project.
Then the undo system can be based on this, and the file restoration/journaling/backups, too, with saved snapshots at an increment of the user’s choosing, kind of like keyframes are to video compression techniques.
No need for git*, autosaves, etc, and it’s all surfaced in the Editor, and the “journal” of the Project, and Unity gets to try some of its own tech (the DOTS).
*an option should exist such that the snapshots can be background saved off to git, in another thread, along with the journal history, meaning it’s seamless and silent, the user just keeps working.
It would be smart for Unity to save periodic backups (or slices, as they’re called), though it’s a bit different with a game engine as you’re generally editing a large swath of files and scenes, rather than just the one file like you do in 3d software like Blender and 3dsmax. I imagine that introduces a number of extra complexities into the equation.
Just do what I do: Make a fastidious habit out of regularly pressing Crtl-S, to the point where you don’t have to think about saving. You’ve just already done it. Unity’s crashed on me a few times yes, but I’ve so far not lost any progress.
Oh, and use Source Control, of course.
This is a commonly held misconception, probably held in game making because programmers consider 3D apps only in terms of making of content for game engines and games. It’s true, “make a model, export a model” is an efficient way, often, to work in a 3D modeller when creating game content.
However… 3ds Max offline rendering exists in a world unto itself, too, making whole new worlds, wherein projects can dwarf game project folders because the only deliverable is renderings, not the content that’s going into making those renders.
Those working within 3ds Max often have projects that include entire city blocks (many of them) to do complex renders of the archvis type. Granted, there are a multitude of approaches to building up big projects like this, so as to be both efficient and more easily manageable, but come render time (which can be blocks of months of work) much of the project may exist together, and be enormous (many hundreds of gigs).
In making visual effects, there will often be gigs of textures, dozens, or even hundreds, of particle systems, all manner of other complex fluid and effects systems, huge swathes of animated things and masses of layering of effects and background models.
Again, yes, there’s ways to break all this up and modularise it as much as possible. But it all has to come together somewhere for final rendering, and that space is often one massive 3ds Max project.
I mean, I’m a 3d artist before I am a programmer. I’ve being doing 3d for over 10 years as opposed to my 5 months of coding. So yeah, I understand the 3d process and the pipeline challenges; I hear you.
No doubt they also use source control over relying on some auto-save system. I’ve never relied on auto back-up saves myself; more so just forming the habit of saving all the gosh-darn-time.
This isn’t an OR situation, it’s an AND
We should have:
- easy, seamless, backgrounded versioning. Great for experimentation and divergences.
AND…
- easy, seamless, backgrounded auto backups. Great for “Oh shit… what just happened?”
Check out this thread. A few posts in, there’s a post that includes some code where someone implemented their own auto-save. Maybe it still works?
That’s why Unity exposes so much of the editor API- if you don’t like the way the editor works you can change it.