We are assuming you guys are still using the same P4 Stream Structure that was announced on this video
That is referenced [Content removed] and [Content removed]
You can also see some reference to it in this video
Now I have a couple of questions regarding this
1- Do most people work in main and only some people that are working directly on the release move to the release branch?
2- Are you guys still doing new features directly on main? What if you have a feature A and a feature B that are for different releases?
3- Is the stream structure a big “line” (not using the word branch here to not confuse with p4 branches. Or do you actually fork out at main releases. With having 8 and 9 on a different stream branch?
3a - does it look like this?
[Image Removed]
3b - or does it look like this
[Image Removed]
3c - somethine else
Hey there Marcos,
1- Do most people work in main and only some people that are working directly on the release move to the release branch?
- Yes, most work out of main. We use robomerge to coordinate between our release branches etc.
2- Are you guys still doing new features directly on main? What if you have a feature A and a feature B that are for different releases?
- New features are primarily on main. Longer tail initiatives tend to be feature branches. At a certain point we create a dev-fortnite-RELEASENUMBER branch
3- Is the stream structure a big “line” (not using the word branch here to not confuse with p4 branches. Or do you actually fork out at main releases. With having 8 and 9 on a different stream branch?
- It’s really important to disambiguate how we coordinate changes, vs what the “stream-branch” structure is.
- For a major version, we will indeed have a dev-fortnite-{MAJOR-RELEASE-NUBER} ; with a similar view to 3b
- Our robomerge works a lot more like 3a, insuring that we coordinate changes between the releases.
I hope that clarifies things or you.
Kind regards,
Julian
Hey Marcos,
I can’t give too many specific details around Fortnite, but I can talk about some more high level concepts that we employ.
- I’d highly recommend reviewing Game Feature Plugins. This is a way that you can create optional content to the game, and as such, you can sequester
- You can control what folders are being robomerged, such that you don’t include the content to be replicated over into the release branch until it’s ready
- E.g. Engine\InternalOnly
- E.g. Engine\Plugins\InternalOnly
- This is more or less a strategy that we employ even within engine dev to keep internal BuildGraph scripts separate from our formal release
With the above two, you should be able to reasonably control:
- Modular feature & content development
- Integration/replication therein
I hope that helps, and gives a couple of mechanisms that we utilize internally at a conceptual level in order to keep development modular, and control the flow of changes.
Julian
Hey Marcos,
I think my previous answer may have been a bit incomplete and/or misleading. For RoboMerge, you’d just make sure the branch-mapping that’s being used has said folders filtered out. Corresponding Perforce documentation on how to update branchmapping with excludes.
Kind regards,
Julian
Hey there Marcos,
It’s not done with virtual streams, but instead branch mappings such as:
//UE5/Engine-Dev-Release-Branch-5.6/Samples/... //UE5/Main/Samples/... //UE5/Engine-Dev-Release-Branch-5.6/Sandbox/... //UE5/Main/Sandbox/... -//UE5/Engine-Dev-Release-Branch-5.6/Samples/JulianSample/... //UE5/Main/Samples/JulianSample/...That is to say, Robomerge will utilize that branch mapping and make sure that it observes the proper mapping details.
So what is your ROBO:R10.10->R10.20 definition when you look in perforce?
Julian
Hey thank you for the answer and it clarifies it.
Just one small extra note, if everyone works on main, how do you prevent things to “leak” to players for a release that is not suppose to be out yet.
Example, if we have a team working on mechs in main to a later release, let us say 50. But then we create release 49. It will have some of that content/feature in it.
Even if it’s disabled (even if we use a modular gameplay system), at least some content will be there.
Do you use a folder strcuture for this and remove that part out of cook in the release 49 stream, any other option, or maybe it’s not an issue for Fortnite?
Ok that sounds good. Thank you.
We tried looking on how to block folders from robomerge and we couldn’t find one, but now that we know it’s possible we will look harder.
Apologies for ressurecting this.
We were trying to follow your suggestion but we couldn’t find a way to set a view/workspace/ignore_list in the robomerge branch mapping.
So is this done with virtual streams?
Or do we have to create a branch mapping(ROBO:R10.10->R10.20) in p4 and just set it in like this
“branchspecs”: [
{
“name”: “ROBO:R10.10->R10.20”,
“from”: “R10.10”,
“to”: “R10.20”
}
]
Or something in robomerge that we are missing.
Thank you.