4 ms·

Not gonna lie, when I saw "delta" I immediately assumed Git or some other source control solution. What boggles the mind is how these professional game develop

Not gonna lie, when I saw "delta" I immediately assumed Git or some other source control solution. What boggles the mind is how these professional game developers recently discovered this technology. I didn't think Git was so exclusively beholden to the web development community.

AndrewDucker 13y ago
You wouldn't use git for massive binary files that change on a regular basis. Particularly when you only need your testers to have the latest version of them, not the complete history (which is what git would give them).
unwind 13y ago
You are fantastically mistaken if you think game devs don't use source control. Heh. Of course they do, and I'm ... let's say pretty sure that much of EA runs on http://www.perforce.com/ http://www.perforce.com/. Also weird that the article starts with a BF4 image, but then claims that BF4 was developed in Californa. I guess that hurts my national pride (go DICE!).
NickPollard 13y ago
Git solves a different problem; sending large binary blobs around is not it. As another comment said, this is essentially RSync, not git. I've been out of game development for a year, but unfortunately git is not being taken up much by large game developers. The main reason cited is actually git's handling of binary files, which leads to every checkout containing many duplicates of huge files. However this is possible to work around and the benefits of git still make it worth it.
- js2 13y ago
  That said, git does have a delta compression mechanism for reducing disk space and saving network bandwidth that is quite complex: http://stackoverflow.com/questions/9478023/is-the-git-binary-diff-algorithm-delta-storage-standardized http://stackoverflow.com/questions/9478023/is-the-git-binary...
  - kzrdude 13y ago
    Git's compromises break down with large enough files. Some git operations still need to have the whole blob in memory at once. Support for chunking of big files would possibly solve this, but the git project is not interested(?).
- Negitivefrags 13y ago
  The binary file reason is big enough, but it's also the ability to check out a sub tree without checking out the entire Repo. The repo is 1TB and there really is no reason for your texture artist to be checking out the raw uncompressed audio files. The other reason not to use git in game development is because it's incredibly hard to use, and more than half the game development team are not programmers and/or not technical. Getting them to use good source control discipline is hard enough with TortoiseSVN. I shudder to think the insane mess we would have using git.
  - NickPollard 13y ago
    So one thing is to use separate repositories - either separate git repos, or use git for code + design data, and something like Perforce for assets. We did this at my first studio (Free Radical Design) and it worked very well. As for git being 'hard', yes it's not trivial to learn, but for people using just perforce/svn etc. they end up misusing so much that it's almost worthless - as Linus said, even just sending around tarballs is better. I think if you're running a team, you need to give your team the benefit of the doubt that they can learn new tools, learn to use them effectively, and be more productive. If you spend some time teaching them why the tools are important and how to use them, then using git isn't really any more difficult than anything else. It's just different.
    - w0rd-driven 13y ago
      This is how I've structured our use at the place I'm at. TortoiseGit is better than svn to me. Submodules are the key though in our situation these are best when they can exist in the same directory structure. We create a master repo with all the design assets, statement of work, and any other useful files for the end product. Then we have a client repo as it were of the files we serve in the wamp www directory. Because this is physically different, submodules make little sense. For the WPF builds that all live together in the same directory structure, submodules are perfect. My only hiccup is remembering to commit the subs via the master but that's a habit I need to change. The files in the wamp repo are deployed to client computers using git pull with a read only ssh key so people aren't committing from them. Our wamp files are primarily text either in straight html or usually PHP. We take care not to commit user editable sections so we don't overwrite what a customer ultimately changes. This is kind of a hand rolled version of the now many git deployment tools out there and it works rather well. I know this isn't gaming nor are our source files that large but the psds can be astronomical very quickly on just simple web pages. I could only imagine what goes into "next gen games". GIT is still useful for binary deltas but you definitely have to carefully plan how you partition things in repositories. If I can do this, really almost anyone can. Kiln brought excellent binary support to Hg so there's really no need to stick to svn. There may be areas where its still useful but the distributed nature of dvcs is just too compelling when your team is well... distributed. I do hear great things about perforce too and I hope any company uses the better vcs not because they think the users can't cope with anything new, but there is extreme benefit for doing so. Again, if I could help our team move into Git with very little hand holding, you would probably be surprised how quickly people adapted. Especially if something like TortoiseGit isn't that much different than TortoiseSvn or TortoiseHg for that matter.
ethanhunt_ 13y ago
I think a lot of game developers actually use perforce because it handles large files better. This is at least what I've gather from eavesdropping some of them (e.g., Jon Blow) on twitter.
- NickPollard 13y ago
  Perforce is very popular in Games, I think 4/5 studios I've worked for used it. I still vastly prefer git. Perforce does have some pluses, but it's mostly people just going with what they know.
