One of the most aggravating noob mistakes you won't get told in tutorials...

Maybe this is just computer 101 stuff that I never learned, but whether you are a programmer, artist, animator, or whatever else there is, do yourself a favor and practice good version control.

I don't know if I'm using that term precisely or not, but version control is a method programmers use to help them debug their work. In a nutshell, it means don't keep saving your progressive work in the same file. Make new saves, and date/name them accordingly.

I'm practicing some rigging, and somewhere in a massive hierarchy of complicated parent/child relationships and constraints that make my eyes hurt to look at -- somewhere in here:
there is a mistake. If I could just revert to before I started the previous tutorial lesson, it wouldn't be a big problem at all. But I can't do that, because I'm a lazy moron.

 

This is how ALL newbies learn about version control - when it's too late.

Friends don't let friends create without version control.

 

working without version control is like playing diablo2 on hardcore

 

That is NOT version control! Its a recipe for insanity. I strongly suggest learning actual version control. Good luck!

 

No, that's just ordered saves. That's not version control. Ordered saving is useless in the face of true version control. If you don't want to think about how it works then you can use the built in Unity Collab although that's definitely version control-lite with just enough to qualify as version control. It's enough for me.

 

https://en.m.wikipedia.org/wiki/Version_control

 

Semantics!

 

I'm always amazed by the people who show up complaining about problems despite the fact we've told them in the past about version control. There is at least one member of this community who has repeatedly lost data only to repeatedly be told to use version control only to repeatedly tell us his backup solution is just fine.

 

Not really, as when developers talk about versioning or version control, they talk about having it managed on github, and being able to pull sources from different places without screwing your entire code base. It's about rolling back highly specific mistakes or being able to maintain branches of code then merge them further along into new branches, or main branches. It's a big subject and far more than just "oh lets name this one today's date" which is just numbered backups.

If you want to progress you need to stop using save as and stop doing backups. Let the internet take care of it with proper managed version control and source control.

The rename backup thing is something that I used to do 20 years ago (and still do but only out of hardcore habit if I want local backups).

 

I was being facetious there. Like you said, actual version control is a much greater degree of organization versus just keeping saved work in a timeline.

But, on a semantics level, it's the same principle. Anyway, for my larger projects there is a github and proper version control, but in this instance, I am working through a tutorial about rigging and thus just keeping a series of saves for each major step is sufficient, and I think is an important thing for beginners to understand that they ought to do this.

 

When you’re speaking about technical details, semantics is important, just as in code. Ordered saves isn’t a system, it process. And one that doesn’t work the broader scope of software development. Try doing that with a .cs or fbx or .dll in a project and you’ll quickly get into trouble. Ordered saves is a terrible practice for game development.

 

Can you elaborate on that last sentence?

 

FOR THE LOVE OF GOD!!!! GIT, google GIT.. And when you are at it, gitflow and feature branches.

ps: I'm an ateist

 

I believe he is referring to the fact that an ordered save will reload that entire project in that version. If you use version control you can change 20 scripts and 15 textures etc, screw up two of the scripts beyond return and then upload the successful work and roll back the two screwed up scripts to the version where they last worked. Sure, you could update the 18 scripts to the ordered save reversion..but what a PITA.

 

These things make life good. Also check that any server used supports git-lfs.

 

For the kind of graphics work that I do as a freelancer, version control would not work. You can't do all the fancy stuff that version control is really good for (branching, merging) with Photoshop documents anyway, let alone push 2gig big files onto github on every saved change. On some jobs I probably even outpace my upload speed with the amount of data I'm saving. For stuff like certain Photoshop documents or 3D content creation imho saving versioned backups is a valid way to go. I'm not talking about code here, because neither did the opening post. Actually I'm not even talking about gamedev...


I'd be interested in an online backup solution that can handle a simple automagic backup of all data on my pc. Backblaze claims to do this, but I'm super skeptical it actually is truely unlimited and unthrottled. Hell, I don't even know if my ISP would let me upload over 10 TB of data without throttling my upload speed below the rate at which I create or update data. Uploading 2gig files onto an ftp in my experience seems problematic at the best of times, and I don't know how an automagic tool could handle that. I also have forced auto-disconnects every ~24h, so a very robust resume function would be mandatory.

