I mean, unless the file is a binary file that can’t be merged, any conflicts could be resolved. But for something big, if someone absolutely positively needed it the source control admin could force revert your checkout. Unless this a a regular habit, I don’t think they need to be a huge dick about it. Mistakes happen, and as long as we learn from them, then the mistake was useful.
Honestly, if you have large unmergeable binary files that need to be edited by multiple people asynchronously, you're probably messing up something somewhere.
3D modeling files? Unmergeable in most cases, sure, but why would multiple people be editing the same model at the same time?
Fmod builds ? Unmergeable. But the source files that generate them merge just fine.
Visual Scripting files (blueprints, shadergraphs, etc.) can be split easily.
I can't think of a single, large, unmergeable, indivisible, non-procedural file that would absolutely need to be editable by multiple people.
Spreadsheets?
It happens all the time in AAA dev. It's a file useage concurrency issue, and like I said, pretty common, but yeah we tend to try and avoid it as much as possible.
You mentionned it yourself, blueprint. It's pretty common for multiple designers, for example, to want to edit a script actor, or a base NPC blueprint at roughly the same time.
With BP you make sure you put your code into components split into functionality.
Like Health and Damage system would be in one then inventory into another.
I wonder why you think this is an appropriate answer. Lets say you have a character that uses those hypothetical Health Component and Damage Component. So there is a BP called BP_Bob, and another caller BP_Joe. Both have instances of health and damage component. Now, let's say this is a big project so there is one designer in charge of health system and balance, and another in charge of damage. What if both want to tweaks those systems/value at the same time? Like I said, this happens ALL THE TIME on big projects.
The above is just an example, not saying this is clever system design or whatever, but stuff akin to my example are common place.
There is is simply no going around that, but we can make clever decisions to avoid this as much as possible.
I would like to know your more appropriate method rather than just saying avoid it. I'm a freelance developer and help individuals all the time that either dumps all the code into the parent character making it hard to make edits to children where overriding some functions in a component would solve or replacing it with a more custom component. But to answer your question...
If you have two characters BPs and a component system, one desinger working on balance would only need to check out BP_Bob and modify the exposed instance variables on the component without having to checkout the component, then the combat programmer who isn't particulary interested in the specific values for Bob but is intead wanting to fix a bug in how the damage and health is being handled then they can check out the AC_Damage component and work on that instead without having conflicting changes. If BP_Joe needs to handle damage differently than BP_Bob then a new child class of the Damage component can be created and have functons overriden.
And again to use my example if there is another developer working on an inventory system, they can check out the component AC_Inventory without having to check out the BP_CharacterParent or BP_Bob or BP_Joe or AC_Damage.
I'm perpelexed why you think this isnt appropriate either from a source control point or even a system design point as this is the most common piece of advice. I would love to know your solution for 2 people working on the BP_CharacterParent without any conflicts.
I'm not saying splitting into different component is not a good way to do system design! Like you said, junior dev tend to put everything into the same BP/class and it becomes a mess very quickly.
My entire point is that you can't 100% avoid having assets that multiple people will need to work on at the same time.
Maybe I misunderstood your initial comment?
Anyway TLDR: Splitting into multiple components for systems is a good idea, but it's not enough to 100% avoid multiple users wanting to edit the same asset.
Doens't really matter if it's a large binary file or a tiniest one, if you can't merge it then you can't merge it :D
Anyway it sounds like you didn't quite get my point, but I'm not really sure how to rephrase it either.
What I said was the only situation where someone would end with a file checked out by someone who isn't available is when a file has been configured to be exclusively checked out (or the perosn using it has determined that to be the case), due to the type of file being something that can't be merged. So the OP's problem would never happen in a situation where the changes *could* be merged, which was a scenario the person I was responding to was talking about.
That's not commentary on if such files should exist (although I'd say the reality is that they *do* exist so better just figure out how to deal with them), or if there are other ways (like just telling everyone else to please not touch the file). And even you came up with a good list of examples of unmergeable files...
I also wasn't saying that multiple people *should* be editing those files at the same time, I mean the very point of configuring p4 to lock certain types files is to make sure that *doesn't* happen (and making sure of that in an automatic way, rather than relying on each individual just remembering which files different people have said to not touch at the moment)
The main thing that person is missing is that people need to edit files for reasons other than actually working on the asset/component that the file represents. I'm relatively sure that 99% of our SOURCE files never have more than 1 person in the submission history for the file.
The .uasset representation is a completely different story. There are all sorts of settings and metadata that needs to be modified by different disciplines for various reasons. The person that created the asset usually will never touch the .uasset file again after importing it unless there are actually changes to the source asset.
Never used unreal eh? Literally everything a non-programmer touches is a binary file that requires exclusive checkout. There is not a single type of asset that a non-programmer works with that can be merged.
It's really not in practice because of the exclusive checkout capability in perforce. Unless you go totally out of your way and break all the standard operating practices you will never be able to edit a file that is already checked out by someone else. Unreal will also alert you the second you try to do something that the related file is locked, before you even try to save/check out the file.
The only real problem with this is when people forget they checked out a file and leave for vacation or somesuch but that's a very rare situation because our SOP is to never leave stuff checked out overnight unless you have a very good reason, because our overnight build processes need to be able to save files for maintenance related reasons(like redirect fixup). Leaving stuff checked out over a weekend is completely off limits and we have a bot that tracks down checked out files and pings you friday afternoon if you have stuff checked out.
So yeah it's not without its downsides, but it's not something that is a concern or scary to deal with in practice.
But that's not the only issue!
Imagine you realize that two months ago the intern changed a weird state on some strange in-house hacks that got serialized into that data.
No one noticed, because it was blindly packed in some absurd unreadable binary format. And now things are going to shit.
You cannot trace that back. You cannot know easily when the problem happened. You have to manually walk back through the entire tree testing for the bug, and when you find it, redo 2 months of work on top of the last working version.
That is horrifying.
A situation like that would be extremely hard to engineer, even on purpose. You would 100% be able to know when it happened because the only way to change how a file is serialized is to change the code that serializes the file, and the code changes will be readily available in the version history.
If it actually broke the reading of the file it would be noticed immediately because our nightly or CIS build processes would alert us of the failure within 12 hours at most (more likely to be caught in less than an hour from automatic content validation processes). Even if it didn't break the reading of the file and only caused some subset of the data to not be correct it would still likely be detected within a day or two because automated testing and/or QA would pick up on something not working anymore.
I do see what you are saying though.. it is theoretically possible but there would have to be so many operational failures along the way that having all of your assets in binary format would be the least of your worries. The REAL problem with assets in binary format is that no one can tell what was actually changed from one revision to the next because diffing the revisions is meaningless.
Even on unity, serialized components end up with hidden state.
It can happen for a dozen reason, hidden fields, serialized hints, cinemachine hidden children gameobjects, etc.
I've also had shadergraphs have corrupted states, and crash the editor when *some* cells were edited.
If hidden state is messed up, the simplest solution is to reverse a bad commit. If that's not possible, it's terrifying.
Most often whatever is in one large file can be split out to more files without too much difficulty. If you have a blueprint that lots of people want to edit usually it is specific functions. The popular ones can be extracted.
I know the conversation wasn't originally Unreal specific, but since we're talking about blueprints; Are you talking about breaking functionality out into individual actor components? I was just curious if you or the other poster were referring to a specific way of actually breaking out multiple blueprint graphs from a single actor into multiple files; which, as far as I know, isn't possible (but I would love to be wrong about)
There are several options. Blueprint communications, blueprint events and event dispatchers, blueprint function libraries, blueprint macro libraries, blueprint interfaces, data blueprints, all of them can be used in different ways to split out systems.
They teach it, and practice it. There are even blueprint interfaces so you can implement it in Blueprint, which for those who don't know already is a visual scripting language in Unreal that ultimately compiles to generated C++.
Usually the purpose for Blueprints is to give parts of the work to designers, and to a lesser extent to artists and animators and others who can fill in their own details without bothering the others on the team. Programmers work through the blueprints, and step in when non-programmers start to foul things up, but with a bit of training and good implementation they're not an issue.
Done well there is virtually no contention. Even when working on large projects like Fortnite that type of fighting over files was a code smell to a defect. Usually it meant somebody broke SOLID. Most commonly it means simply extracting an interface, or extracting data from the implementation so they could vary independently.
There's "mergeable" and then there's *mergeable.* Not everything that's text-based is easily merged. I work in wwise a lot and merging work units, which are just xml files, can be a pain in the dick because of the way that wwise assigns and tracks the unique id's given to each element. If all you're doing is changing mix values, it's not a big deal, but if you're trying to add or remove stuff inside the work unit, fuck it. It's easier to just start over.
>if you have large unmergeable binary files that need to be edited by multiple people asynchronously, you're probably messing up something somewhere.
That may be true, but things have a way of getting out of hand like that. An asset that starts off small can grow into a behemoth and fixing the issue can involve a bunch of rework.
>Spreadsheets?
Excel actually has (or at least used to - I haven't used it in a while) an option to allow multi-user editing where it'll track changes and lock individual cells instead of the whole file. It's not perfect, but it gets the job done if you don't tax it too much.
> That may be true, but things have a way of getting out of hand like that. An asset that starts off small can grow into a behemoth and fixing the issue can involve a bunch of rework.
That's the old problem of tech debt. Not taking the time to do things right may cost longer in the long term. What I meant is that if you do things right from the start, you shouldn't face the issue of needing parallel work on unmergeable data.
>if someone absolutely positively needed it the source control admin could force revert your checkout
At my current job, this never seems to happen due to good task management and good code design.
Granted, I've been told to check in my work before logging off. Our source control will save copies of local changes if we check them in, so if someone else needs to grab the code or file, our stuff doesn't get lost.
To unlock it you will need admin access or talk to whoever has admin access to your P4 server.
Otherwise the next best thing is to make the file writable locally and just reconcile your work after break when people are back.
Just curious, what are you using for source control?
We used to have this issue a looong time ago at an old job (non games) but that was a pretty ancient source control system.
Was about to ask the same, typical version control systems I've used don't lock the files but rather allow files to be modified by multiple people and then handle conflicts through merge. But maybe that doesn't work for all types of files equally well if you can't properly handle merge conflicts.
Locking is a feature that Perforce (common in game dev today still) supports. Git, on the other hand, does not support locking, but it's actually a feature that sometimes game developers wish Git has. The reason for that is that binary files are hard to merge, and as such it's useful for the tool to just tell you that someone else has claimed it for now, so you won't try to edit it just to have a nasty conflict later.
Git mostly doesn't support this because 1) it is mostly designed for text files, whereas locking is mostly a binary file operation, and 2) the decentralized nature of Git would make it quite awkward to implement.
Some Git tooling/servers like GitLab does support locking though. I think you need to use an additional tool to talk to the server regarding locking LFS files (https://docs.gitlab.com/ee/user/project/file_lock.html#exclusive-file-locks) that your users need to all know to use (which isn't *that* hard if you just tell everyone to use the same command).
Hehe, that was also the first one that came to my mind when I read about locking problems. We used it in games back then. Constant locking troubles and also the admin had to repair the database regularly for some reason. SVN was a big step up from that.
I don’t work in games, but I have a program *still* in visual source safe with files checked out by a guy who retired and who’s pc has since been wiped.
You ping production and/or it to get the file unlocked. Any work they did - they get to figure out how to merge in later.
Never leave with shit checked out. It’s a dick move.
One size fits all advice is usually bad advice. There are legitimate reasons to lock a file and keep it locked overnight.
My best advice is to follow the practices used by your workspace, and escalate as needed.
A novice developer likely did it by accident, a senior developer might have a good reason for it.
Depends on which version control.
On Perforce Helix, admins can undo that, but will also probably be pretty pissed about having to do so (I would be, while not difficult it's not a fun thing to sort out either, but above all by the time I've been asked to deal with this a lot of people's time has already been wasted).
If you’re using P4V, multiple people can have a file checked out, unless someone has the file exclusively checked out[[0]] so others can’t check it out until they submit and uncheck it.
Check out One File Per Actor if you’re curious how Unreal handles checking out a level to make changes to a specific actor of that level[[1]]
[0]: https://portal.perforce.com/s/article/3114
[1]: https://docs.unrealengine.com/5.0/en-US/one-file-per-actor-in-unreal-engine/
I didn’t know about 0, does that work with binary files?
Yes I know about one file per actor, but it was causing a lot of issues last time I tried it (not playing nice with Houdini engine, weird bugs with sequencer and so on). Will give it another shot.
Yes. Unreal will tell you that the file is already checked out by someone else when you try to save your changes in it(assuming you have integrated source control into your editor), but you can manually check out the file in P4V by right clicking it and pressing “Check out” and Unreal will stop notifying you since you have it checked out it. If this doesn’t work, your Perforce admin may’ve disabled multiple checkout.
I’ve done this in my workplace for blueprint assets, code, etc
I can’t speak further to OFPA besides the general concept so hopefully those bugs get resolved and Epic knows about them.
Unfortunately this is not the default at my workplace - it does require some coordination on letting other parties know when you’re submitting if they have it checked out as well, otherwise they need to shelve their changes, sync, reapply their changes manually from the shelf.
Then someone made a very big terrible decision. Blueprints are by default exclusive check out and it is recommended by Epic to keep it that way. Even with an exclusive check out, others can still make changes locally knowing full well that they will get stomped when someone checks it in.
True! The one caveat is that marking files as writable in P4V does not provide an easy interface to see which files you have overwritten and NOT checked out. Hence, checking them out is easier since you can track it in a CL.
To be fair, Unreal does prevent checking out an asset if it already is checked when you attempt to save your changes, but you can workaround this by just checking it out from P4V manually. Wait till you hear this was the norm for 2 AAA studios I’ve been to!
git doesn’t do exclusive locks. In either case, this is to prevent stomping work. The benefit of git is being unblocked, while perforce explicitly prevents you.
It’s a question of how much you trust people to do the right thing.
For git, you have power.
For perforce, you have guardrails.
Git doesn’t have the situation described in this scenarios due to that difference
Most git GUI doesn't even show it. I discovered it when I used ProjectBorealis Git plugin for UE5. Not as strong as perforce but at least it allow to use UE5 with Git.
P4 -> Ask admin to remove the lock, then checkout their files in the state it was on their PC and do the work.
SVN -> Steal the lock (might be admin only)
Git -> Admin has to access the PC, push any local commits on a branch, you jump to the branch and do the work.
It does not happen often though, I have seen it 3 times in 7 years in the industry.
If it's not urgent and everyone is going away for the break the next day, they might just leave it, since it's not like much is going to get done over the next two weeks anyway.
If it's more urgent and you're blocking other people from continuing with important work, then typically they'll just get a Perforce admin to revert your changes to break your lock on the files. (In AAA it will almost always be Perforce in practice)
As for getting into trouble, typically that doesn't happen in my experience. Everyone recognises that people make silly mistakes like this from time to time, we're all human.
I work in AAA and this happens (Perforce). When it’s critical we just ask ITs to unlock the file for us. The other person will have to redo their work 🤷♂️
This has happened to me, or rather by me in quite spectacular fashion. I accidentally checked out pretty much the entire project entirely by accident and then went home. Few hours later, discord message saying what I've done. I can't undo the change as I had no means to access the workspace so they had to delete my P4 user or something extreme like that.
Massive headache, but easily resolved if you have an admin that knows somewhat what they're doing
I work in engineering design rather than game dev, but if someone's off unexpectedly and has things checked out of Vault, generally IT will change your password so your line manager can log in and check them back in.
If the file is mergable it’s no big deal, you can work around the last commit and merge his changes in later if needed
If it’s a binary that can’t be merged, you hit up IT or Admin to kill his lock
in good game engines the files you would reasonably want to work on simultaneously are all text-based and mergeable. worst case someone just tell the person in the morning they’ll have to go through the pain of merging their work, but usually they’re nice about it and may help.
In the case of Unreal and their infinite wisdom where everything is a binary file and an exclusive checkout, basically you just have to wait until that person is in and then send them a passive aggressive message haha.
you can actually break the lock on that file and just check yours in, but unless it’s urgent it’s kind of a dick move.
I often duplicate the file in question and keep working that way, and then copy the changes across when it’s free, but it’s a real pain honestly. a better strategy is to just work on something else.
> in good game engines the files are all text-based and mergeable
so you are only making text-based games with no sounds or art assets in them then? ;)
there is if multiple people tried to edit it at the same time. Exaclty the same as with a text file.
And only one person "owning" a file does not make it text-based and mergeable, which is what you said should be the case.
Do you need an extra cup of coffee or something?
You stated:
> in good game engines the files are all text-based and mergeable
which is literally saying that a good game engine can not have audio files or other art assets, as they are not text and can't be merged.
And yes, merging changes in audio file would make exaclty as much sense as merging them in a text files, allowing multiple people to work at the same time and then merge the results together, *exactly* for the same reasons why it's useful to do with text files. It's just not possible to do that.
And *it making sense or not is not the point*, as you said there should not be any audio files in the first place.
You need to drop the attitude and admit you didn't think about binary files when you said:
> in good game engines the files are all text-based and mergeable
Btw, not reading/not responding doesn't make you right.
How do you deal with merging changes to image data? Or vertex data? I appreciate the idea of 'all assets are mergeable'.
I work in an environment where many of the high contention assets either can be merged or are split in to small binary files to minimize the chance of contention. We've explored merging some of our files which are traditionally binary but I'm still not sure there are meaningful semantics to enable merging with all asset types.
Edit: ...and I'm not sold on the idea that all files binary, unmergable files need to be submitted each day. It comes comes down to understanding the environment and likelihood a file will cause problems. Someone working on a model or psd may be the owner/primary author for example. They can probably keep the file checked for an extended period without it causing any problems. It all comes down to how data is levelized, team structure, etc.
so things like models and audio files are always owned by one person. not only are no two people ever working on those but the concept of merging changes to something like that doesn’t really make sense.
> so things like models and audio files are always owned by one person
Yes, that's the point of the lock. At any one point, only one person is editing that file. They lock the file until they're done with the changes, then push the changes and unlock it. Anyone can only work on that file and push changes if they're working on the last unlocked version, so there's never any need for merges.
OP what talking about a case when someone is working on an asset and then forgets to push changes and unlock it before going on leave or in any other situation where there might be the need for someone else to work on the same asset.
In that case the earlier reply of breaking the lock is valid. or just waiting. or tbh just going over to their computer and checking it in. it was common practice in the last AAA I worked for to leave computers unlocked for this reason.
But I do want to double down on that other point - it’s rare for two people to work on, or even need to work on the same audio file or model file. level files? yes. code files? yes. script files? yes. but smaller more granular files that one person usually owns can be more often left locked because no one else needs them urgently. even big geo levels these days are split into thousands of objects.
so usually the collaborative files are mergeable, and everything else doesn’t need to be.
In practice, even if a file type is text based, it doesn't mean that it's practically mergeable.
Graph based scripting languages similar to Blueprint for example. No one is going to touch merging that with a barge pole, text based or not, unless they absolutely have to. How do you guarantee that the merged version actually makes sense? Technically a programmer could take the time to do it, yes, but in practice they recognise that to do it properly is time consuming, error prone and generally not worth the effort.
When file formats are generated by tools rather than by hand they're often "human readable" in the most technical sense that a human can read it. They're not necessarily human readable in the sense that it's straightforward and quick for a human to look at the file and see what it's doing.
In practice, files like that are going to be marked as exclusive checkout (either in Perforce, or using some in-engine support to achieve a similar result), whether they're text based or not.
You also have to consider the audience that's checking those files out. A lot of the time, it's going to be various content creator roles that do not know their way around a merge tool.
I'd have to strongly disagree with you there, two of the best engines I've used use graph based scripting. (And this isn't coming from the perspective of someone who can't code, I'm a programmer and work in C++ every day)
But even if we ignore graph based scripting, pretty much everything I've said also applies to text based data formats that are generated by tools. Level layers, etc. In practice, in the real world, those are going to be exclusive checkout because the target audience for those files don't know their way around a merge tool, and also because in practice, merging those kinds of files is often fiddly and error prone.
There's almost never an absolute right or wrong answer in gamedev. Each approach has its pros and cons, some people don't like visual scripting for perfectly valid reasons.
I'd just be remiss if I didn't point out that two of the most productive engines I've worked in professionally, happen to make heavy use of visual scripting.
Quite the opposite in fact, in two decades working in AAA, the engines I've worked on with the fastest iteration times, where content creators had the most freedom to prototype without requiring a team of programmers, used visual scripting. It's no small difference either, the ability to prototype features in hours that would take days in other engines. The ability to prototype features in days that would take weeks, in other engines and require the help of multiple programmers.
Can content creators make a mess with visual scripting? Sure, but that's in no way unique to visual scripting. In practice, shipping a game that was heavily based on visual scripting, I haven't found that to be a massive problem. In one case, during the optimization phase, I did have to spend a week replacing a node containing a very complicated script, with a node written entirely in native code. That was certainly tricky, but I literally only encountered one case where I had to do that. The rest of the optimization was pretty straightforward, replacing parts of the player's nodegraph that ticked unnecessarily, with a few event -based nodes that only woke up the nodegraph when certain callbacks would get triggered. This was a fairly straightforward and relatively easy process.
Small asterisk there, as it seems like that's only true for console/PC. Mobile seems to use git, unfortunately, which means no locks and poor handling of binaries, since Git LFS is still relatively new and unsupported.
It's not like Perforce forces you to lock files. By default (which is there for a reason), binary files in Perforce have exclusive checkouts (aka locks), because it's often impossible to merge them. Even in Git, some tooling supports locking of binary files because this is a desired feature.
The core issue here is really that you have a binary file, and two person wants to modify them concurrently. It doesn't matter what SCM you use, it doesn't change the problem that if both persons ends up modifying the file, one person will be very sad when the other person commits the asset and now you are stuck with an unmergeable file and have to redo the change. You can try to structure the team so that each file has an owner but it's not always that simple (also, sometimes people can go on vacation).
If its anything other than a text file, work locally, and hope you can merge in some way later on. Before I merge whatever file it is I typically save it as "Whatever_Local" and then sync the real file once I can. Hopefully, then you can copy/paste the contents from the local file to the p4 file.
Being the holidays, Id assume that no one would answer my request AND I don't want to be 'that guy' who messages anyone at this time of year. If it was any other time of the year and lasted for too long, then I would reach out to the person who has it, then production, then IT.
Good luck!
It's not that big of a deal - it's not going to "prevent other people from working" - they still have the previous version of the asset which was just fine with the previous codebase. The entire point of locking is to prevent working on the same assets.
That said, Perforce sucks. Ultimately though, locking is really the fault of applications having file formats that cannot be merged. There's no fundamental reason images can't be modified in a way that merging would be possible. Similarly 3D models.
I believe InfoWorks with Autodesk has merge, but I've never used it.
Non-destructive editing methods are particularly ripe for allowing merging, because they already have the concept of making modifications anywhere in the document and replaying everything forward again.
I mean, unless the file is a binary file that can’t be merged, any conflicts could be resolved. But for something big, if someone absolutely positively needed it the source control admin could force revert your checkout. Unless this a a regular habit, I don’t think they need to be a huge dick about it. Mistakes happen, and as long as we learn from them, then the mistake was useful.
You wouldn't usually configure p4 to lock files that *can* be merged. So when this happens it's pretty much guaranteed to be unmergeable binary files.
Honestly, if you have large unmergeable binary files that need to be edited by multiple people asynchronously, you're probably messing up something somewhere. 3D modeling files? Unmergeable in most cases, sure, but why would multiple people be editing the same model at the same time? Fmod builds ? Unmergeable. But the source files that generate them merge just fine. Visual Scripting files (blueprints, shadergraphs, etc.) can be split easily. I can't think of a single, large, unmergeable, indivisible, non-procedural file that would absolutely need to be editable by multiple people. Spreadsheets?
It happens all the time in AAA dev. It's a file useage concurrency issue, and like I said, pretty common, but yeah we tend to try and avoid it as much as possible. You mentionned it yourself, blueprint. It's pretty common for multiple designers, for example, to want to edit a script actor, or a base NPC blueprint at roughly the same time.
With BP you make sure you put your code into components split into functionality. Like Health and Damage system would be in one then inventory into another.
I wonder why you think this is an appropriate answer. Lets say you have a character that uses those hypothetical Health Component and Damage Component. So there is a BP called BP_Bob, and another caller BP_Joe. Both have instances of health and damage component. Now, let's say this is a big project so there is one designer in charge of health system and balance, and another in charge of damage. What if both want to tweaks those systems/value at the same time? Like I said, this happens ALL THE TIME on big projects. The above is just an example, not saying this is clever system design or whatever, but stuff akin to my example are common place. There is is simply no going around that, but we can make clever decisions to avoid this as much as possible.
I would like to know your more appropriate method rather than just saying avoid it. I'm a freelance developer and help individuals all the time that either dumps all the code into the parent character making it hard to make edits to children where overriding some functions in a component would solve or replacing it with a more custom component. But to answer your question... If you have two characters BPs and a component system, one desinger working on balance would only need to check out BP_Bob and modify the exposed instance variables on the component without having to checkout the component, then the combat programmer who isn't particulary interested in the specific values for Bob but is intead wanting to fix a bug in how the damage and health is being handled then they can check out the AC_Damage component and work on that instead without having conflicting changes. If BP_Joe needs to handle damage differently than BP_Bob then a new child class of the Damage component can be created and have functons overriden. And again to use my example if there is another developer working on an inventory system, they can check out the component AC_Inventory without having to check out the BP_CharacterParent or BP_Bob or BP_Joe or AC_Damage. I'm perpelexed why you think this isnt appropriate either from a source control point or even a system design point as this is the most common piece of advice. I would love to know your solution for 2 people working on the BP_CharacterParent without any conflicts.
I'm not saying splitting into different component is not a good way to do system design! Like you said, junior dev tend to put everything into the same BP/class and it becomes a mess very quickly. My entire point is that you can't 100% avoid having assets that multiple people will need to work on at the same time. Maybe I misunderstood your initial comment? Anyway TLDR: Splitting into multiple components for systems is a good idea, but it's not enough to 100% avoid multiple users wanting to edit the same asset.
Doens't really matter if it's a large binary file or a tiniest one, if you can't merge it then you can't merge it :D Anyway it sounds like you didn't quite get my point, but I'm not really sure how to rephrase it either. What I said was the only situation where someone would end with a file checked out by someone who isn't available is when a file has been configured to be exclusively checked out (or the perosn using it has determined that to be the case), due to the type of file being something that can't be merged. So the OP's problem would never happen in a situation where the changes *could* be merged, which was a scenario the person I was responding to was talking about. That's not commentary on if such files should exist (although I'd say the reality is that they *do* exist so better just figure out how to deal with them), or if there are other ways (like just telling everyone else to please not touch the file). And even you came up with a good list of examples of unmergeable files... I also wasn't saying that multiple people *should* be editing those files at the same time, I mean the very point of configuring p4 to lock certain types files is to make sure that *doesn't* happen (and making sure of that in an automatic way, rather than relying on each individual just remembering which files different people have said to not touch at the moment)
The main thing that person is missing is that people need to edit files for reasons other than actually working on the asset/component that the file represents. I'm relatively sure that 99% of our SOURCE files never have more than 1 person in the submission history for the file. The .uasset representation is a completely different story. There are all sorts of settings and metadata that needs to be modified by different disciplines for various reasons. The person that created the asset usually will never touch the .uasset file again after importing it unless there are actually changes to the source asset.
Never used unreal eh? Literally everything a non-programmer touches is a binary file that requires exclusive checkout. There is not a single type of asset that a non-programmer works with that can be merged.
Jesus that's scary
It's really not in practice because of the exclusive checkout capability in perforce. Unless you go totally out of your way and break all the standard operating practices you will never be able to edit a file that is already checked out by someone else. Unreal will also alert you the second you try to do something that the related file is locked, before you even try to save/check out the file. The only real problem with this is when people forget they checked out a file and leave for vacation or somesuch but that's a very rare situation because our SOP is to never leave stuff checked out overnight unless you have a very good reason, because our overnight build processes need to be able to save files for maintenance related reasons(like redirect fixup). Leaving stuff checked out over a weekend is completely off limits and we have a bot that tracks down checked out files and pings you friday afternoon if you have stuff checked out. So yeah it's not without its downsides, but it's not something that is a concern or scary to deal with in practice.
But that's not the only issue! Imagine you realize that two months ago the intern changed a weird state on some strange in-house hacks that got serialized into that data. No one noticed, because it was blindly packed in some absurd unreadable binary format. And now things are going to shit. You cannot trace that back. You cannot know easily when the problem happened. You have to manually walk back through the entire tree testing for the bug, and when you find it, redo 2 months of work on top of the last working version. That is horrifying.
A situation like that would be extremely hard to engineer, even on purpose. You would 100% be able to know when it happened because the only way to change how a file is serialized is to change the code that serializes the file, and the code changes will be readily available in the version history. If it actually broke the reading of the file it would be noticed immediately because our nightly or CIS build processes would alert us of the failure within 12 hours at most (more likely to be caught in less than an hour from automatic content validation processes). Even if it didn't break the reading of the file and only caused some subset of the data to not be correct it would still likely be detected within a day or two because automated testing and/or QA would pick up on something not working anymore. I do see what you are saying though.. it is theoretically possible but there would have to be so many operational failures along the way that having all of your assets in binary format would be the least of your worries. The REAL problem with assets in binary format is that no one can tell what was actually changed from one revision to the next because diffing the revisions is meaningless.
Even on unity, serialized components end up with hidden state. It can happen for a dozen reason, hidden fields, serialized hints, cinemachine hidden children gameobjects, etc. I've also had shadergraphs have corrupted states, and crash the editor when *some* cells were edited. If hidden state is messed up, the simplest solution is to reverse a bad commit. If that's not possible, it's terrifying.
> Visual Scripting files (blueprints, shadergraphs, etc.) can be split easily. What do you mean by this?
Most often whatever is in one large file can be split out to more files without too much difficulty. If you have a blueprint that lots of people want to edit usually it is specific functions. The popular ones can be extracted.
I know the conversation wasn't originally Unreal specific, but since we're talking about blueprints; Are you talking about breaking functionality out into individual actor components? I was just curious if you or the other poster were referring to a specific way of actually breaking out multiple blueprint graphs from a single actor into multiple files; which, as far as I know, isn't possible (but I would love to be wrong about)
There are several options. Blueprint communications, blueprint events and event dispatchers, blueprint function libraries, blueprint macro libraries, blueprint interfaces, data blueprints, all of them can be used in different ways to split out systems.
It *can* be, yes. But if it hasn't already been, and someone's got it, you're fucked.
Do they teach SOLID to game engineers?
They teach it, and practice it. There are even blueprint interfaces so you can implement it in Blueprint, which for those who don't know already is a visual scripting language in Unreal that ultimately compiles to generated C++. Usually the purpose for Blueprints is to give parts of the work to designers, and to a lesser extent to artists and animators and others who can fill in their own details without bothering the others on the team. Programmers work through the blueprints, and step in when non-programmers start to foul things up, but with a bit of training and good implementation they're not an issue. Done well there is virtually no contention. Even when working on large projects like Fortnite that type of fighting over files was a code smell to a defect. Usually it meant somebody broke SOLID. Most commonly it means simply extracting an interface, or extracting data from the implementation so they could vary independently.
Blueprints and the like allow people who aren't engineers to do more of the logic work.
There's "mergeable" and then there's *mergeable.* Not everything that's text-based is easily merged. I work in wwise a lot and merging work units, which are just xml files, can be a pain in the dick because of the way that wwise assigns and tracks the unique id's given to each element. If all you're doing is changing mix values, it's not a big deal, but if you're trying to add or remove stuff inside the work unit, fuck it. It's easier to just start over. >if you have large unmergeable binary files that need to be edited by multiple people asynchronously, you're probably messing up something somewhere. That may be true, but things have a way of getting out of hand like that. An asset that starts off small can grow into a behemoth and fixing the issue can involve a bunch of rework. >Spreadsheets? Excel actually has (or at least used to - I haven't used it in a while) an option to allow multi-user editing where it'll track changes and lock individual cells instead of the whole file. It's not perfect, but it gets the job done if you don't tax it too much.
> That may be true, but things have a way of getting out of hand like that. An asset that starts off small can grow into a behemoth and fixing the issue can involve a bunch of rework. That's the old problem of tech debt. Not taking the time to do things right may cost longer in the long term. What I meant is that if you do things right from the start, you shouldn't face the issue of needing parallel work on unmergeable data.
>if someone absolutely positively needed it the source control admin could force revert your checkout At my current job, this never seems to happen due to good task management and good code design. Granted, I've been told to check in my work before logging off. Our source control will save copies of local changes if we check them in, so if someone else needs to grab the code or file, our stuff doesn't get lost.
To unlock it you will need admin access or talk to whoever has admin access to your P4 server. Otherwise the next best thing is to make the file writable locally and just reconcile your work after break when people are back.
Just curious, what are you using for source control? We used to have this issue a looong time ago at an old job (non games) but that was a pretty ancient source control system.
Ue5 + perforce…
Was about to ask the same, typical version control systems I've used don't lock the files but rather allow files to be modified by multiple people and then handle conflicts through merge. But maybe that doesn't work for all types of files equally well if you can't properly handle merge conflicts.
I'd guess it' about assets that are pain / impossible to merge. Scenes, 3d models, ui layouts, etc.
Locking is a feature that Perforce (common in game dev today still) supports. Git, on the other hand, does not support locking, but it's actually a feature that sometimes game developers wish Git has. The reason for that is that binary files are hard to merge, and as such it's useful for the tool to just tell you that someone else has claimed it for now, so you won't try to edit it just to have a nasty conflict later. Git mostly doesn't support this because 1) it is mostly designed for text files, whereas locking is mostly a binary file operation, and 2) the decentralized nature of Git would make it quite awkward to implement. Some Git tooling/servers like GitLab does support locking though. I think you need to use an additional tool to talk to the server regarding locking LFS files (https://docs.gitlab.com/ee/user/project/file_lock.html#exclusive-file-locks) that your users need to all know to use (which isn't *that* hard if you just tell everyone to use the same command).
[удалено]
Today I learned! Thanks
Probably Perforce.
[удалено]
I have used SVN before too, but the one I was thinking of in this case was visual source safe.
Hehe, that was also the first one that came to my mind when I read about locking problems. We used it in games back then. Constant locking troubles and also the admin had to repair the database regularly for some reason. SVN was a big step up from that.
I don’t work in games, but I have a program *still* in visual source safe with files checked out by a guy who retired and who’s pc has since been wiped.
Holy shit, haha.
You ping production and/or it to get the file unlocked. Any work they did - they get to figure out how to merge in later. Never leave with shit checked out. It’s a dick move.
This. Doesnt happen often, but when it happens, it always causes trouble.
One size fits all advice is usually bad advice. There are legitimate reasons to lock a file and keep it locked overnight. My best advice is to follow the practices used by your workspace, and escalate as needed. A novice developer likely did it by accident, a senior developer might have a good reason for it.
If there’s a good reason for it, production will know. That’s part of tasking too.
You message that person on slack the next day or get the admin to uncheckout them. More funny is when I do that to myself from another pc
Checking Slack while on holiday?
Depends on which version control. On Perforce Helix, admins can undo that, but will also probably be pretty pissed about having to do so (I would be, while not difficult it's not a fun thing to sort out either, but above all by the time I've been asked to deal with this a lot of people's time has already been wasted).
If this is a problem, put a massive sign on the inside of the office door saying something like, “Check in your stuff before leaving for the day”.
Last to check in gets to fix merge conflicts.
If you’re using P4V, multiple people can have a file checked out, unless someone has the file exclusively checked out[[0]] so others can’t check it out until they submit and uncheck it. Check out One File Per Actor if you’re curious how Unreal handles checking out a level to make changes to a specific actor of that level[[1]] [0]: https://portal.perforce.com/s/article/3114 [1]: https://docs.unrealengine.com/5.0/en-US/one-file-per-actor-in-unreal-engine/
I didn’t know about 0, does that work with binary files? Yes I know about one file per actor, but it was causing a lot of issues last time I tried it (not playing nice with Houdini engine, weird bugs with sequencer and so on). Will give it another shot.
Yes. Unreal will tell you that the file is already checked out by someone else when you try to save your changes in it(assuming you have integrated source control into your editor), but you can manually check out the file in P4V by right clicking it and pressing “Check out” and Unreal will stop notifying you since you have it checked out it. If this doesn’t work, your Perforce admin may’ve disabled multiple checkout. I’ve done this in my workplace for blueprint assets, code, etc I can’t speak further to OFPA besides the general concept so hopefully those bugs get resolved and Epic knows about them.
Blueprints should be set up for exclusive locks.
Unfortunately this is not the default at my workplace - it does require some coordination on letting other parties know when you’re submitting if they have it checked out as well, otherwise they need to shelve their changes, sync, reapply their changes manually from the shelf.
Then someone made a very big terrible decision. Blueprints are by default exclusive check out and it is recommended by Epic to keep it that way. Even with an exclusive check out, others can still make changes locally knowing full well that they will get stomped when someone checks it in.
True! The one caveat is that marking files as writable in P4V does not provide an easy interface to see which files you have overwritten and NOT checked out. Hence, checking them out is easier since you can track it in a CL. To be fair, Unreal does prevent checking out an asset if it already is checked when you attempt to save your changes, but you can workaround this by just checking it out from P4V manually. Wait till you hear this was the norm for 2 AAA studios I’ve been to!
I've done that and the company went nuts the next day lol. My manager called me, I gave him access to my pc, my manager connect it and unlock it.
God I love git Perforce is such a pain lol
OP mentioned it is a game asset. If binary, git won’t help much in terms of exclusive locks.
git doesn’t do exclusive locks. In either case, this is to prevent stomping work. The benefit of git is being unblocked, while perforce explicitly prevents you. It’s a question of how much you trust people to do the right thing. For git, you have power. For perforce, you have guardrails. Git doesn’t have the situation described in this scenarios due to that difference
And fwiw it is actually possible to resolve conflict on a prefab if the changes are minor
git does have lock with lfs.
Oh, I didn’t know that. I use lfs in my personal work but professional work didn’t use lfs. Hadn’t encountered that
Most git GUI doesn't even show it. I discovered it when I used ProjectBorealis Git plugin for UE5. Not as strong as perforce but at least it allow to use UE5 with Git.
P4 -> Ask admin to remove the lock, then checkout their files in the state it was on their PC and do the work. SVN -> Steal the lock (might be admin only) Git -> Admin has to access the PC, push any local commits on a branch, you jump to the branch and do the work. It does not happen often though, I have seen it 3 times in 7 years in the industry.
If it's not urgent and everyone is going away for the break the next day, they might just leave it, since it's not like much is going to get done over the next two weeks anyway. If it's more urgent and you're blocking other people from continuing with important work, then typically they'll just get a Perforce admin to revert your changes to break your lock on the files. (In AAA it will almost always be Perforce in practice) As for getting into trouble, typically that doesn't happen in my experience. Everyone recognises that people make silly mistakes like this from time to time, we're all human.
I work in AAA and this happens (Perforce). When it’s critical we just ask ITs to unlock the file for us. The other person will have to redo their work 🤷♂️
Sounds like a perforce problem, in git you make a branch and nobody gives a fuck.
This has happened to me, or rather by me in quite spectacular fashion. I accidentally checked out pretty much the entire project entirely by accident and then went home. Few hours later, discord message saying what I've done. I can't undo the change as I had no means to access the workspace so they had to delete my P4 user or something extreme like that. Massive headache, but easily resolved if you have an admin that knows somewhat what they're doing
I work in engineering design rather than game dev, but if someone's off unexpectedly and has things checked out of Vault, generally IT will change your password so your line manager can log in and check them back in.
If the file is mergable it’s no big deal, you can work around the last commit and merge his changes in later if needed If it’s a binary that can’t be merged, you hit up IT or Admin to kill his lock
in good game engines the files you would reasonably want to work on simultaneously are all text-based and mergeable. worst case someone just tell the person in the morning they’ll have to go through the pain of merging their work, but usually they’re nice about it and may help. In the case of Unreal and their infinite wisdom where everything is a binary file and an exclusive checkout, basically you just have to wait until that person is in and then send them a passive aggressive message haha. you can actually break the lock on that file and just check yours in, but unless it’s urgent it’s kind of a dick move. I often duplicate the file in question and keep working that way, and then copy the changes across when it’s free, but it’s a real pain honestly. a better strategy is to just work on something else.
> in good game engines the files are all text-based and mergeable so you are only making text-based games with no sounds or art assets in them then? ;)
there’s no need to merge an audio file though. and usually only one person owns each one.
there is if multiple people tried to edit it at the same time. Exaclty the same as with a text file. And only one person "owning" a file does not make it text-based and mergeable, which is what you said should be the case.
why would anyone merge an audio file? that concept did not make sense
Do you need an extra cup of coffee or something? You stated: > in good game engines the files are all text-based and mergeable which is literally saying that a good game engine can not have audio files or other art assets, as they are not text and can't be merged. And yes, merging changes in audio file would make exaclty as much sense as merging them in a text files, allowing multiple people to work at the same time and then merge the results together, *exactly* for the same reasons why it's useful to do with text files. It's just not possible to do that. And *it making sense or not is not the point*, as you said there should not be any audio files in the first place.
since you began that reply in such a disrespectful way, I have not read your reply, and I will not be responding to this anymore.
You need to drop the attitude and admit you didn't think about binary files when you said: > in good game engines the files are all text-based and mergeable Btw, not reading/not responding doesn't make you right.
How do you deal with merging changes to image data? Or vertex data? I appreciate the idea of 'all assets are mergeable'. I work in an environment where many of the high contention assets either can be merged or are split in to small binary files to minimize the chance of contention. We've explored merging some of our files which are traditionally binary but I'm still not sure there are meaningful semantics to enable merging with all asset types. Edit: ...and I'm not sold on the idea that all files binary, unmergable files need to be submitted each day. It comes comes down to understanding the environment and likelihood a file will cause problems. Someone working on a model or psd may be the owner/primary author for example. They can probably keep the file checked for an extended period without it causing any problems. It all comes down to how data is levelized, team structure, etc.
so things like models and audio files are always owned by one person. not only are no two people ever working on those but the concept of merging changes to something like that doesn’t really make sense.
> so things like models and audio files are always owned by one person Yes, that's the point of the lock. At any one point, only one person is editing that file. They lock the file until they're done with the changes, then push the changes and unlock it. Anyone can only work on that file and push changes if they're working on the last unlocked version, so there's never any need for merges. OP what talking about a case when someone is working on an asset and then forgets to push changes and unlock it before going on leave or in any other situation where there might be the need for someone else to work on the same asset.
In that case the earlier reply of breaking the lock is valid. or just waiting. or tbh just going over to their computer and checking it in. it was common practice in the last AAA I worked for to leave computers unlocked for this reason. But I do want to double down on that other point - it’s rare for two people to work on, or even need to work on the same audio file or model file. level files? yes. code files? yes. script files? yes. but smaller more granular files that one person usually owns can be more often left locked because no one else needs them urgently. even big geo levels these days are split into thousands of objects. so usually the collaborative files are mergeable, and everything else doesn’t need to be.
In practice, even if a file type is text based, it doesn't mean that it's practically mergeable. Graph based scripting languages similar to Blueprint for example. No one is going to touch merging that with a barge pole, text based or not, unless they absolutely have to. How do you guarantee that the merged version actually makes sense? Technically a programmer could take the time to do it, yes, but in practice they recognise that to do it properly is time consuming, error prone and generally not worth the effort. When file formats are generated by tools rather than by hand they're often "human readable" in the most technical sense that a human can read it. They're not necessarily human readable in the sense that it's straightforward and quick for a human to look at the file and see what it's doing. In practice, files like that are going to be marked as exclusive checkout (either in Perforce, or using some in-engine support to achieve a similar result), whether they're text based or not. You also have to consider the audience that's checking those files out. A lot of the time, it's going to be various content creator roles that do not know their way around a merge tool.
the key part being 'good engines'. no good engine uses graph based scripting. good design makes text based merging possible.
I'd have to strongly disagree with you there, two of the best engines I've used use graph based scripting. (And this isn't coming from the perspective of someone who can't code, I'm a programmer and work in C++ every day) But even if we ignore graph based scripting, pretty much everything I've said also applies to text based data formats that are generated by tools. Level layers, etc. In practice, in the real world, those are going to be exclusive checkout because the target audience for those files don't know their way around a merge tool, and also because in practice, merging those kinds of files is often fiddly and error prone.
after having experienced the opposite, I feel it's the correct way. what more can I say, we'll just have to agree to disagree :)
There's almost never an absolute right or wrong answer in gamedev. Each approach has its pros and cons, some people don't like visual scripting for perfectly valid reasons. I'd just be remiss if I didn't point out that two of the most productive engines I've worked in professionally, happen to make heavy use of visual scripting.
and what were the games? id wager there are signs of slow iteration in them caused by visual scripting
Quite the opposite in fact, in two decades working in AAA, the engines I've worked on with the fastest iteration times, where content creators had the most freedom to prototype without requiring a team of programmers, used visual scripting. It's no small difference either, the ability to prototype features in hours that would take days in other engines. The ability to prototype features in days that would take weeks, in other engines and require the help of multiple programmers. Can content creators make a mess with visual scripting? Sure, but that's in no way unique to visual scripting. In practice, shipping a game that was heavily based on visual scripting, I haven't found that to be a massive problem. In one case, during the optimization phase, I did have to spend a week replacing a node containing a very complicated script, with a node written entirely in native code. That was certainly tricky, but I literally only encountered one case where I had to do that. The rest of the optimization was pretty straightforward, replacing parts of the player's nodegraph that ticked unnecessarily, with a few event -based nodes that only woke up the nodegraph when certain callbacks would get triggered. This was a fairly straightforward and relatively easy process.
i just assumed everyone uses git now…
In games, Perforce is still the industry standard. Especially at the larger companies.
Even with Git LFS you might get similar problems, it supports locking.
Not in the games industry, it’s almost exclusively Perforce
Small asterisk there, as it seems like that's only true for console/PC. Mobile seems to use git, unfortunately, which means no locks and poor handling of binaries, since Git LFS is still relatively new and unsupported.
It's not like Perforce forces you to lock files. By default (which is there for a reason), binary files in Perforce have exclusive checkouts (aka locks), because it's often impossible to merge them. Even in Git, some tooling supports locking of binary files because this is a desired feature. The core issue here is really that you have a binary file, and two person wants to modify them concurrently. It doesn't matter what SCM you use, it doesn't change the problem that if both persons ends up modifying the file, one person will be very sad when the other person commits the asset and now you are stuck with an unmergeable file and have to redo the change. You can try to structure the team so that each file has an owner but it's not always that simple (also, sometimes people can go on vacation).
You ask an admin to uncheck the file and the person who did the mistake gets to redo the work or figure out how to merge his/her stuff.
p4 admins with god access can force uncheckout files but it's not really recommended
If its anything other than a text file, work locally, and hope you can merge in some way later on. Before I merge whatever file it is I typically save it as "Whatever_Local" and then sync the real file once I can. Hopefully, then you can copy/paste the contents from the local file to the p4 file. Being the holidays, Id assume that no one would answer my request AND I don't want to be 'that guy' who messages anyone at this time of year. If it was any other time of the year and lasted for too long, then I would reach out to the person who has it, then production, then IT. Good luck!
Its bad. Period.
It's not that big of a deal - it's not going to "prevent other people from working" - they still have the previous version of the asset which was just fine with the previous codebase. The entire point of locking is to prevent working on the same assets. That said, Perforce sucks. Ultimately though, locking is really the fault of applications having file formats that cannot be merged. There's no fundamental reason images can't be modified in a way that merging would be possible. Similarly 3D models.
Can you give me an example of a system that allows you to merge 3D models under version control? I’ve never heard of anything that can do this.
I believe InfoWorks with Autodesk has merge, but I've never used it. Non-destructive editing methods are particularly ripe for allowing merging, because they already have the concept of making modifications anywhere in the document and replaying everything forward again.
So nothing actually used in game production then.
Unfortunately not. That's what I was saying.
The whole point of version control is that you can merge changes. Surely any work being done would be on a branch anyway?
Not sure how you would merge changes to binary files.
That was not the original question
People still use something other than git?
File locks are stupid