7952 13y ago
When you look at how non-programming projects are managed you often see a lot of the same issues that source control addresses. Files (and information in peoples brains) become out of sync, or need to be locked. Programmers always focus on the technology of source control, but the difference it makes is also social. It forces a particular workflow that allows tasks to be carried out concurrently. This workflow could be adopted without necessarily needing git.

AndrewDucker 13y ago

You wouldn't use git for massive binary files that change on a regular basis. Particularly when you only need your testers to have the latest version of them, not the complete history (which is what git would give them).

unwind 13y ago

You are fantastically mistaken if you think game devs don't use source control. Heh. Of course they do, and I'm ... let's say pretty sure that much of EA runs on http://www.perforce.com/ http://www.perforce.com/. Also weird that the article starts with a BF4 image, but then claims that BF4 was developed in Californa. I guess that hurts my national pride (go DICE!).

NickPollard 13y ago

Git solves a different problem; sending large binary blobs around is not it. As another comment said, this is essentially RSync, not git. I've been out of game development for a year, but unfortunately git is not being taken up much by large game developers. The main reason cited is actually git's handling of binary files, which leads to every checkout containing many duplicates of huge files. However this is possible to work around and the benefits of git still make it worth it.

js2 13y ago
That said, git does have a delta compression mechanism for reducing disk space and saving network bandwidth that is quite complex: http://stackoverflow.com/questions/9478023/is-the-git-binary-diff-algorithm-delta-storage-standardized http://stackoverflow.com/questions/9478023/is-the-git-binary...
- kzrdude 13y ago
  Git's compromises break down with large enough files. Some git operations still need to have the whole blob in memory at once. Support for chunking of big files would possibly solve this, but the git project is not interested(?).
Negitivefrags 13y ago
The binary file reason is big enough, but it's also the ability to check out a sub tree without checking out the entire Repo. The repo is 1TB and there really is no reason for your texture artist to be checking out the raw uncompressed audio files. The other reason not to use git in game development is because it's incredibly hard to use, and more than half the game development team are not programmers and/or not technical. Getting them to use good source control discipline is hard enough with TortoiseSVN. I shudder to think the insane mess we would have using git.
- NickPollard 13y ago
  So one thing is to use separate repositories - either separate git repos, or use git for code + design data, and something like Perforce for assets. We did this at my first studio (Free Radical Design) and it worked very well. As for git being 'hard', yes it's not trivial to learn, but for people using just perforce/svn etc. they end up misusing so much that it's almost worthless - as Linus said, even just sending around tarballs is better. I think if you're running a team, you need to give your team the benefit of the doubt that they can learn new tools, learn to use them effectively, and be more productive. If you spend some time teaching them why the tools are important and how to use them, then using git isn't really any more difficult than anything else. It's just different.
  - w0rd-driven 13y ago
    This is how I've structured our use at the place I'm at. TortoiseGit is better than svn to me. Submodules are the key though in our situation these are best when they can exist in the same directory structure. We create a master repo with all the design assets, statement of work, and any other useful files for the end product. Then we have a client repo as it were of the files we serve in the wamp www directory. Because this is physically different, submodules make little sense. For the WPF builds that all live together in the same directory structure, submodules are perfect. My only hiccup is remembering to commit the subs via the master but that's a habit I need to change. The files in the wamp repo are deployed to client computers using git pull with a read only ssh key so people aren't committing from them. Our wamp files are primarily text either in straight html or usually PHP. We take care not to commit user editable sections so we don't overwrite what a customer ultimately changes. This is kind of a hand rolled version of the now many git deployment tools out there and it works rather well. I know this isn't gaming nor are our source files that large but the psds can be astronomical very quickly on just simple web pages. I could only imagine what goes into "next gen games". GIT is still useful for binary deltas but you definitely have to carefully plan how you partition things in repositories. If I can do this, really almost anyone can. Kiln brought excellent binary support to Hg so there's really no need to stick to svn. There may be areas where its still useful but the distributed nature of dvcs is just too compelling when your team is well... distributed. I do hear great things about perforce too and I hope any company uses the better vcs not because they think the users can't cope with anything new, but there is extreme benefit for doing so. Again, if I could help our team move into Git with very little hand holding, you would probably be surprised how quickly people adapted. Especially if something like TortoiseGit isn't that much different than TortoiseSvn or TortoiseHg for that matter.

ethanhunt_ 13y ago

I think a lot of game developers actually use perforce because it handles large files better. This is at least what I've gather from eavesdropping some of them (e.g., Jon Blow) on twitter.

NickPollard 13y ago
Perforce is very popular in Games, I think 4/5 studios I've worked for used it. I still vastly prefer git. Perforce does have some pluses, but it's mostly people just going with what they know.

7952 13y ago

When you look at how non-programming projects are managed you often see a lot of the same issues that source control addresses. Files (and information in peoples brains) become out of sync, or need to be locked. Programmers always focus on the technology of source control, but the difference it makes is also social. It forces a particular workflow that allows tasks to be carried out concurrently. This workflow could be adopted without necessarily needing git.