4 ms·

A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc. And git can sti

by malkia 12y ago

A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc. And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.

SoftwareMaven 12y ago
Perforce also handles large binary blobs better as well, which is super important in game programming.
- yoklov 12y ago
  Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git). We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art. This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.
zanny 12y ago
How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.
- rtpg 12y ago
  I think perforce deals with binary files better too (not sure of the details)
- virtue3 12y ago
  git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets). This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid. http://stackoverflow.com/questions/3055506/git-is-very-very-slow http://stackoverflow.com/questions/3055506/git-is-very-very-...
  - teraflop 12y ago
    FWIW, git will never store two copies of the exact same file in the same repository, since the blobs will have the same SHA-1 hash.
    - yoklov 12y ago
      Sure, but that rarely matters here, as artists are working on the assets.
    - virtue3 12y ago
      Right. But when you change one thing in the the PSD git can't do a diff and store the diff. Which means you now have basically the same 500meg file duplicated. SVN and the like will attempt to store the binary deltas instead of duplicating the files. I don't believe git can actually do this due to the way branches / git itself works (it doesn't have a simple #1 - #2 - #3 ... #n commit chain setup) There are plugins for handling binary assets better but they aren't great. and/or it just makes it less intuitive for the non-programmers which really defeats the whole purpose. I absolutely _love_ git and I'm 99% sure this issue will be worked out at some point. I've seen teams just use git for the code and then use something else for art assets (alien brains or something).
      - Dylan16807 12y ago
        Git packs are mostly made up of deltas. Git is remarkably efficient at diffing files. And because it's all handled at the the storage level it doesn't matter what order the files are in, it generally packs all the revisions of a file from largest to smallest with the a compression window several versions wide. The problem is that it's still a lot of data when you have significant binary assets. Edit: The default is to delta files up to half a gigabyte in size.
- jp_sc 12y ago
  And what when, suddenly, vim appears and they have no idea of why or how to close it?
  - tnorthcutt 12y ago
    At what point would Vim appear when using a gui client for git?
  - virtue3 12y ago
    the github client is actually extremely artist friendly.
    - yoklov 12y ago
      Not much commercial game development goes on on github, which IIRC is the only way to use the github client. (Where I work we have a local gitlab.)
      - lmm 12y ago
        Since commercial developers on github presumably use private repositories, how would you tell?
      - joshuacc 12y ago
        You can use the github client with non-github repos as well.
    - golergka 12y ago
      But not particularly stable. At least when I tried to use it about a year ago
    - maccard 12y ago
      As is sourcetree, and not tied to github
- jkrems 12y ago
  I think the bigger point is that game studios check in assets. And you don't want the complete history of game assets over 2 years of development and iteration on your machine. And git is generally not optimized for huge binary files.
- keypusher 12y ago
  Having used both extensively, Perforce workflow is just a lot easier for a layperson to understand. Add files to changelist, move files between changelists, remove file from changelist, check it in. It has a nice GUI and command line tools. With git you have staged files vs commited files, commit vs push, multiple commits and the need to rebase, difficulty of removing a file from the commit before push, not to mention lack of a good built in visual merge solution tool and stuff like detached head state. Git also has a more complex command line, and multiple UI choices, none of which are great. I love git and it is my vcs of choice, but just because we know, love, and understand it doesn't mean intern Katie from the art team is going to feel the same way.
- to3m 12y ago
  It's not the GUI that's the problem. The difficulty comes when you pull/fetch-merge and somebody has pushed a change in a file you're editing. Binary files aren't easy to merge, so now you're going to lose your changes, or they're going to lose theirs. This is the problem the check in/check out (lock/unlock, whatever) mechanism is designed to solve. It gets in your way a bit when working on files that could be automatically merged, but it's completely necessary when working on files that can't. A system like perforce stores the files read-only on disk, and makes them writeable when you check them out. To do that you visit the perforce GUI and try to check the file out; if somebody else has the file checked out already, the server will tell you who it is, so you can go and talk to them and decide how you're going to order the edits. (Because of the read-only flag, even if you don't check out at least the files you know you'll need before you start work (which you should do), you at least find out immediately when you try to save. So even if you then end up losing a bit of work - it happens - you at least won't get too far into your work before finding this out.)
skittlebrau 12y ago
Also, "exclusive checkout" is something that doesn't even really make much sense in git, but is important for people collaborating on non-mergeable assets (3D models, textures, etc). We end up using git for code and in-game assets but p4 for source art assets.
DanielRibeiro 12y ago
Some small game studios also don't use git. Famous indie developer Jonathan Blow[1] said they had 20GB of data on a svn repo 6 months ago: https://news.ycombinator.com/item?id=6745412#up_6746172 https://news.ycombinator.com/item?id=6745412#up_6746172 [1] Braid here if you haven't: https://www.youtube.com/watch?v=uqtSKkyJgFM https://www.youtube.com/watch?v=uqtSKkyJgFM
j_s 12y ago
Plastic SCM is targeting Perforce users who want to go to a distributed model.

