Question on auto-save and version control

To anyone,
I would prefer if the Unity staff answer this because they are the ones who designed Unity. However, anyone who knows can also contribute:

After using Unity for some time now, I saw a small box in the design window where auto-save seem to have been automatically activated. This is not easily seen. I still use Save and save project to make sure my scripts are saved. I have also been told by various parties to use version-control.

I simply want to ask: If auto-save is deactivated, then isn't it true that version control need not be used? Or is my opinion wrong?

 

People recommend to use version control so you can easily extract earlier version of codebase. One from hours, days, weeks or even months ago. Having version control allows you to experiment without fear of data loss. For example, you can upgrade your project to newer version of unity, and even if it breaks, you'll be able to restore it back to working version.

You can't do that with autosave, so your opinion is wrong.

 

They have different purposes. They both involve files being stored, but that's the extent of their similarity.

Auto save limits the loss if there is a failure while you are working. For instance, if the Editor crashes or there is a power outage then at most you will have lost work since the last auto save.

Version control is for keeping multiple different versions of a saved project which are stored separately from where you do your work. Ideally, this separate storage is on a different computer or a remote server somewhere. This has a range of benefits:
- It stores history to back the start of the project.
- It can also be used to share the project among a team.
- It can automate most of the work of merging different peoples' work.
- If you're not lazy with your commit descriptions, it's also useful documentation.
- It's an implicit backup, because if your workstations dies you can just pull a fresh copy.
- There's advanced functionality for things such as branching, which are useful when working in a team or doing experimental stuff. But... leave that for later.

 

There's lots of ways you can irreversibly alter a Unity project. Version control really saves your butt, even for a solo dev. The first time you accidentally create a week of work, which version control solves in minutes, you'll see its value. Until then it can be hard to see its advantage.

 

Yes. Thanks. I've experienced this before. But my point is if auto-save is not activated during the time I'm working on my project, I can make changes before it becomes permanent. Perhaps your point is version control is only useful for bigger amounts of work. You should agree because undo is already available.

 

Eh... Unity does lots of things that it even tells you that it can't undo. Deleting assets, and opening your project in a newer Unity version for example. Also, I reread your original post, and just want to point out that "Save" and "Save Project" have nothing to do with saving the text of your scripts (that's handled in VS or your favorite code editor), just how they are set up as components inside the editor. Wasn't sure by the way you wrote that if you are clear on that or not.

But I disagree that version control is only useful for bigger amounts of work. I don't use it when I'm making prototypes or playing around with new game ideas, but for a serious project I always use it. It actually has a lot of value outside of making backups.

Simple but common example: Some system in your game was working last month, but is not today? Just look at the diffs between all the different versions of the scripts involved over that month, and you'll probably spot where the regression appeared within minutes. Then you even have the old working code right there to bring back, or use to help you rewrite it so it works as it used to but also incorporates whatever additions were needed which broke it last time. It could just be a 1 line change that caused the problem, not really "bigger amounts of work", but those kinds of things can easily take hours to spot the old fashioned way going through the entire system line by line trying to find the issue.

 

Like mentioned above version control is good for any size of change. I wouldnt want to change anythign in a code base without version control. Its such a nice tool when you are implementing a new feature or refactoring a old one.

Just branch out and hammer away.

edit: btw, I have seen people say they are too lazy for it. Version control is a tool that can make you lazier in a safe way

edit: though if you are working in my team you better not be lazy with your commits or you get my range raining down on your. A commit should only contain whats relevant to the feature or refactoring/bug fix. I hate it when someone also for example formated the file so the entire content change., Impossible to see what was the actual bug fix.

 

I can't fully agree with you or @MDADigital. I'm also into Android studio programming and I do not see the same problem like with unity. I don't use any version control and I don't understand why Unity is so fuzzy and screwed to this level. I just wished that SOMEONE can explain if there's any way to use unity without version control.

When my Android gets screwed, it doesn't end up like Unity where all sorts of weird and strange results appear.

Note: I won't be responding to this thread because your points are already given. I'm just saying I wish that Unity did not have problems to the point where version control must be used.

 

You shouldn't use any programming language without VC

 

What are you talking about? You need VC because its a sensible thing to have, not because of problems in unity. The problems you are describing are workflow problems, which are solved by being smart about your workflow and using things like VC for reliability.

Im not even sure you fully understand what VC or even what the auto-save checkbox is that you are using, based on everything you have said tbh

 

There is, but basically it means that all your changes will be permanent, which, in practice, is like trying to do stunt driving without helmet, protective gear, seatbelt or having a roof in the car. While on fire.

This applies to all programming languages. Anything bigger than 20 lines of code needs version control.

The most common example, by the way, is that you open a file in your IDE, alter few lines and then close it. And those few lines introduce a bug despite being compileable. And that's it. You can't reverse it anymore without a version control. Because you saved and closed the file and the original version is gone. You need version control.
What if you altered a model or a texture and want earlier version? Version control. You accidentally destroyed settings for something? Version control. You altered field within a scriptable object asset? Version control.

