Проекты
SS14 и RobustToolbox разделены на несколько различных проектов. Основные, с которыми вы будете иметь дело — это проекты Client, Shared и Server. Другие проекты предназначены для более мелких вещей, таких как интеграционные тесты, бенчмарки или код, специфичный для базы данных.
Client, Shared и Server упакованы в разные «assembly» (сборки), что по сути является .NET-термином для исполняемых файлов или разделяемых библиотек.
Проект Client как в Robust, так и в SS14 содержит клиентский код, например UI. Эта сборка отправляется только клиенту — человеку, который фактически играет в игру.
Проект Server содержит серверный код, с которым не должен взаимодействовать клиент, например атмосферу или ботанику. Эта сборка находится только на игровом сервере.
Проект Shared содержит общий код, который может использоваться как клиентом, так и сервером. Эта сборка не является исполняемой и полагается на то, что клиент или сервер вызывают функции или используют классы данных, расположенные в ней. Цель shared — обеспечить сетевую предсказуемость (где клиент и сервер выполняют один и тот же код для более плавной работы), а также определить общие классы данных, такие как сетевые сообщения, чтобы клиент и сервер могли эффективно общаться.
Shared-код может обращаться только к другому 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’; такие папки — ад для организации, и совершенно произвольно, что в них помещать. Вы можете поместить меньшие игровые системы внутри более крупных, если это однозначно имеет смысл (Atmos -> Piping), но не сваливайте все мелкие системы в misc.
Эта структура должна стать очевидной после работы с ней или просмотра примеров.
Реальный пример из Content.Server на da11cbd8e6bef3373ec1f570df7d7b9155a3890f
- Atmos — довольно крупная игровая система. У неё много папок и много файлов, которые не обязательно помещать в эти папки.
- Botany — меньшая игровая система. Однако у неё есть только одна папка для Components, поскольку только это там и нужно.
- ItemCabinets — очень маленькая игровая система. У них есть только компонент и EntitySystem, поэтому папки для каждого не нужны.
Ресурсы
Папка ресурсов — ещё одна область, в которой мы надеемся превзойти структуру организации кодовых баз SS13.
Entity Prototypes
Новые папки обычно следует создавать только для нового родительского типа. Если вы обнаружили что-то, что можно вынести в родительский prototype, это нужно поместить в отдельную папку.
Родительские prototypes должны содержаться в base.yml в этой папке, а остальные prototypes — в отдельном файле.
Не везде так организовано; однако папка Structures организована именно так.
Это было выбрано для того, чтобы структура директорий отражала дерево наследования prototypes, делая очевидным, куда помещать новые prototypes, и достаточно однозначным при выборе создания новых папок.Последнее изменение 21 июня 2026 г.