кейс
Як ми перетворили «Чому» на відтворюваний контракт канону InterDead
Кейс про публічну вікі, SSOT і дисципліну змін як операційний контракт канону.
Про велике й страшне «Чому» в геймдизайні.
Контекст
InterDead працює на перетині наративної архітектури й механічної реалізації, де кількість сутностей, протоколів і локалізацій постійно зростає. Кожний елемент взаємодіє з багатьма іншими, створюючи накопичувальну складність.
Проблема
Локальні рішення виникали без спільної причинності, значення дублювалися, терміни тлумачилися по-різному, а суперечності множилися разом із каноном. Багатомовність ускладнювала узгодженість. Проєкт масштабувався швидше, ніж дисципліна його підтримки.
Гіпотеза
Якщо перенести канон у публічну вікі та дати кожній сутності явне «Чому», структура стане керованішою. Оновлення проходитимуть хвилями, причинність стане перевірюваною, синхронізація команди прискориться, а локалізації будуть похідними версіями.
Рішення
«Чому» стало операційним інструментом — контрактом канону. Кожна сутність повинна мати:
- визначене призначення;
- задокументовані причинні зв’язки;
- чітку сферу застосування;
- описувані наслідки.
Вікі одночасно є середовищем формалізації та системою обмежень.
Метрики ефекту
Ефект є архітектурним: передбачуваність масштабування, менше внутрішніх суперечностей, менша семантична розбіжність між локалізаціями та швидші рішення. Найважливіший результат — контроль причинності.
Побічними ефектами стали швидше редагування та краще залучення аудиторії; останнє розглядається окремо в кейсі «How We Offset Development Costs».
Обмеження
Модель підвищує поріг входу, вимагає термінологічної дисципліни й уповільнює спонтанні ітерації. Для коротких прототипів без довготривалого канону вона може бути надмірною.
Самодисципліна як головний чинник
Модель працює, коли кожне рішення відповідає на «Чому», канон фіксується до масштабування, а публічність вікі тисне в бік точності формулювань. Творчість набуває структури.
Архітектура моделі
SSOT: єдине джерело істини
Первинна версія канону є англомовною. Інші локалізації похідні, тому суперечки про «правильну» версію не виникають.
Процес change-list
Кожна зміна проходить послідовність:
- визначити «Чому»;
- назвати всі заторкнуті сторінки;
- оновити основний матеріал;
- поширити залежні зміни хвилями;
- перевірити локалізації.
Три режими публікації
Ми розрізняємо ручну публікацію, напівавтоматичні збірки та повну API-синхронізацію через Action API + CI. Ручна форма гнучка, але схильна до помилок; напівавтоматична зменшує копіювання; API дає високу синхронність і масштабованість. Автоматизація не скасовує редакційної відповідальності за семантичні зміни.
Наступний етап
Наступний рівень — культурна адаптація канону зі збереженням «Чому» при зміні культурного контексту.
Висновок
Публічна внутрішня система перетворила «Чому» на контракт, редакційний фільтр, архітектурний стабілізатор і механізм синхронізації.