I'm well aware this isn't version control, I have a gitlab repository for that, but I can't use git for the big stuff that I need to back up.

Any experiences and recommendations?

 

What @ippdev said. You are just making a mess of your project and creating potential conflicts. Moreover, "rolling back" to previous versions of assets/code via renaming files is going to screw up assetdatabase links, trashing references in scenes and prefabs. Basically it will just create an unmanageable mess and break your project. VCSs exist for reason. And that is just for basic version control, things like branching/forking/merging make VCSs invaluable. Doing it manually is a horrible idea, and terrible advice to new users.

 

I think I understand what you are saying about messing up references, etc. Sometimes if I step away from something I'm working on for awhile, I might forget what the latest version I was working with was, or I need to file through lots of directories to associate things like texture files with .fbx models.

So what you are saying is that if I use an online repository to hold my stuff, then my computer stays clean and only holds on to the pieces I need at the moment?

Sorry, I don't know what half the words people are using here mean, so I have to break it down very simply.

 

It doesn't have to be online, it can be on a local network or on your computer (though not a good idea, as it creates a single point of failure). But essentially yes. It keeps a complete history of all your versions (check-ins). You can view or revert to any version, or roll back the entire project. You can branch, which essentially creates a copy of the project that you can work on (typically for features or releases) and work on without affecting the trunk, then merge back in. The files in your project are just he most current (or whatever branch you have checked out).

 

Ok. When it is explained simply, it sounds like what I am already doing. Maybe some people thought I was a programmer... I just do art. Typically I practice good backup techniques, but because I haven't suffered too greatly yet my discipline lacks sometimes, like today. For the project I am working on now, there is a programmer and he does use all that stuff and has shown me a bit about how he uses github to keep version controls with commits and all this stuff, etc.

I keep a temporary backup folder on google drives, where I keep versions of assets as I develop them. I also keep a library of completed things that can be used as starting points for future things.

 

Good version control practice:
A good way to use it is to check in a working collection of code when passing some minor milestone. For instance, finishing more than a stub of a new script or adding a group of assets and any code which makes use of it.

Every commit should have a clear description. Don't go overboard if it's a tiny code edit, as the diff should be sufficient to explain. But if a commit is substantial I start with one line summarising what sort of changes were made, then follow with an itemised list. Graphical Git clients like SourceTree makes this easier.

Combine this with meaningful tags so you can reverse to a snapshot with clearly defined functionality. I like semantic version numbers starting at 0.0.1 (if I also dumped a bunch of assets in), with 0.1.0 being the first version which does more than open a blank scene.

When you just mess around and try different bits of code, and find it doesn't work after all, it's easy to just use the stash command to undo everything since last commit.

Branches:
You can break off development into experimental versions. Just like regular version control, it only stores difference. This can be a great advantage when working on many different computers and storing it all on a central repository (GitHub, personal GitLab etc.), as when you clone it on a new device you can use the --single-branch and --branch options to get only that branch you're after.

Version control lets you reverse all sorts of scene changes, and that's where coders and artists meet in their requirements. Just remember to force text meta files in the project settings inside Unity.

 

I've heard a little about this. So for programmers, the github or gitlab, whatever it is, it automatically recognizes what changes you have made as you upload newer versions of your work? Is this automation what makes it so worthwhile?

 

GitHub/GitLab are just servers with repositories. Your local Git operations are where the magic happens.

 

It’s not automatic, you choose when to commit. Version control is not a backup, though if you are properly using version control you don’t need to backup.

 

Using ordered saves doesn't scale past 1 user, unless you like have 2+ users work as fast as 1. Even then, it is incredibly inefficient for space.

Version control saves deltas - just the changes - from one commit to the next. You can also have more than 1 person work on different aspects of the game (which is a necessity), and commit their changes as they get done.

I use source control on lone projects too, just because I get an efficient way of storing a full history. I can always roll back, I can try things and revert if they fail, I can use tags to find previous versions.

 

I am surprised nobody has mentioned the elephant in the room - working on projects with more than one person.

That is when proper version control is a life saver as it will let you resolve conflicts (multiple people updating the same file) intelligently with clever file merging and it will show what has changed by who.

