Download

How to work with source control on one map

In our team two guys are working with assets related to the same map. One is modifying a static meshe in Blender and updating it in Unreal, the other guy is working on an actor Blueprint. That is, two completely separated assets. However, both these assets are used in the same map/level.

Now the issue is this: we are using UE4 built-in source control (SVN). Now when guy A updates his asset, Unreal asks to check out and save both his asset and also the map. Now guy B saves his (other) asset, so Unreal asks him to check out and save both as well, his asset but also the map again.

Obviously this leads to a problem, as both guys need to check out the map file alongside “their” current assets. But it’s not possible for both to check out the map file. This basically leads to the situation that it seems to be impossible to work simultaneously on two completely different assets, if both are used in one map.

Is there any supposed way of dealing with this issue?

Using Perforce here. Still, don´t really get while the map has to be checked out. If you don´t check out the map or you only check out the asset you modified there shouldn´t be an issue. For me, when I check in, a new windows opens where I can tick and untick every object I want to check in. So you can always untick the map there.

But if one has checked out an asset, like the map, isn’t it locked then for everyone else?
So how can one check out an asset and another one check it out as well?

Yeah, this workflow won’t work with map asset, but there is a cool plugin in development - I think it is exactly what you’re looking for

Thanks for the link, that is definitely something to check out. I am wondering though … I am pretty sure we are not the only dev team struggling with this issue. How are we (officially) supposed to work around this limitation? Has there been any feedback from Epic directly?

Even though there is always a need for some form of source control the level of source control required for a small team is not really necessary as say for a much larger team where not everyone knows who is working on what at any given time.

In the later case it makes sense to check out the file and lock any further changes so that no one comes through the front door and mess things up. This more or less creates a software based ownership of the complete project in hand and no further work can be done until the complete project is released.

As to your example you don’t need this level of of “project” control but rather set up an asset chain that gets updated through the iteration process and more so when talking about art assets like static mesh and textures.

Keep in mind asset chains and source control are two totally different things.

Source control is about who owns what as part of the total project and asset chains are used to introduced changes to the project with out the need to check out the entire project that in turn makes you the owner.

The solution to the problem is to give ownership of a project file to an individual full time and let them manage what gets updated through the asset chain.

A good example of how 3ds Max manages just another asset chain is by X-referencing.

In your case the dev modifying assets in Blender does not need to have ownership of the project but rather push the “iteration” through the source chain, most cases FBX, that gets updated the next time the project is loaded just like an x-referenced file.

Perhaps you could make a temporary sub level for one of the assets

Thanks for all your replies. Somehow I feel that there must be some kind of “best practice” how to deal with this issue. I can easily imagine that very many game dev teams work somehow like I have described above: One guy works in Blender (or alike) and iteratively checks his or her changes within Unreal (or alike). Something like making the asset a bit bigger, checking how it looks within the level in the UE editor, no, rather not that big, check it again in UE, add another detail and check again in UE to see how lighting looks with it, and so on.

In the meantime another dev in the team is working on the same map, but on another asset. For example he or she updates the logic associated to some event triggered by something. He runs and debus and runs and fixes and runs and adds a bit more and so on.

I would assume this should not be a problem at all, since both are working on two completly different things. But still, in UE4 source control this approach leads to a quite severe difficulty, if everytime the whole map needs to be checked out / saved / checked in again.

It’s hard for me to think of this as an exotic workflow. Isn’t that quite a usual way of working together in a (small) game dev team? Of course, as Crushed suggested, it would be possible to create a new test level for one of the assets. But that feels more like a workaround than a real solution …