design - What is a good structure for files edited in parallel by multiple people -

i'm making amounts level editor game, , i'm not sure best way store game content file. clear, design question, not technical one.

the game content can broken down hierarchically multiple levels, each multiple scenes, have multiple events, etc., each of relatively independent. there data, such items , characters, referenced globally across game.

ideally editor support multiple users, each edit non-conflicting parts of game content, , merge changes without issue (think source code in version control system). ideally, game content should easy load game once finished (i.e. should able load "level" , have necessary pieces load without navigating filesystem).

i've come few ideas how this, none of wholly satisfactory:

• split game content across many files, parallel edits easy make , merge. use folder structure , project file keep track of files, how visual studio handles code projects. cons harder manage in game, , it's harder content reference other content in file (e.g. character has item).

• use single binary file, create merge functionality, similar ms word (or how git merges text files). cons means have manually resolve merge conflicts , merge functionality non-trivial implement.

• use few files represent large pieces of game, , hope people using editor smart enough not edit same 1 @ same time. cons self-evident, deal easier implement.

obviously have underspecified problem, i've given enough information people know i'm talking about. have helpful insights or has had similar problem?

if helps, these .json files, versioned using git.

i think quite bit of depends on how complex editor , how want keep users unaware of underlying design.

here general thoughts experience related projects:

• even if split content on many files there chance 2 users edit same one, conflicts , merging have part of design in cases.
• if use binary files, you'd have develop custom solution showing conflicts , allowing users merge them. i'd think using text files in standard format xml or json. allow reuse existing merge tools either separately or embedded in editor.
• smaller files easier merge visually if can divide configuration in smaller sub-parts , have separate files each part it'd make life easier. can give editor required intelligence load each file , making links between sections related characters items.

and here's possible design i've seen myself in project worked on. perhaps it's if trying build smaller can take ideas:

you can build custom editor on top of eclipse platform. involves developing eclipse plugins , ui behaviour if want parts of editor visual instead of text-based.

the thing eclipse can manage folder structure , concept of "project" , separate editors different files. can leverage eclipse's integration git or svn don't have worry developing part of editor.

as per conflicts , merging, if use text files , don't mind users being exposed underlying structure, can leverage existing tools eclipse have show , solve conflicts within editor.

i hope helps. broad question not sure if these high level ideas were looking for.