Every try doing that manually? Copying and pasting into a single file while sitting with the other developer discussing who modified what? I have and lets just say it isn't fun.

Not mention that if you use a remote server for it, you remove the single point of failure.

 

@zombiegorilla @hippocoder we have discussed this before in depth.
Can you and anyone else who has worked on a project with dedicated artists, preferably a smaller project/team, how are the non-coders incorporated into the chosen version control system?
I can't see iterative work where fundamental changes to a complex asset such as a hero character, being continuously linked to a repository, but I could be wrong.
My sole experience with a team and version control allowed me to pull each day, version locally while I worked, then upload at the end of the day. The local versions were only for myself to iterate on while I made creative decisions. I know this process wasn't best practice - but it kept me focused on the creation rather than the back end stuff.
Some 'how it's done where I'm from' antidotes (spelling) might be helpful for all.

 

i work with a smallish team. we have 3 modelers and 2 animators.

we have seperate systems. the art team uses subversion and the server to track their changes.

when an asset is ready to be tested in the game the programmmers bring it in. set it up and if its working ok we commit the game asset in p4

on svn they are supposed to be commiting the source asset psd or max files and the current fbx and png. we only store fbx png in the game p4

later when nore changes are ready we will then go update the svn repo and bring the updated assets into the game.

the artists also have a daily updated version of the game they can update and test their changes in first before giving to us.

this is what mostly happens. i dont have time to make sure the art side is doing it exaclty like that. but the general flow is in place.

the biggest thing this saves us is that in our game repo only working things exist. the artist cant break anything by doing a commit. if they are only half way done.

of course git offers this same kind of thing but even using ui tools. git can be very complicated and our artists are used to svn.

 

My example was also with svn.

Related link
https://forum.unity.com/threads/released-free-beta-git-for-artists.510454/#post-3335733

 

On larger teams, art (source) was kept in a separate repo, usually svn/perforce. Game assets were only added to the game via assetbundles. Most of the artists managed all that themselves, unless what was being added was a special case or one off, then tech art handled it. We also built of tools into maya and other apps and unity to make the process faster and safer. For my current teams, about a dozen folks, everyone works in the same repo (perforce) with art source files in a sibling directory to the unity project. Artists directly integrate assets into the games

For iterative work pre-integration, stuff that worked on by a single person, usually commits were an end of day thing, unless they specifically committed for version purposes or branching. We also use staging projects if we want to pass stuff back and forth. In preproduction it is a bit more loose, in full production iteration is usually done outside trunk or in prototype projects. In post release/ live ops, iteration is usually kept strictly in the design phase. Iteration at that point is usually a failure in planning. Large things (multi day type things) like environments and large characters, are usually just committed at end of day until they move to integration.

General practice is always at the end of your day, you have nothing unique on your local machine. Everything is committed somewhere, wether an art repo, or if code, in a branch or disabled if incomplete. (Ideally not breaking the build). It’s the ‘hit by a bus’ contingency. If I get hit by bus after work, or I drop my laptop in the lake, nothing is lost. I can get a new laptop and be up and running quickly.

It’s also going to depend on the experience level of the staff. While most of my current team might be called “non-coders”, they are still highly skilled game developers and quite comfortable working directly in engine (unity and others). Our artists and animators build and modify state machines, handle lighting and camera rigs, etc. On a small team, everyone has to have broad skill set. Everyone runs local servers, does local builds and can/does interact / modify the backend data.

 

Honestly, GIT is fantastic. If you don't want to learn the fancy stuff, just download tortuisegit (windows) or some other visual shell. You don't really need to learn very much other than "right click->commit".

My project is sitting at 18 gigs of assets - 44 gigs in total including library, etc (the project directories are a giant mess). Git handles this fine. It's not quite as useful for binary files since you can't get meaningful diffs, but it's still saved me a ton of headache when working with textures or brutally hacking meshes or animation like the artistic noob I am.

Since I work alone, I just put a git repo on my dropbox folder and push commits there. Dropbox synchs the repo automatically. This setup won't work for teams, but for solo work it's fantastic.

The difference between ordered saves and actual source control is massive. Having clear commit logs, being able to diff text, selecting a specific file you want to roll back, etc - these things are incredibly useful.

