Vision & Scope

Паркур-режим — Vision & Scope

1. Контекст и проблема

На сервере существует режим строительства с ранговой системой, где строительство — это измеримый навык: игрок проходит оценку, получает ранг и открывает новые возможности. Паркур-режим расширяет эту концепцию на другой аспект Minecraft.

Паркур решает три задачи одновременно:

2. Целевая аудитория

Первичная аудитория — игроки, уже присутствующие на сервере в строительном режиме. Им знакома ранговая система, они понимают ценность прогрессии. Паркур предлагает им альтернативное занятие без необходимости менять сервер.

Вторичная аудитория — новые игроки, которых привлекает именно паркур как жанр. Для них режим является точкой входа на сервер.

3. Основной игровой цикл (Core Loop)

Вход в режим → Лобби
      
Автоматическая генерация уровня (по текущему рангу игрока)
      
Прохождение уровня
       (успех)                    (провал)
Получение опыта           Нет штрафа (обычный уровень)
      
Накопление опыта → порог ранга
      
Ранговый экзамен:
уровень повышенной сложности
с механиками следующего ранга
       (успех)              (провал)
Получение нового ранга    Штраф: снятие части опыта
Разблокировка механик     Повторная попытка позже

Важные детали цикла:

4. Независимые системы

Режим состоит из четырёх полностью независимых систем. Каждая система разрабатывается, тестируется и обновляется отдельно. Взаимодействие между ними происходит только через явно описанные контракты (см. документ Subsystems Spec).

Система

Ответственность

Знает о других системах

Ранговая система

Прогрессия, очки, экзамены, награды

Нет

Процедурная генерация уровня

Построение геометрии по параметрам

Нет

Парсер уровней в конфиги

Перевод построенных карт в данные генерации

Нет

Система создания мира

Разворачивание мира со сгенерированным уровнем

Нет

Единственная точка связи между системами — Subsystems Spec, где описан маппинг ранг параметры генерации.

5. Out of Scope — версия 1.0

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

6. Критерии успеха

Режим считается успешным при достижении следующих показателей:

7. Принцип независимости систем

Ни одна из четырёх систем не импортирует, не вызывает и не знает о внутреннем устройстве другой. Любое взаимодействие между системами проходит через контракт, описанный в Subsystems Spec. Нарушение этого принципа в коде требует обсуждения и обновления документации до мержа.

Этот принцип обеспечивает возможность замены любой системы (например, генератора уровней) без затрагивания остальных частей режима.

 


Revision #1
Created 2026-06-29 22:59:25 UTC by Colombino
Updated 2026-06-30 00:11:39 UTC by Colombino