You have to use it when you program in any language. It is just common sense, and it is not a result of unity having some sort of issue.

 

It's not that Unity is "fuzzy" or "screwed", and it's not even fundamentally different to stuff you might do in Android Studio.

It's that out of the box Unity is already doing far more complex stuff than you're likely to be doing in Android Studio. Unlike with a simple mobile app, in even a simple game in Unity you're likely to be dealing with:
1 - Code assets
2 - Various environment specific data assets (Scene files being the first and most fundamental one)
3 - Various data assets imported from external sources (eg: 3D models, textures, sound effects)
4 - Configuration data which relates all of those to each other

While working on a simple project in Android Studio you've got a lot of item number 1 up there, and comparatively little of the others. That means there's far less of a "problem space" that you need to understand, and fewer sources of potential errors.

When you're working in a game engine there are oodles of sources for potential issues that are outside of your code. There's a lot more to wrap your head around. It seems "fuzzy" to you because you don't fully understand how everything relates to everything else yet. Don't sweat that, it just takes time. But hopefully it'll help you to know that there is reason behind the stuff you're running into, and if you stick at it you will come to understand it and be able to solve and avoid those issues.

Bringing this back to the original point, here's another key difference between "auto-save" and version control:
- Auto-save works on individual files.
- Version control works on related sets of files.

So when Unity auto-saves a Scene it is saving only the changes to that Scene. In many cases that's perfectly fine and useful. For instance, if I'm working on adding art to a level then that's a great feature to have, because if something goes wrong I can just load it back up to more or less where I was up to.

However, if I'm also writing code which is related to that level then there is a dependency between that Scene file and whatever scripts I am writing. I am making one overall change, but that change involves multiple files. Say I'm tweaking how a character controller works in a game prototype. It's not enough for me to have just the previous scene or just the previous script file if that breaks. If something goes wrong I need to look at both files together in the state they were in when it worked. This type of thing is what version control is for. It allows you to record changes to projects rather than to individual files. "I have made changes to these files, which go together in this state".

Once you're in the habit of working based on this it makes life much easier. And that's not just a Unity thing, the same applies when you start making complex stuff in Android Studio or other environments, too.

 

I think your explanation is the best one. Thinking back, Android has only one java file to work on. Unity has so many scripts.

 

I do know what I'm saying. I'm still using Android for other work-related issues and I don't have the same problem when the codes are wrongly written. Unlike Unity, it's not difficult to test and debug. So I don't understand why this is hard to accept. As my previous reply stated, Unity is more complex due to the multiple scripts it requires. I hope no more replies comes in as there's no point arguing further.

 

Nope, it doesn't. Any normal program that is not a toy project will be split into multiple files.
Even a few thousand files in a project is not unusual. A blank project on android should have a couple of files in it (with all those build configurations)

 

Sorry, but seems you came with an assumption, people will agree with you.
When they are pointing your posiblle misunderstanding of using certain features, you turn into defensive mode.

So what was the point of your initial question, if not to learn from others?

I also agree, you should spend some time on learning VC. In fact few hours may be enough to get basic grip and things going, if never used VC. You then will appreciate the feedback and the time, other people are giving here

 

You can stuff everything into the same file, sure. Is it maintainable? No

 

I don't think you fully understand what version control is because this is the default behaviour of Unity. This is what happens when you just save a project to a folder. Automatically saving your project is not version control. Version control is a way to easily roll back to previous versions of your project, an easy way to create forks of your project, and an all around good idea for project management. You keep speaking with the confidence that you understand these things, but you do not seem to actually know them.

 

No, that's not why. It's also not specific to Unity.

Splitting code over multiple files has been a thing since the early days of programming, and has been standard practice all that time because it's helpful. Projects get complex, and breaking big complex things down into simpler pieces makes them easier to manage. At first it doesn't seem that way because you need to learn a bunch of stuff to be able to do it effectively, but afterwards it will drastically increase your productivity.

I suggest reading up on object oriented design principles. They're not the ultimate word in how to program effectively, but they're a great starting point and I believe anyone who writes significant software should be familiar with them.

 

Specifically, what are the problems you're running into with Unity? If you give us details we might be able to suggest things to do or learn. Just saying "problems" is far too broad to be of any practical use or discussion.

What is the most recent thing you did which didn't turn out as expected? What did you expect? What happened instead? What task was it a part of?

 

I need to open a new thread or just check the internet. I just sent some feedback stating that the manuals don't give user-friendly instructions. Debug.log is an example. Instead of finding it in the manuals, the internet did a better job. From here, I can see what values are in my variables and better understand what I'm writing / creating. I'm following online tutorials others gave that can be found in the unity learn link.

 

What about this isn't user friendly?