Plus, if you really get into good habits with making solid commit comments, the rolling log of changes is incredibly valuable and feels great.

Just do yourself a favor, set up a repo and try it out for a few days. If you don't like it - just stop using it. Trust me, you won't go back to ordered saves. Some of the docs might seem intimidating, but I'm sure you can find a youtube tutorial on setting up a local repo.

 

Whats best with version control is all the fun you can have. Here is some examples from our git history

 

Only one of these doesn't have a certain word in it...lol.


I'm sorry, but I just find setting up Git to be a massive pain. I've never really figured it out. I'd love a straightforward tutorial on how to do this with Unity Collab, or even just Unity in general. I tried to use Unity Collab once, but saw it was looking for a Git repository and noped right on out of there.

 

Unity has a pretty good tutorial with screenshots.

They should have added a note to set Edit > Project Settings > Editor > Visible Meta Files and Force Text Serialization.

Other than that, they did a good job because they kept it to the bare minimum, avoiding discussion of branches and other things that are important but information overload for a first-time tutorial.

 

I use gitlab, they have LSF support. You are up in matter of minutes

 

Even setting up your own GitLab instance is just one package to install.

 

That sounds like something I will look into once I start compiling more assets and get ready to work more in engine.

Thanks for the advice, one and all.

 

For a solo project, if you aren't going to use version control, at least make regular backups, and don't delete your older backups. Version control is great, and pretty much a requirement, when working in even small groups. It can seem to be an unnecessary hassle when working on something solo though, so lots of people just skip it and won't set it up until they have been caught with their pants down.

If that is you, you can still save yourself a lot of headache by getting yourself something like an inexpensive NAS storage device, and copying your project over to it at regular intervals. Don't replace old backups until you have to, just create new backups.

 

This is going to really show my ignorance regarding computers, but, if I have two harddrives on my desktop (a SSD and 1TB hd), is that a reliable backup? What I mean is, is it as reliable as having an external hardrive that you backup to? My thinking is that because my OS is on the SSD, if i were to get a virus or something it would just affect that, right? I really don't know though. I guess if there was a lightning strike, that would probably fry everything, but thats what the surge protector is for, right?

This is just a curiousity question so don't nobody get upset over it. For now my artwork is mostly done solo, but soon I'll be compiling this stuff in Unity with some other people so I'll get a proper version control for my art assets set up -- an aside from the programmers gitLab project.

 

http://robertgreiner.com/2010/02/getting-started-with-git-and-tortoisegit-on-windows/

 

While you are at, can you build my project for me?


Haha, j/k. Thanks alot. I've got this thread saved on my trello board to come back at reference.

 

Best practice for backups is one backup on site (or possibly more, depending on budget), one offsite backup (online services, simply uploading an archive of your backup drive to a personal server, whatever). In addition you have change history in version control, plus a separate version control server you push it to. And of course you back up the version control data too, ensuring you have it in about four places

 

But what if there is a nuclear war?

It's amazing how meticulous this can be, but I guess when you are dealing with hundreds of hours of complex work, you really don't want a chance at losing it.

I mean, a lot of times in the army your contingency plans for combat missions weren't so meticulous, but then I guess a soldier isn't as expensive to keep around as a programmer.

 

Your offsite backup should be with MoonCorp anyway. If you're worried about a sufficiently large asteroid colliding with the moon, also look into locations around Jupiter and its 69+ moons.

 

That was a Fup in the commit comment!
All important commits are F'ed to designate importance.

 

Surely you have a microwave, right?

https://io9.gizmodo.com/5902325/could-a-microwave-save-your-electronics-during-an-emp-attack

 

That is certainly the case virtually every project I have been on. That and “unf’d” are practically technical terminology. They are short, clear and convey severity.

 

I've invested in a personal NAS in a RAID for redundancy's sake and it's been serving as my personal version control drive and it's honestly one of the best investments I've made simply for how fast it makes rolling back to previous iterations and recovering files lost. It was a little pricey to set up, but it keeps my peace of mind well at ease.

 

100% safety doesn't exists anyway.

I personally store my projects on both Mega and an external hard drive. I keep different versions once in a while, especially when I've reached a "key point" in development, before carrying on.