Multiplayer map editor?

[mankubus]

Would be cool if you could build maps with other people at the same time in real time. This could make mapping more popular and thus raise the amount of wads from people doing collabs.

[1Destro3456]

hmm, I don't really know, but seems interesting. Going to follow this out of curiosity 

[Arrowhead]

Sounds like a little bit of a pipe dream, but yeah, I do agree - it would be very very cool. :)

 

I'm having a hard time thinking how such a thing could be implemented...

[Shepardus]

I've seen it done in platformers such as LittleBigPlanet, Super Mario Maker, and Mega Man Maker. Would be cool to see for Doom, though it does seem like a lot of work.

[Doomkid]

I have had this dream of two remote instances of Doom Builder connecting P2P and both being able to alter the map simultaneously in real-time, with the changes the other author makes also happening right before your eyes, while you work on some different area of the map.

 

You'd have to avoid working on the same room at any given time, and it would probably be hell to make - but I've wanted it for a long time..

[TheMagicMushroomMan]

3 minutes ago, Doomkid said:

I have had this dream of two remote instances of Doom Builder connecting P2P and both being able to alter the map simultaneously in real-time, with the changes the other author makes also happening right before your eyes, while you work on some different area of the map.

 

You'd have to avoid working on the same room at any given time, and it would probably be hell to make - but I've wanted it for a long time..

 

Doomkid: spends nine hours building and detailing a map and is currently setting up a combat encounter involving nine mancubi and an archvile on the northernmost part of the map

 

Me: adds terry trap to a small room while he isn't paying attention

[SuperPIter_DoomWorldthe2nd]

6 minutes ago, TheMagicMushroomMan said:

 

Doomkid: spends nine hours building and detailing a map and is currently setting up a combat encounter involving nine mancubi and an archvile on the northernmost part of the map

 

Me: adds terry trap to a small room while he isn't paying attention

Devilish. Anyway though, a bit on-topic:

 

This reminded me of Super Mario Maker 2's whole thing of 2 players being able to build levels together.

[Dexiaz]

A pretty interesting idea. But TeamViewer (or something like this) is not enough for such idea. I mean, while Mapper#1 doing something, Mapper#2 will just seat and wait. It would be kinda interesting to see the double work.

[Doomkid]

43 minutes ago, Dexiaz said:

A pretty interesting idea. But TeamViewer (or something like this) is not enough for such idea. I mean, while Mapper#1 doing something, Mapper#2 will just seat and wait. It would be kinda interesting to see the double work.

Some kind of "split screen doom builder" could get around this, lol. Somehow each screen would have to receive different keyboard and mouse inputs as well, though..

[SilverMiner]

It would speed things up a lot and maybe help burnt out mappers

[ketmar]

actually, it is not that hard to implement in an existing editor as a client/server model. some hooks here and there, and some code to work on "explicit sets" instead of the "current selection". now we only need somebody to actually write it. ;-)

[boris]

1 hour ago, ketmar said:

actually, it is not that hard to implement in an existing editor as a client/server model.

 

Famous last words.

[Worst]

I think a good approach to this, would be with a client/server model that uses commits/patches.
 

How it could work:

• Mappers using client editors would connect to an authoritative server, which would hold the main copy of the map.
• The server's job would be to keep clients up to date with the "master copy" of the map, and to receive commits from the clients, that get applied to the "master copy" of the map.
• Client editors would keep in memory both the latest "master copy" received from the server, as well as their local working copy of the map.
• When a mapper using the client editor is done with a portion of the map, the client editor would compare the local changes to the latest "master copy" received from the server, and form a commit/patch of the changes done to the map, and send these over to the server. The server would then patch the master copy of the map, and broadcast the changes back to all the clients so that they can update their "master copy".

In addition to the previous points:

Spoiler

• Mappers using the client editors could also have the option of reverting back to the "master copy", and discarding their current changes.
• Perhaps mappers could choose to highlight specific sectors/linedefs/things/etc. to commit to the server, rather than all of their current changes.
• Client editors could also be automated to send preview commits to the server that are not patched into the "master copy", but are instead just broadcasted to the other clients as mere previews of what the mapper is working on at the moment. The client editor could differentiate the previews by using a different color or shade. (The previews would be just layered under the local copy of the map, and would not interact with the local copy.)
• Since the commits would usually not target the entire map, it could be possible to revert an older commit affecting only a particular room, without reverting the entire map back to an older version.
• The commit/patch approach also would not require a great connection to the server, as information would not need to be relayed constantly between the server and client, and even with no connection, the client could keep working on their local copy.
• However if multiple mappers touch the same areas, commits could end up conflicting with one another, but that could be avoided with proper communication between the mappers.

What I think is great about the commit/patch approach is that work on it could be started without worrying about the whole client/server model, by implementing it as a feature in the editor, that for example would let you save a patch file, that only contains the specific changes made to the map. Such a patch file feature alone could already bear fruit in team/community projects where multiple mappers work on the same map. It would allow merging changes from multiple mappers without having to do it manually with copy & paste, or without having to take turns on modifying a map.
 

I suppose this may all still be somewhat of a pipe dream, but it's an interesting topic nonetheless, so I couldn't help thinking how it could work.

[ketmar]

@Worst that sounds interesting from a technical standpoint, but is not much fun to use. i mean, collaborative editing is fun when people don't have to perform any additional steps to "merge" their edits. your workflow is more suited to "serious work", but i see collab editors as mostly "doing it for fun". so it should be as seamless and transparent as possible, to not annoy people, and not take away that fun. so all changes should be instant, and propagated to all participants, there should be onyl one map version shared by all parties.

 

so you basically need two major changes in "master" editor: the ability to work with "explicit sets" (so each client can have independend selection), and "marked undos" (so undo will undo only the things from the given client). of course, the conflicts are inevitable, but they can be solved as any other conflicts in multiplayer games: the server is the authority. with map changes propagated in realtime there's no need to create any complicated conflict resolution schemes, it just all about people cooperating and doesn't interfere with each other work (at least not much ;-).

[Kappes Buur]

Maybe this could evolve from a two monitor system, where one edits on one monitor and sees the result on the second monitor.

[basje]

You can already do this online with multiple players in the FPS game Cube2 Sauerbraten.

Would be cool in DOOM if possible.