5 ms·

Based on my brief stint in the game development industry, it seems that there are two major obstacles that keep artists from adopting Git. One is the tooling: m

Based on my brief stint in the game development industry, it seems that there are two major obstacles that keep artists from adopting Git. One is the tooling: most of the tools artists use have integrated support for Perforce. This problem is not trivial, but it's something that could ultimately be overcome. A much bigger obstacle is the workflow. The reason why coders can work with a DVCS is because merging in other people's changes is something that can be clearly defined and executed. When it comes to assets, there is no clear definition of whether and how you can merge changes. It's not even clear for which kinds of assets diff and merge are concepts that make sense. There's a lot of work that could be done there, but it doesn't seem like it will be done any time soon, mostly because game development is one of the most single-minded fields in software development industry; the only thing that matters is momentum and meeting the deadlines at all costs (witness the latest Rockstar Games controversy about 100-hour weeks) and everything else is secondary.

pfranz 8y ago
In practice, most people don't expect binary files to diff or merge. It's more about how mergeable groups of files or commits are. I've seen a few tools that diff certain image formats, which can be helpful, but I don't think this is all that different than what Git does with text. I agree that the bigger issue is workflow. Often after setting them up I get asked for a checkout/locking model because that's easier to police and gives you a clear straight-line history (anyone who has used it is also aware of the downsides). Git's permissive system where you can make changes, but then you have to resolve them before committing shifts around the problem. This seems to be more of a problem for them? Maybe because they're more medium-sized and have more of a flat hierarchy? I was going to bring up Unreal Engine. It has had Perforce integration for awhile and Git integration has been in beta (I wouldnt be surprised if that has changed in the last few years). It abstracts everything into the engine UI (so no things like branching). It performed way worse. Their docs have a lot more caveats. https://wiki.unrealengine.com/Unreal_Project_Git_Workflow_(Tutorial) https://wiki.unrealengine.com/Unreal_Project_Git_Workflow_(T... https://wiki.unrealengine.com/Git_source_control_(Tutorial) https://wiki.unrealengine.com/Git_source_control_(Tutorial) To be fair, I don't see indie studios bothering with Perforce, either.
- 4ad 8y ago
  > To be fair, I don't see indie studios bothering with Perforce, either. What then? SVN?
  - pfranz 8y ago
    Nothing. If you're lucky they'll have their own obtuse naming structure of "carrot_model_FINAL_FINAL_12.psd" With something like Unreal Engine, Maya, Photoshop, etc. you can get a few knowledgable artists and build a game with minimal technical skill. If it's not as turnkey as using Dropbox or Windows Backup, they probably won't use it. I started at a place in 2011 that had been open since 1993 and had spun off some software that is industry standard. They were proud they had recently got everyone using SVN. For the entire life of the company teams used whatever they wanted and most used nothing. They're still using SVN.
    - 4ad 8y ago
      I don't understand how it is possible to work like this. As soon as I started learning programming I immediately wished for and imagined some kind of version control. I didn't have to imagine much, as I very quickly learned about cvs (the standard back then). My partner, a scientist, that deals with all kind of data and code and latex has expressed the need for version control too (sadly I have not been able to explain git well enough such that it makes enough sense so she could use it).
      - pfranz 8y ago
        I've gone back and forth (and I probably spend more time thinking about tools at the expense of solving problems). I have a lot of git repos with either 1 commit or where I never even bothered committing. If you're programming you can just tar up the source folder and call it a day. 95% of the use case for VCS is committing to a single tree. Depending on what you're doing, it's rare you'll even look backward. If so, timestamps and usernames are often good enough (you wont even look at the code). It takes a lot of upfront work to be able to write a new unit test then run it on the source history to see when the regression was introduced (even though I think that's really cool). The huge benefit of VCS is project management, which most people brush off as much as possible. Git and SVN provide models where responsibility is clear. For one person, it's a bit ridiculous to stage, commit, push, merge, build, test, release, but necessary when you get a few people involved or what to share the source code. Artists are a different beast. First off, artists are often delivering art and never have to open the project again. It's like if programmers were hired for a couple hours to a couple weeks and only ever handed over binaries with no expectation to ever support or revisit it. For programming, a directory along with a series of files make up a project. For a lot of artist tools there's a monolithic binary project file. Generating "deliverables" are often done manually or configured inside the monolithic project file, where programmers would write a separate build script. Both with programmings and artists they mix project files, intermediate data, and deliverables all together. Programmers and scientists are the only ones with the motivation and technical skill to tease that apart and push for changes.

