Files
g-world/docs/adr/0001-yazyk-proekta-gdscript.md

2.8 KiB
Raw Permalink Blame History

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# пришлось бы проектировать до того, как известно, где узкое место.