Организация кодовой базы

Проекты

SS14 и RobustToolbox разделены на несколько разных проектов. Основные, которые вас будут волновать, — это проекты Client, Shared и Server. Остальные проекты предназначены для более мелких вещей, таких как интеграционные тесты, бенчмарки или код, специфичный для базы данных.

Client, Shared и Server каждый упакован в разные «сборки», что на языке .NET в основном означает исполняемые файлы или разделяемые библиотеки.

Проект Client и в Robust, и в SS14 содержит код, специфичный для клиента, например UI. Эта сборка отправляется только клиенту, то есть человеку, который на самом деле играет в игру.

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

Проект Shared содержит общий код, который может использоваться клиентом или сервером. Эта сборка не является исполняемой и полагается на то, что клиент или сервер вызовет функции в ней или использует классы данных, расположенные внутри неё. Цель shared — позволить сетевое предсказание (когда клиент и сервер выполняют один и тот же код, чтобы всё работало плавнее), а также указать общие классы данных, например сетевые сообщения, чтобы клиент и сервер могли эффективно общаться друг с другом.

Общий код может обращаться только к другому общему коду, но не к клиентскому или серверному. Однако клиентский и серверный код всегда могут обращаться к общему коду.

Игровой код

В SS13 весь игровой код случайно разбросан под code/ и вместо группировки по отношению к системам сгруппирован по абстрактным вещам, например является ли файл списком констант или относится ли файл к подсистеме мастер-контроллера. В SS14 мы сначала разграничиваем по игровой системе, с которой работаем (atmos/botany/buckling и т. д.), а затем по классам, нужным для неё, что гораздо проще для любого, кто на самом деле пытается работать в рамках одной системы.

Content.Client, Content.Shared и Content.Server все следуют этой организации. Эквиваленты в RobustToolbox сейчас этого не делают, но в будущем будут.

  • Весь игровой код будет организован в папки, расположенные непосредственно под Content.Client/Shared/Server и т. д.
  • Папки игрового кода разделены на Components, EntitySystems, Visualizers, UI, Prototypes и т. д.
  • Если в папке был бы всего один файл, папка не нужна (если только этот файл не попал бы прямо в верхний каталог проекта, что нежелательно).
  • Не используйте папки «misc»; папки misc — ад для организации, и совершенно произвольно, что в них попадает, а что нет. Вы можете инкапсулировать меньшие игровые системы внутри больших игровых систем, если это однозначно имеет смысл (Atmos -> Piping), но не стоит просто сваливать все меньшие игровые системы в папку misc.

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

Реальный пример под Content.Server на коммите da11cbd8e6bef3373ec1f570df7d7b9155a3890f

  • Atmos — довольно крупная игровая система. В ней много папок и много файлов, которым не нужно находиться в этих папках.
  • Botany — меньшая игровая система. Однако у неё есть только одна папка для Components, поскольку это всё, что там действительно есть.
  • ItemCabinets — очень маленькая игровая система. У неё есть только компонент и EntitySystem, поэтому папки для каждого из них не нужны.

Ресурсы

Папка resources — ещё одна область, которую мы надеемся улучшить по сравнению со структурой организации кодовых баз SS13.

Прототипы сущностей

Новые папки обычно следует создавать только для нового родительского типа. Если вы найдёте что-то, что можно вынести в родительский прототип, это должно лежать в своей собственной папке.

Родительские прототипы должны содержаться в base.yml в этой папке, а остальные прототипы — в другом файле.

Не везде организовано так; однако папка Structures организована именно так.

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

Subpages