> ## Documentation Index > Fetch the complete documentation index at: https://docs.ss14.art/llms.txt > Use this file to discover all available pages before exploring further. # Организация кодовой базы ## Проекты 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, и достаточно однозначным при выборе создания новых папок.