[danbolt]

In the AAA games industry git has been a bit slower on the uptake (although that’s changing quickly) as large warehouses of data are often required (eg: version history of video files, 3D audio, music, etc.). It’s nice to see git have more options for this sort of thing.

[Keverw]

Surprised this new idea doesn’t support object storage. Sounds like Git LFS would still be the right way to go for repos with assets for games like meshes, sounds, etc.

However I’ve heard many studios use Perforce instead. However not being open source is a downside to some, but I don’t really know too much about it personally.

Then if working with a lot of non code files, sounds like some solutions have locking. I guess not two people could edit the same Blender or PSD file at the same time and then merge them later on.

Kinda wouldn’t surprise me if some companies actually run multiple versioning control systems. Code on one system, game assets on another.

[danbolt]

I think in terms of game production, software licensing usually isn’t the largest cost center for a project. Proprietary software isn’t a concern as much, given that games traditionally are “shipped” and then completed. (Note that this changes as games that are more online service-based with live operations, rather than a specific release date and a “final” copy sent for production; the internet has changed things a lot)

You’re more right than you think about multiple versioning systems, although keeping synchronized becomes an issue. Perforce is a bit of a boon for management, as they get a GUI for versioning across a multidisciplinary team.

[jfkebwjsbx]

Git LFS has been a thing for years, though.

[danbolt]

You’re absolutely right, but larger developers and publishers have been slower to adopt.

P4’s GUI/model is also intuitive for non-programming roles to learn and use historically compared to git, so a team with wide skills can ramp up quickly with a unified toolset. A less-technical manager gets a GUI that has versioning across changes from a multidisciplinary team. You can probably guess what inertia that has in a space with higher turnover compared to other industries.

As mentioned, things are changing though. git and GitHub have become a mainstay and are what new programmers likely learn in schools. This has a trickle effect on new projects with smaller teams and results in more investment into git setups. I use git in a AAA context at work, and it’s not uncommon to find sentiments from more seasoned game programmers on git that are similar to HN comments about the latest fad in web frameworks.

[jfkebwjsbx]

The problem is that you blamed Git, rather than your legacy workflows and corporate culture.

And again, you keep blaming Git here, now around a lack of intuitiveness and a lack of GUI. Again, Git has multiple GUIs around to choose from and multiple integrations with almost any editor and IDE you can think of, some meant for beginners and trivial usage.

And no, things are not "changing" and Git is not to be compared with a "web framework fad". Git became the version control system more than 5 years ago.

[danbolt]

Sorry if my tone came off as blaming like you said. I didn't mean to be blaming git or holding it responsible for something. I see a lot of existing inertia for Perforce in the AAA game development industry, and wanted to express that.

I think you're correct in that git is the go-to version control software. I'd reach for it as a default tool every time. I do work with older programmers where the majority of their careers have been in Visual C++ and Perforce, and I've definitely heard sentiments seeing it as wheel-reinventing. I don't agree with them, but it's what I've experienced.

[dagmx]

So I fully agree with you, but one area for more artist heavy workflows where git still struggles is ease of use.

The two biggest issues are: - git lfs doesn't automatically identify large files or binary files. So it's very easy for even experienced engineers to have set up lfs but forgotten to track a file or extension

- git exposes too much of its internals. It's really cumbersome for artists even with UI tools.

That's not to fault git as a technology but I think there's a place for an artist friendly layer on top of git, perhaps a very artist centric UI and set of tools and workflow guides