99 lines
6.9 KiB
Markdown
99 lines
6.9 KiB
Markdown
# Лог Проектных Решений - Этап 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
|