Initial perforce structure

Question

I'm trying to setup an initial perforce structure for a small game.

I'm familiar with SVN and SCMs in a "classic" (read source code only) usage.

After some research, it seems Perforce is the way to go for managing source and binary content, like models, textures, sounds ...

But, to be honest, I'm struggling a bit finding a good structure.

I want to put everything in source control, so that means the artists source files, plus the game source code.

The stream depot seem nice for the devs / source code, but a bit cumbersome for the artists. I don't think the artists will be happy having to manage the streams and the copy/integrate into branches.

So, my idea, is to put everything into a plain depot and then have another stream depot to add the "icing" on top.

The problem is I don't know if it's possible or how. I think I recall one forum post of someone having setup a stream that would mirror a "standard branch", but I could not find it.

Unfortunately my google-fu failed me, so I'll ask here :

Is there some kind of "standard" or "recommended" perforce setup for game related development ? I could not even find one full example :/
Can I make a stream that will "mirror" a standard branch on a plain depot ? If so, how ?

Thank you.

Samwise Samwise · Accepted Answer · 2015-09-15T18:31:54

I'd lean towards using streams for both groups and putting them each in their own depot, but there's not necessarily one right way to do this. Here are some data points about streams to consider:

Streams don't necessarily imply branching; you can have one "//art/main" stream that the artists work in exclusively. There's no inherent reason they'd need to create and maintain branches (except for the reasons you'd normally create branches, but those might not apply to your art assets the same way they do to your code).
The benefit of using streams beyond managing codelines is centralized management of client specs -- suppose you notice that all the artists are submitting giant generated ".foo" files that don't need to be in the depot. Rather than trying to get all your artists to add "-//....foo" lines to their client specs, or messing around with triggers, you add one Ignored line to the "//art/main" stream spec and it affects everyone using that stream.
You can pretty easily share content between the "art" and "code" sections of your repository whether both teams use streams, one team does, or neither.

Supposing you set up an "//art" stream depot (with an "//art/main" stream) and a "//code" stream depot (with "//code/main" plus whatever other streams it makes sense to create -- dev streams for different coders who want to work on different features in isolation before merging them together, etc). Within your "//code/main" stream you add this Path:

import art/... //art/main/...

Now everything from "//art/main" shows up in an "art" directory under clients of "//code/main", as well as clients of child streams like "//code/sadral". Note that this exact same syntax works if the art lives in a "local" depot rather than a "stream" depot -- depot files are depot files.

If you end up needing to isolate certain versions of the art assets, keep in mind that you can create branches in the //art depot without the artists needing to be involved; they just keep working in //art/main and someone else can take care of branching/copying things around as needed during the development process.

Initial perforce structure

2 Answers