# 0001. Язык проекта — GDScript

- Статус: принято
- Дата: 2026-08-12

## Контекст

Редактор — .NET-сборка Godot, и в `project.godot` живёт секция `[dotnet]` с
`project/assembly_name`. Это выглядит как признак C#-проекта и провоцирует
вопрос, на чём вообще писать.

Признаком он не является: ключ прописывает GodotTools любой .NET-сборке при
открытии проекта, независимо от наличия C#. Настоящий маркер — сгенерированный
`.csproj` в корне. В истории репозитория его нет: 21 файл `.gd` и ни одного
`.cs`, `.csproj` или `.sln` ни в одном коммите. Плагин `addons/godot_ai` тоже
на GDScript.

## Решение

Пишем на GDScript. C# не заводим; если какой-то участок упрётся в
производительность, выносим точечно именно его, а не переезжаем целиком.

## Последствия

- Горячая перезагрузка без шага сборки, экспорт не требует .NET-шаблонов.
- Секция `[dotnet]` в `project.godot` остаётся: без `assembly_name` GodotTools
  пишет `Property not found`, а ключ всё равно возвращается. Игре она не нужна
  и трогать её не надо.
- Тяжёлые расчёты (симуляция многих жителей, поиск пути) придётся держать в
  уме: на GDScript они дороже, и когда упрёмся — это повод для нового ADR, а не
  для тихого добавления `.cs`.
- Рефакторинг и статические проверки слабее, чем в C#. Компенсируем строгой
  типизацией (см. соглашения в `CLAUDE.md`) и тестами в `tests/`.

## Альтернативы

- **C# целиком.** Строгие типы, зрелый рефакторинг и тест-фреймворки. Отвергнут:
  весь существующий код и плагин на GDScript, переписывать нечего ради выгоды,
  которая проявится только на тяжёлой симуляции; плюс шаг сборки и .NET-шаблоны
  при экспорте.
- **Гибрид с самого начала.** Отвергнут как преждевременный: границу
  GDScript↔C# пришлось бы проектировать до того, как известно, где узкое место.