Перейти к основному содержанию
Если вы рассматриваете добавление или переработку какого-либо крупного компонента игры, рекомендуется отправить proposal до того, как вы начнёте писать код. Чёткое определение того, как ваша функция должна работать и сочетаться с остальной игрой, избавит вас от множества головных болей при переписывании вашего PR в 1-й2-й4-й 7-й раз перед его принятием.

​
Как составить proposal?

  1. Сделайте копию шаблона design proposal, находящегося в src/en/templates/proposal.md.
  2. Ознакомьтесь с Core Design Documentation SS14 (для proposal, связанных с геймплеем).
  3. Напишите ваш proposal (см. руководство по редактированию документации).
  4. Когда ваш proposal будет готов к рассмотрению, создайте pull request.
  5. Ваш proposal утверждён, когда maintainer выполняет его merge. Это зелёный свет для вас или кого-то ещё, чтобы реализовать его. Maintainer затем добавит ссылку на ваш proposal в боковую панель. Примечание для maintainer: отредактируйте src/SUMMARY.md
tip
Если вы считаете, что ваш proposal ещё не готов к проверке maintainer, но всё же хотите получить отзывы, вы можете оформить его как draft. Draft менее привлекают людей, желающих обсудить конкретные детали, но всё же позволяют оставлять комментарии и советы.

​
Нет, что такое design doc?

Design document — это краткое описание высокого уровня того, что вы предлагаете добавить в игру. По сути, они служат для того, чтобы зафиксировать нечёткие идеи на бумаге, чтобы было легче понять, как именно эти идеи будут сочетаться с остальным проектом. Обычно они состоят из нескольких частей.
  1. Зачем предлагается данная функция — может быть как просто «я думаю, это было бы круто», так и более конкретно, например «я заметил проблемы ABC в геймплейном цикле Cargo и хочу добавить XYZ для их решения».
  2. Краткое описание того, что представляет собой функция, как она взаимодействует с игроками и как взаимодействует с другими крупными частями игры.
  3. Более детальное описание предлагаемой механики функции, того, как игроки будут с ней взаимодействовать и как эта механика связана с другими частями игры. Не нужно вдаваться в каждую конкретную деталь; достаточно сказать, что должны быть химикаты, выполняющие определённые роли, не описывая точные химикаты.
Эти разделы не обязательно должны быть дискретными и не должны такими быть. Когда вы описываете механику, вероятно, стоит описать, как игроки будут с ней взаимодействовать и как это взаимодействие приносит пользу игре. Если вы хотите увидеть примеры успешных design documents, все принятые, но не реализованные design docs можно найти в разделе «Design Proposals» ниже. Design documents, которые были реализованы, со временем превращаются в feature docs в разделе «Space Station 14».
warning
- Включать описания на уровне псевдокода того, как работает ваша функция. Это для того, когда proposal уже принят, и вы реализуете его.
- Указывать числовые значения для каждого предмета, поля или механики. Это для последующего обсуждения баланса; например, достаточно сказать, что болезнь будет иметь один, несколько или много симптомов.
- Забывать описать, как игроки должны взаимодействовать с вашими функциями. SS14 — многопользовательская игра, и то, как игроки взаимодействуют с вашей механикой, важнее, чем конкретная механика.
- Писать целый полноценный FSD или SRS. Это не требуется и никогда не потребуется, так как является чрезмерным для проекта нашего размера и структуры.

​
Действительно ли моей идее нужен design doc?

Это зависит от масштаба и распространённости того, что вы предлагаете. Если это что-то вроде добавления одного оружия или пары простых растений — вероятно, нет. С другой стороны, если вы добавляете целый подотдел вроде аномалий/ксеноархеологии или нечто масштабное, как переработка целой ботаники или химии — то да. Хорошее эмпирическое правило: если новая функция или переработка, которую вы задумали, потребует добавления или переработки страницы guidebook или одного из feature docs на этом сайте, то, вероятно, нужен design doc. То же самое, если proposal можно точно описать как «переработка всего X».

​
Будет ли мой design doc принят?

Понятия не имею! То, что принимается, а что нет, определяется одобрением maintainer, как и обычные PR. Если вам удастся убедить хотя бы одного maint, что это звучит как хорошая идея, есть большая вероятность, что он будет принят. Практически любая идея потребует хотя бы некоторой критики, прежде чем будет смержена, так что не расстраивайтесь!
tip
Если вы хотите повысить свои шансы, рекомендуется прочитать [SS14 Core Design Documentation](/src/en/space-station-14/design), чтобы получить общее представление перед началом написания, так как это даст контекст того, почему вещи устроены так, как они устроены.

PR'd design documents также должны следовать [Decorum Guidelines](./feature-proposals/expected-feature-proposal-decorum).
Последнее изменение 21 июня 2026 г.