Implement live multi-user editing of projects over the network

[Shadowblitz16]

Describe the project you are working on: Non right now but I would like to work on a project with my older brother and show him godot

Describe the problem or limitation you are having in your project: Me and my brother live in two different countries and I would like to start a rouge lite game with him and introduce him to godot.

the problem is I would like to have live interaction developing this game with him and while git is good it doesn't really acheave the feeling of building something together

Describe the feature / enhancement and how it helps to overcome the problem or limitation: I suggest that the godot editor gets live networked editing similar to what superpowers did and SMBX tried to do.

this would allow people to work together to build games in a really cool way.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: basically when one user would edit a file or a property the other users would see the changes on the other end.

the way I see this would be something like git being used to save daily work while this would be used to save immediate work.

I would guess that when you connect to someone it does the following..

• lets you choose project if one doesn't have source control it makes you create one
• lets you choose a source control branch. each branch might have different people working on it.
• when something changes for example a property or file it update it in the editor for each person working on that branch (only the changes).
• finally when people are done for the day commits are made to the currently work on branch. and if everything is implemented right it won't let you commit if your out of sync with others.

If this enhancement will not be used often, can it be worked around with a few lines of script?: idk if people would use this but it sounds like it could be the next big source control also it couldn't be worked around.

Is there a reason why this should be core and not an add-on in the asset library?: if implemented right it would speed up development and while it could be implimented as a asset library its very unlikely someone would do something this big

[RabbitB]

I genuinely like this idea as a concept, and maybe this is a pessimistic view, but I can only see the amount of work required to make this happen in a fluid and project-safe way, as insurmountable.

[Shadowblitz16]

I think the set and get functions would actually make it easier but I still agree it would be alot of work.

[LikeLakers2]

It's a great concept, and I've had this idea in my head for a while, but I have to agree with RabbitB here -- it sounds like a little too much work.

However, perhaps you could use something like Dropbox shared folders or a network share to make something similar. You would have to avoid stepping on each other's edits, however, such as ensuring you're both not editing the same scene or the same script file.

Aside from that, perhaps some checks could be added to make something like this a little easier. Perhaps the editor can check, when you save a file, if the file has changed since you opened it/last saved it. And/Or perhaps the editor can create lock files on any files that it opens, so as to indicate to other editors that File_X.gd is open in another process (whether that process lives on the same machine or a different machine).

[RabbitB]

If we break it down into the core functionality that needs to be developed, we have:

1. Editor needs network connectivity, and every single change made needs to be broadcast reliably. This is a much larger task than it sounds, as the editor holds a lot of state that we need to track and sync constantly.
2. There needs to be some sort of conflict resolution. In an ideal world, a change to a file would only be made when all clients are fully synced, but the reality is that's not likely to always be the case, and we need conflict resolution on how to resolve this without losing any progress made by anyone. Unlike with git, this is all being updated real-time, so we would need to develop UI to alert developers and provide them the ability to resolve conflicts. I have a suspicion that this could greatly disrupt workflow.
3. The project needs to resync all files every time you launch it. This part isn't that bad, but it still needs to be done.

There's certainly more, but that's a 10,000 ft view of the problem. I don't want to call it impossible because it certainly isn't, but this would be a massive undertaking.

[Jummit]

I think this would make a great plugin. There is this, but I don't know how functional it is.

[mhilbrunner]

Yeah, this sounds more like a whole seperate project, scope-wise, as amazing as it would be. Not really feasible, IMO.

[Shadowblitz16]

if this was done it would be nice to also see people's mouse cursers

[Calinou]

There are a few attempts to implement this feature like this one, but I think this is too difficult to implement in a safe manner. Not to mention that it may also be quite gimmicky given the effort required to implement it.

For comparison, Cube 2: Sauerbraten features a cooperative map editor, yet most serious maps are created in singleplayer mode. This doesn't mean cooperative editing is never useful for serious mapping, but it's not used as often as you'd expect.

[aaronfranke]

I love the idea of live editing, Google Docs is a blessing for school work and I could see it being really useful for Godot too. However, this could be an add-on in the asset library, and considering the amount of effort it would take to maintain this if it was in core, it probably should be.

[Shadowblitz16]

Note vs code and vs studio now have live share which is the same thing

[fire]

I worked out an approach for doing multi-person editing.

Use the Mixer from Ubisoft as the server. The clients are multiple blender and Godot Engine clients.

https://gitlab.com/ubisoft-animation-studio/mixer/-/issues/8

We were able to get Mixer's client(protocol, not blender) server portion licensed as MIT compatible.

Edited:

I'll repost my sample for Godot-python here because I've been bogged down. So that other people can contribute.

Here's the project example.

https://github.com/godot-extended-libraries/godot-mixer

Edited:

Last working edition before I broke it.

Edited:

I ran out of effort on the mixer godot integration, so this post is a hope someone else can take the lead on it.

[fire]

https://github.com/ubisoft/mixer/releases/tag/v1.0.0

Ubisoft Mixer is live editing the same scene in Unity and Blender.

The 1.0 release adds skeletal posing and is a major release.

Here are the tutorials https://www.youtube.com/channel/UCVfQBSBBvo8GMndYy2TzQHw.

Also Unity compatibility https://github.com/ubisoft/vrtist.

This 1.0 release removes the limit of skeletons disappearing for use in Godot Engine proposal.

[macryc]

Interesting discussion. What about multiuser collaboration at runtime? Like multiplayer but not quite. Say, you have a mindmap type of app that uses the graphedit node with nodes and connectors. Is there a way to allow more than 1 person move/connect the nodes at the same time and save changes to the same file?

[Calinou]

Is there a way to allow more than 1 person move/connect the nodes at the same time and save changes to the same file?

That's not implemented yet, although it may be feasible with a plugin. This is pretty much what this proposal is about :slightly_smiling_face:

However, there are a lot of potential issues with desyncs you need to cater for.

[anunknowperson]

I described my vision of the solution here: https://github.com/godotengine/godot-proposals/issues/3694

[ghost]

laalfalfaflel

[TrueSgtMonkey]

Has this been implemented in Godot 4 at all?

Edit: Understandable that it hasn't been implemented. I simply commented this here because Godot 4 had so many huge changes.

[Calinou]

Has this been implemented in Godot 4 at all?

No.

[qtqgyt]

So is this ever planned?

[starry-abyss]

I wouldn't wait for this any time soon, because even working alone still has some quirks like editor sometimes nulls all export variables in a scene...