tengri/Documentation/ProjectDecisions/DL_03.md

Лог Проектных Решений - Этап 3

Решение 1: Архитектура UI позиционирования

• Проблема: Ручное управление позициями тостов сложно и подвержено ошибкам
• Решение: Использовать Vertical Box container для автоматического стэкинга
• Обоснование: UE5 UI система лучше справляется с dynamic layout чем manual calculations
• Альтернативы: Manual positioning, Canvas Panel с абсолютными координатами
• Дата: 24.08.2025

Решение 2: Система типов сообщений

• Проблема: Нужна цветовая дифференциация для разных типов информации
• Решение: 6 семантических типов (Info, Success, Warning, Error, Debug, Test) с фиксированной цветовой схемой
• Обоснование:
  • Достаточно типов для всех игровых сценариев
  • Консистентная цветовая схема повышает UX
  • Test type специально для отладочной информации
• Альтернативы: Произвольные цвета, больше типов, только текстовая дифференциация
• Дата: 24.08.2025

Решение 3: Стратегия управления лимитами

• Проблема: Неограниченное количество тостов может заполнить весь экран
• Решение: FIFO (First In, First Out) с лимитом MaxVisibleToasts = 5
• Обоснование:
  • Старые сообщения менее актуальны
  • 5 тостов - баланс между информативностью и UI clutter
  • Простая и предсказуемая логика
• Альтернативы: Priority-based removal, LRU, настраиваемые приоритеты
• Дата: 24.08.2025

Решение 4: Duration handling для edge cases

• Проблема: Duration = 0 может означать "бесконечный" или "по умолчанию"
• Решение: Duration = 0 трактуется как DefaultDuration
• Обоснование:
  • Бесконечные тосты могут засорить UI
  • Более безопасное поведение по умолчанию
  • Соответствует принципу "fail-safe"
• Альтернативы: Duration = 0 как бесконечный toast, генерация ошибки при нулевом значении
• Дата: 24.08.2025

Решение 5: Дублирование в консоль

• Проблема: Тосты исчезают, но иногда нужна persistent информация
• Решение: Опция AlsoLogToConsole для дублирования всех тостов в UE консоль
• Обоснование:
  • Debugging удобнее с persistent логами
  • Output Log можно сохранить в файл
  • Опциональная функция не влияет на performance
• Альтернативы: Отдельная logging система, только для Error типов, file logging
• Дата: 24.08.2025

Решение 6: ID генерация и трекинг

• Проблема: Нужна возможность отслеживать конкретные тосты
• Решение: Простой инкрементальный ID генератор с возвратом ID из ShowToast()
• Обоснование:
  • Простая и быстрая генерация ID
  • Достаточно для игрового сценария (не distributed system)
  • ID нужны для debugging и potential future features
• Альтернативы: GUID generation, hash-based ID, no tracking
• Дата: 24.08.2025

Решение 7: Обработка disabled состояния

• Проблема: При IsEnabled = false что делать с попытками создать toast?
• Решение: ShowToast() возвращает -1, но console logging все еще работает
• Обоснование:
  • UI может быть отключен, но debugging information остается доступной
  • Graceful degradation вместо silent failure
  • Return value -1 указывает на проблему
• Альтернативы: Полное игнорирование, throw exception, queue до включения
• Дата: 24.08.2025

Решение 8: Тестовая архитектура

• Проблема: Нужно comprehensive тестирование всех аспектов системы
• Решение: 7 категорий автотестов покрывающих все major functions + edge cases
• Обоснование:
  • Каждая категория тестирует отдельный аспект
  • Edge cases предотвращают runtime failures
  • Автоматический запуск при инициализации ловит regression bugs
• Альтернативы: Manual testing only, unit tests в отдельном framework, integration tests
• Дата: 24.08.2025

Решение 9: Performance over features trade-off

• Проблема: Анимации и rich content vs простота и производительность
• Решение: Stage 3 фокус на функциональности, анимации отложены до Stage 4+
• Обоснование:
  • Стабильная база важнее visual polish
  • Анимации добавляют complexity в тестировании
  • Можно добавить позже без breaking changes
• Альтернативы: Immediate animation implementation, rich text support
• Дата: 24.08.2025

Решение 10: Integration с существующими системами

• Проблема: Toast система должна cooperate с Debug HUD без конфликтов
• Решение: Раздельное позиционирование (Debug HUD слева, Toasts справа)
• Обоснование:
  • Нет overlap между системами
  • Обе системы могут работать одновременно
  • Консистентное поведение с UX точки зрения
• Альтернативы: Shared UI space, toast overlay поверх debug info, mutual exclusion
• Дата: 24.08.2025