Что такое хорошая структура для файлов, отредактированных параллельно несколькими людьми

Question

Я делаю то, что составляет редактор уровней для игры, и я не уверен, что лучший способ сохранить игровой контент в виде файла. Чтобы быть понятным, это вопрос дизайна, а не технический.

Содержание игры может быть разбито иерархически на несколько уровней, каждый с несколькими сценами, которые имеют несколько событий и т. Д., Каждый из которых относительно независим. Однако есть также данные, такие как элементы и символы, которые будут называться глобально по всей игре.

В идеале этот редактор будет поддерживать нескольких пользователей, каждый из которых может редактировать неконфликтные части содержимого игры, а затем объединять изменения без проблем (подумайте об исходном коде в системе управления версиями). В идеале, игровой контент также должен быть легко загружен в игру после завершения (т. Е. Я должен иметь возможность загрузить «уровень» и объединить все необходимые куски без навигации по файловой системе).

Я придумал несколько идей о том, как я мог бы сделать это, ни один из которых не являются полностью удовлетворительными:

• Split содержание игры во многих файлах, так что параллельные редактирует легко сделать и слияние. Используйте структуру папок и файл проекта, чтобы отслеживать файлы, что-то вроде того, как Visual Studio обрабатывает проекты кода. Недостатки в том, что в игре сложнее управлять, и контент более сложно ссылаться на другой контент в другом файле (например, персонаж, у которого есть элемент).

• Используйте один двоичный файл, но создайте функцию слияния, аналогичную тому, что делает MS Word (или как git объединяет текстовые файлы). Недостатком является то, что это означает, что вам необходимо вручную разрешить все конфликты слияния, и функциональность слияния, скорее всего, будет нецелесообразной для реализации.

• Используйте только несколько файлов для представления больших фрагментов игры и надейтесь, что люди, использующие редактор, достаточно умны, чтобы одновременно не редактировать один и тот же. Сознания очевидны, но это было бы намного проще реализовать.

Очевидно, что у меня есть проблема, но, надеюсь, я дал достаточно информации, чтобы люди знали, о чем я говорю. У кого-нибудь есть полезная информация или у кого-то была аналогичная проблема?

Если это помогает, это, скорее всего, файлы .json, с версией git.

Answer 1

Я думаю, что это немного зависит от того, насколько сложным будет ваш редактор и как вы хотите, чтобы ваши пользователи не знали о базовом дизайне.

Вот некоторые общие мысли из моего опыта с родственными проектами:

• Даже если разделить содержимое на большое количество файлов, всегда есть вероятность того, что два пользователя редактировать один и тот же один, так что конфликты и слияние будет иметь быть частью вашего дизайна во всех случаях.
• Если вы используете двоичные файлы, вам, вероятно, придется разработать собственное решение для отображения конфликтов и разрешить пользователям их объединять. Я бы подумал об использовании текстовых файлов в стандартном формате, таком как XML или JSON. Это может позволить вам повторно использовать существующие инструменты слияния либо отдельно, либо встроенные в ваш редактор.
• Меньшие файлы легче объединяются визуально, поэтому, если вы можете разделить конфигурацию на более мелкие части и иметь отдельные файлы для каждой части, это облегчит вам жизнь.Затем вы можете предоставить вашему редактору необходимую информацию для загрузки каждого файла и создания связей между этими разделами, которые связаны с символами с элементами.

И вот возможный дизайн Я видел себя в проекте, над которым я работал. Возможно, это слишком много, если вы пытаетесь построить что-то меньшее, но вы можете принять некоторые идеи:

Вы можете создать собственный редактор поверх платформы Eclipse. Это предполагает разработку некоторых плагинов Eclipse, а также некоторого поведения пользовательского интерфейса, если вы хотите, чтобы части вашего редактора были визуальными, а не просто текстовыми.

Хорошо, что Eclipse может управлять структурой папок для вас, а также концепцией «проект» и отдельными редакторами для разных файлов. Вы также можете использовать интеграцию Eclipse с Git или SVN, поэтому вам не нужно беспокоиться о разработке этой части вашего редактора.

В соответствии с конфликтами и слиянием, если вы используете текстовые файлы и не обращаете внимания на то, что ваши пользователи подвергаются воздействию базовой структуры, вы также можете использовать существующие инструменты, которые Eclipse должны показывать и разрешать конфликты внутри редактора.

Надеюсь, это поможет. Это был широкий вопрос, поэтому не было уверенности в том, что эти идеи высокого уровня были тем, что вы искали.