pfranz 8y ago

In practice, most people don't expect binary files to diff or merge. It's more about how mergeable groups of files or commits are. I've seen a few tools that diff certain image formats, which can be helpful, but I don't think this is all that different than what Git does with text. I agree that the bigger issue is workflow. Often after setting them up I get asked for a checkout/locking model because that's easier to police and gives you a clear straight-line history (anyone who has used it is also aware of the downsides). Git's permissive system where you can make changes, but then you have to resolve them before committing shifts around the problem. This seems to be more of a problem for them? Maybe because they're more medium-sized and have more of a flat hierarchy? I was going to bring up Unreal Engine. It has had Perforce integration for awhile and Git integration has been in beta (I wouldnt be surprised if that has changed in the last few years). It abstracts everything into the engine UI (so no things like branching). It performed way worse. Their docs have a lot more caveats. https://wiki.unrealengine.com/Unreal_Project_Git_Workflow_(Tutorial) https://wiki.unrealengine.com/Unreal_Project_Git_Workflow_(T... https://wiki.unrealengine.com/Git_source_control_(Tutorial) https://wiki.unrealengine.com/Git_source_control_(Tutorial) To be fair, I don't see indie studios bothering with Perforce, either.

4ad 8y ago
> To be fair, I don't see indie studios bothering with Perforce, either. What then? SVN?
- pfranz 8y ago
  Nothing. If you're lucky they'll have their own obtuse naming structure of "carrot_model_FINAL_FINAL_12.psd" With something like Unreal Engine, Maya, Photoshop, etc. you can get a few knowledgable artists and build a game with minimal technical skill. If it's not as turnkey as using Dropbox or Windows Backup, they probably won't use it. I started at a place in 2011 that had been open since 1993 and had spun off some software that is industry standard. They were proud they had recently got everyone using SVN. For the entire life of the company teams used whatever they wanted and most used nothing. They're still using SVN.
  - 4ad 8y ago
    I don't understand how it is possible to work like this. As soon as I started learning programming I immediately wished for and imagined some kind of version control. I didn't have to imagine much, as I very quickly learned about cvs (the standard back then). My partner, a scientist, that deals with all kind of data and code and latex has expressed the need for version control too (sadly I have not been able to explain git well enough such that it makes enough sense so she could use it).
    - pfranz 8y ago
      I've gone back and forth (and I probably spend more time thinking about tools at the expense of solving problems). I have a lot of git repos with either 1 commit or where I never even bothered committing. If you're programming you can just tar up the source folder and call it a day. 95% of the use case for VCS is committing to a single tree. Depending on what you're doing, it's rare you'll even look backward. If so, timestamps and usernames are often good enough (you wont even look at the code). It takes a lot of upfront work to be able to write a new unit test then run it on the source history to see when the regression was introduced (even though I think that's really cool). The huge benefit of VCS is project management, which most people brush off as much as possible. Git and SVN provide models where responsibility is clear. For one person, it's a bit ridiculous to stage, commit, push, merge, build, test, release, but necessary when you get a few people involved or what to share the source code. Artists are a different beast. First off, artists are often delivering art and never have to open the project again. It's like if programmers were hired for a couple hours to a couple weeks and only ever handed over binaries with no expectation to ever support or revisit it. For programming, a directory along with a series of files make up a project. For a lot of artist tools there's a monolithic binary project file. Generating "deliverables" are often done manually or configured inside the monolithic project file, where programmers would write a separate build script. Both with programmings and artists they mix project files, intermediate data, and deliverables all together. Programmers and scientists are the only ones with the motivation and technical skill to tease that apart and push for changes.