https://docs.unity3d.com/ScriptReference/Debug.Log.html

 

Yes. Thank you. I've done this before. But as I stated earlier - which I'm sure you read, otherwise you won't be in the thread, I don't have the same problem with Android studio. So where my knowledge is concerned, despite it being quite small and narrow, version control is more a backup rather than a necessity at this stage.

 

See https://www.codegrepper.com/code-examples/csharp/unity+how+to+display+variable+in+debug+log. Why isn't this in the manuals? It might be easy for you but it's not easy for me.

Update: It might be common sense for you but I need the steps, one at a time.

 

There are literally examples of this in the link I provided. The Scripting API is the manual for the API, which is where debug.log would be.

Then don't do anything. Version control in Unity does not exist as a feature that you have to disable. You have to opt in to version control. If you aren't doing that, Unity won't do anything. I can not even begin to figure out what your problem is.

 

Yes. I already checked the manual and I don't understand what it says. The link I shared has actual examples that work in the Unity I'm using. There are other debug.log which I tried and ignored because I get compilation errors. So it's no point discussing them.

 

No, those should be discussed because this is starting to sound a lot more like you're not familiar with developing in C# much in the first place, because accessing the Unity API is exactly as it is accessing any other API you'd have encountered in development, which means the source of your problem is that you're not taking time in the right places.

 

OK so be my consultant and give advise. What's the best step? I'm with an online course now still learning. Remember that i never said i was an expert. I'm just wondering why version control was required when other apps don't give problems without version control.

 

Where is Unity asking you for version control? Show a screenshot.

 

Unity did not ask for version control. It's auto save i'm talking about. It's auto-save that makes us use version control so our work is kept securely. I'm using 2018.4.23 LTS. Maybe you can check on your computer. I need to google the location out.

Update: Unable to find the auto-save. I clearly saw it in previous LTS versions before. If no one can find it, then just ignore this thread. I'll just google out my problems...

 

It doesn't but it should. They should replace that backup warning with VC warning. "Before upgrading make sure any imported changes are committed to your version control repository"

 

Outside of two instances that I'm aware of Unity doesn't have an autosave feature. I know this because it's one of several very commonly requested features that we've asked for that the developers have refused to provide.

Instance #1 - Unity saves the scene into a temp folder with a temp name when you press play.

Instance #2 - Prefab editing has an autosave checkbox. Unchecking the box stops it.

 

As Ryiah said, Unity doesn't autosave. There is no feature that does this.

 

Because it is a beginner level programming. On "Hello World" level.
https://docs.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/tutorials/hello-world?tutorial-step=2

If you never programmed before and just started learning, you learn how to do something like that pretty much at step one. That's why it is not in a manual. Because you're supposed to know.

 

Well in that case, I rather stay with a google search. Where I'm concerned, the manuals still need improvement for people like me. That's why I gave the feedback. To me it's silly that basic things like this is not included. As long as I can do my programming in peace, that's all I care about. It might not benefit you and others in this thread but new people who learn unity will definitely benefit from it if it's added.

 

Unity manual also doesn't teach english alphabet. Should it be teaching the alphabet?

There are topics beyond the scope of the manual, and adding two strings together, formatting strings and converting types to strings falls under that. They're programming question, VERY basic ones, and there are thousands of resources where you can learn this information.

 

The thing is, you should never rely on single source of knowledge.
You will find many references to Unit docs. But as well, to many blogs and vids.
I am not consider Unity tutorials to be in particular reliable source of learning. But they are there, if anything.

To get answer, it should be split into two components.

First component is
Debug ( i.e. .Log, .LogWarrning, .LogErorr )

https://docs.unity3d.com/ScriptReference/Debug.html
Log
LogWarning
LogError
etc.

You got Unity manual there for that.

Unity Debug is close equivalent to C# console
https://docs.microsoft.com/en-us/dotnet/api/system.console?view=net-5.0


Second component is
string manipulation and formatting, which is part of C#.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/strings/

This is basics part of C# and is beyond Unity teaching scope, because is already covered, by official resources. Plus tons of external resources.


Tutorials often discriminate pointing out, where to learn specific parts that they showing.
They assume, reader have already expected background, before entering it.
Otherwise, it may be require to do few steps back, to fill missing gaps.

 

All learning resources have prerequisities. In the case of Unity they are a basic understanding of programming and a basic understanding of how to use your computer. If you want to learn programming you need a manual intended for programming like the C# Yellow Book which teaches complete beginners how to use C#.

http://www.csharpcourse.com/

 

Please ignore what I wrote here. Perhaps the internet is better so I can do my own research in peace. Thanks.

 

University of Hull FTW! Rob miles (Author of the yellow book) was a great lecturer at uni when I was there Glad to see people are still using the book to date

 

Not OP. Google seems to work fine. But what do a bunch of seasoned developers know?

 

Closing 'cause this whole thing is just silly.