by malkia 12y ago

SoftwareMaven 12y ago

Perforce also handles large binary blobs better as well, which is super important in game programming.

yoklov 12y ago
Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git). We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art. This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.

zanny 12y ago

How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.

rtpg 12y ago
I think perforce deals with binary files better too (not sure of the details)
virtue3 12y ago
git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets). This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid. http://stackoverflow.com/questions/3055506/git-is-very-very-slow http://stackoverflow.com/questions/3055506/git-is-very-very-...
- teraflop 12y ago
  FWIW, git will never store two copies of the exact same file in the same repository, since the blobs will have the same SHA-1 hash.
  - yoklov 12y ago
    Sure, but that rarely matters here, as artists are working on the assets.
  - virtue3 12y ago
    Right. But when you change one thing in the the PSD git can't do a diff and store the diff. Which means you now have basically the same 500meg file duplicated. SVN and the like will attempt to store the binary deltas instead of duplicating the files. I don't believe git can actually do this due to the way branches / git itself works (it doesn't have a simple #1 - #2 - #3 ... #n commit chain setup) There are plugins for handling binary assets better but they aren't great. and/or it just makes it less intuitive for the non-programmers which really defeats the whole purpose. I absolutely _love_ git and I'm 99% sure this issue will be worked out at some point. I've seen teams just use git for the code and then use something else for art assets (alien brains or something).
    - Dylan16807 12y ago
      Git packs are mostly made up of deltas. Git is remarkably efficient at diffing files. And because it's all handled at the the storage level it doesn't matter what order the files are in, it generally packs all the revisions of a file from largest to smallest with the a compression window several versions wide. The problem is that it's still a lot of data when you have significant binary assets. Edit: The default is to delta files up to half a gigabyte in size.
jp_sc 12y ago
And what when, suddenly, vim appears and they have no idea of why or how to close it?
- tnorthcutt 12y ago
  At what point would Vim appear when using a gui client for git?
- virtue3 12y ago
  the github client is actually extremely artist friendly.
  - yoklov 12y ago
    Not much commercial game development goes on on github, which IIRC is the only way to use the github client. (Where I work we have a local gitlab.)
    - lmm 12y ago
      Since commercial developers on github presumably use private repositories, how would you tell?
    - joshuacc 12y ago
      You can use the github client with non-github repos as well.
  - golergka 12y ago
    But not particularly stable. At least when I tried to use it about a year ago
  - maccard 12y ago
    As is sourcetree, and not tied to github
jkrems 12y ago
I think the bigger point is that game studios check in assets. And you don't want the complete history of game assets over 2 years of development and iteration on your machine. And git is generally not optimized for huge binary files.
keypusher 12y ago
Having used both extensively, Perforce workflow is just a lot easier for a layperson to understand. Add files to changelist, move files between changelists, remove file from changelist, check it in. It has a nice GUI and command line tools. With git you have staged files vs commited files, commit vs push, multiple commits and the need to rebase, difficulty of removing a file from the commit before push, not to mention lack of a good built in visual merge solution tool and stuff like detached head state. Git also has a more complex command line, and multiple UI choices, none of which are great. I love git and it is my vcs of choice, but just because we know, love, and understand it doesn't mean intern Katie from the art team is going to feel the same way.
to3m 12y ago
It's not the GUI that's the problem. The difficulty comes when you pull/fetch-merge and somebody has pushed a change in a file you're editing. Binary files aren't easy to merge, so now you're going to lose your changes, or they're going to lose theirs. This is the problem the check in/check out (lock/unlock, whatever) mechanism is designed to solve. It gets in your way a bit when working on files that could be automatically merged, but it's completely necessary when working on files that can't. A system like perforce stores the files read-only on disk, and makes them writeable when you check them out. To do that you visit the perforce GUI and try to check the file out; if somebody else has the file checked out already, the server will tell you who it is, so you can go and talk to them and decide how you're going to order the edits. (Because of the read-only flag, even if you don't check out at least the files you know you'll need before you start work (which you should do), you at least find out immediately when you try to save. So even if you then end up losing a bit of work - it happens - you at least won't get too far into your work before finding this out.)

skittlebrau 12y ago

Also, "exclusive checkout" is something that doesn't even really make much sense in git, but is important for people collaborating on non-mergeable assets (3D models, textures, etc). We end up using git for code and in-game assets but p4 for source art assets.

DanielRibeiro 12y ago

Some small game studios also don't use git. Famous indie developer Jonathan Blow[1] said they had 20GB of data on a svn repo 6 months ago: https://news.ycombinator.com/item?id=6745412#up_6746172 https://news.ycombinator.com/item?id=6745412#up_6746172 [1] Braid here if you haven't: https://www.youtube.com/watch?v=uqtSKkyJgFM https://www.youtube.com/watch?v=uqtSKkyJgFM

j_s 12y ago

Plastic SCM is targeting Perforce users who want to go to a distributed model.