rdaniil/lampbearer

lampbearer's Issues

Рефакторинг world

То, что world превращается в God-object скорее всего неизбежно, но мы можем вынести некоторые вещи в отдельные сервисы и использовать World как прокси\фасад.
Сейчас логика с светом вынесена в отдельный сервис
Для взаимодействия с сущностями и их атрибутами уже миллион методов, их тоже можно вынести.
И мб документацию где-то добавить

Смешивать пересекающиеся источники света

Сейчас, если два источника света будут пересекаться - один будет отображаться поверх другого.
Нужно смешать цвета этих источников света. Для смешивания надо чето типа такого реализовать.

https://stackoverflow.com/questions/726549/algorithm-for-additive-color-mixing-for-rgb-values

Освещение реализовано в com.vdn.lampbearer.services.light.LightingService

Чтение из REX файла с цветами после реализации #15

Реализовать чтение из файла с учетом цвета фона и символа

Реализовать функцию "осмотра"

Жмем "L", двигаем курсор и читаем описание объекта\блока

Реализовать туман войны

Реализовать логирование в игровую консоль

При открытии меню инвентаря (U) тратится ход, даже если игрок ничего не делает

Реализовать "зрение" игрока

Сейчас игрок видит сквозь стены, если за стеной фонарь. Монстры на исследованных участках отображаются где бы игрок ни был

Возможное решение:
Сделать некую область видимости вокруг игрока, которая строится аналогично источникам света (лучами).
С таким решением мы не будем видеть сквозь стены, но будем видеть монстров где угодно в уже изученных областях.
Возможно нужно использовать параметр Perception и на основе него вычислять как далеко мы можем смареть в изученной области.

По идее мы должны видеть чуть больше чем освещает наш фонарь, но освещенные участки карты мы должны видеть издалека.

Реализовать сигнальную ракету

Заряжается в револьвер
Летит в виде источника света, замирает на точке, куда стреляли, какое-то время светит

При использовании бутылки с маслом, заполняется первая попавшаяся масляная лампа

Если в инвентаре будет две лампы или появится какой-то предмет который тоже можно маслом заправлять - будет плохо.

Реализовать отображение монстров только в области видимости игрока

Нужно отображать монстров только в освещенных участках + отображать только, если у игрока достаточно высокий perception?

Починить баг отображения лога при добавлении новой записи

Когда окно лога полностью забито, при добавлении новой записи, самое верхнее сообщение детачится (detach()). При этой операции компонента на 1 кадр переносится в левый верхний угол

Реализовать логирование в игровую консоль

Реализовать масляную лампу

• Освещает окружность
• Динамический источник света, когда в чьих-то руках
• Можно включать\выключать
• Можно бросить включенным и тогда он превращается в статический источник света
• В включенном состоянии тратится масло
• Понять как пополнять масло

Relocate constants to application.properties

From
GameConfig, GameCharacterConstants and GameColorConstants

Example
https://www.baeldung.com/properties-with-spring

Приложение крашится при достижении границы карты

При достижении игроком границы карты приложение крашится.

• Ожидаемое поведение: игрок просто упрется в границу и не сможет дальше границы карты идти
• Фактическое поведение: краш приложения

Реализовать масло в масляной лампе

Лампа должна тратить топливо
Топливо нужно как-то пополнять
Отображать топливо в интерфейсе

Переделать концепцию создания тайлов и блоков

Кардинально меняем тактику работы TileRepository, совершенно нерасширяемая концепция + при чтении карты из файла необходим экстремальных размеров switch-case.

Тайлов нужно создавать как можно меньше в связи с здравым смыслом и экономием памяти.

• У тайла с уникальным набором показателей (цвет фона\символа, символ) должен быть только один инстанс
• Набор дефолтных тайлов точно должен быть
• Должна быть возможность добавления новых тайлов в рантайме. (Если тайла не существует - создать, если существует - вернуть существующий инстанс).

---

У блоков аналогичная ситуация.
При генерации карты в будущем мы умрем писать гигантские свичи чтобы коробку квадратную нарисовать (для коробки надо 6 уникальных символов (4 угла, горизонтальная полоска, вертикальная полоска)).
Нужно что-то аналогичное тайлам придумать.

Пофиксить мигание блока с отображением характеристик игрока + мб переделать хп на полоску

Он мигает, потому что перерисовывается каждый раз. Когда вызывается detach() компонент на один кадр переносится в левый верхний угол, потом рисуется новый.
Возможный фикс: залезать в внутреннее состояние компоненты и менять там текст на обновленный, тогда не надо будеть детачить ничего.

Подбор и выбрасывание предметов из инвентаря

Реализовать отображение нескольких действий на экране при одном нажатии клавиши игрока

Сейчас, монстры, двигающиеся быстрее игрока "телепортируется" при движении игрока, а хотелось бы видеть как они двигаются поклеточно. + В будущем пригодится при отрисовке пуль и т.д

Понять как уменьшить количество объектов в контексте

Сейчас их уже 5
Кажется что взаимодействие с логом, экраном, боковой панелью можно вынести в сервис(ы).
Мб с спрингом что-то намутить

Переделать основной цикл с использованием poll

Сейчас (#25) там бесконечный цикл с while, лучше переделать на poll
+ возможно пофиксит проблему с ломающейся версткой, надо проверить

Более быстрые монстры выполняют действия перед игроком

• ОП:
  • Когда ходит игрок, его действие выполняется самым первым
• ФП:
  • Когда ходит игрок, перед ним ходят другие монстры.
  • Возникает странная ситуация, если монстр подобрался в упор. При попытке убежать, быстрый монстр нас сначала пару раз атакует, а потом мы от него отойдем, а он останется стоять где стоял.
    • По идее в этой ситуации мы должны отойти на клетку, а потом монстр подходит и атакует нас один раз

Ремарка:
Некоторые монстры все еще должны быть быстрее игрока, но нам должны давать ход, только когда он будет выполнен прямо сейчас.

При наслоении света друг на друга уровень освещенности зависит от порядка отрисовки

А так же затенение сущностей работает очень криво.
Если сущность освещена краешком источника света, то она затеняется.
Но, если игрок подойдет в упор и осветит сущность своим светом, то, если свет игрока отрисовывается раньше, сущность будет в тени, хотя рядом с ней игрок, светящий на нее. В итоге сущность как будто в темноте, но по факту освещена.

Реализовать непроходимые блоки

При взаимодействии с несколькими предметами вокруг спрашивать с каким надо взаимодействовать

Реализовать всплывающее окно над логом или в правой панели.

• Выводит сущности вокруг игрока (будет круто, если будет видно кто где находится)
• Задающее вопрос с какой сущностью взаимодействовать ( указать направление с помощью WASD)

Релизовать RTX свет по окружности

Текущий алгоритм по окружности слабый, потому что использует целочисленные координаты точек окружности и из-за особенностей построения прямых мы покрываем не все клеточки внутри круга.
Поэтому предлагается попробовать строить линии до float-координат круга (соответственно точек на окружности станет больше) и тогда, возможно, все клеточки закрасятся.

Для реализации нужно уметь получать список точек окружности и строить линии до дробных точек/

Если будет норм работать - сможем очень просто строить свет в виде конуса

Статический круглый источник света (фонарь)

Освещенные участки видно отовсюду, вне зависимости от Perception игрока

Improve WanderingBehavior. Create AttackingBehavior and ChasingBehavior.

Доделать WanderBehavior и MoveToAi следующим образом:

1. Выбираем рандомную позицию в определенном радиусе
2. Двигаемся к ней по алгоритму Брезенхэма (LineFactory)

Уменьшать радиус свечения масляной лампы ближе к концу жизни лампы

Когда лампа стоит на полу, тоже должно работать

Разобраться как реализовать анимацию без блокирования потоков, приводящих к графическим артефактам

Сейчас, даже если убрать Sleep между ходами монстров, остаются графические артефакты, предположительно связанные с блокировкой потока.
Понять как нормально реализовать основной цикл игры снаружи обработчика клавиатуры.

Реализовать револьвер

Должен уметь стрелять и перезаряжаться

Помечать блоки "увиденными" только если свет находится на отображаемом куске карты

Сейчас, если какой-нибудь монстр с фонарем будет гулять далеко за границами карты - блоки пометятся как увиденные и мы придем в изученную область карты.

• Самое простое решение:

  • Помечать "SEEN" только те блоки, которые мы в данный момент видим на экране.

• Сложнее но корректнее:

  • Помечать + отображать только те источники света, которые видит игрок (т.е.. если игрок находится внутри дома, он не должен видеть что снаружи кто-то ходит с фонарем.

Выбор действия с предметом инвентаря

Модальное окно с опциями типа

• Drop
• Use

Оптимизировать освещение

Сейчас свет отрисовывается при каждом шаге. Можно как минимум не отрисовывать каждый раз статические источники света.
Но тогда не понятно как обновлять блоки, которые окрашиваются статическим и динамическим светом одновременно. Мб эту проверку делать достаточно

Починить мигание блока с отображением инвентаря

Реализация инвентаря и предметов

Создать поведение ходить-бродить

Доделать WanderBehavior и MoveToAi следующим образом:

1. Выбираем рандомную позицию в определенном радиусе
2. Двигаемся к рандомной позиции

Вывод Хп игрока на UI

Реализовать Printable, вывести все Printable атрибуты

Реализовать чтение из REX файла

Создать сервис для броска кубика

Нужен сервис, позволяющий реализовать бросок кубика.

Предлагаю использовать паттерн Builder, потому что если просто парсить строки выражений - можем написать кривую строку и упасть на этапе выполнения, а хотелось бы на этапе компиляции.

Нужно иметь возможность реализации выражений вида:
1d20 - бросить 1 кубик с 20 гранями
2d6 - бросить 2 кубика с 6 гранями
3d3 + 2 - бросить 3 кубика с 3 гранями, добавить к результату число 2
2d6 + 1d3 + 3 - бросить 2 кубика с 6 гранями, добавить к результату бросок 1 кубика с 3 грянми, добавить к результату число 3

В коде должно быть чето типа:

DiceBuilder.dice(1, 20).roll()
DiceBuilder.dice(2, 6).roll()
DiceBuilder.dice(3,3).plus(2).roll()
DiceBuilder.dice(2,6).dice(1,3).plus(3).roll()

Вынести логику обработки действий игрока из движка

Наследовать игрока от Actor, реализовать Behavior.
Перенести обработку клавиатуры и движение камеры из ScheduledEngine в Behavior

Если включить задержку отрисовки в движке для "анмимации" движений, то свет отрисовывается с задержкой

ОП:
Игрок двигается вместе с светом, который
ФП:
Игрок двигается, через пол секунды за ним двигается свет

Реализовать "анимацию" движения монстров, только когда они в области видимости игрока

Сейчас, если у нас на карте будет 20 монстров, мы будем ждать 20 * количество_мс_между_кадрами. Если игрок не будет видеть монстров, то это будет выглядеть так, будто игра не считывает инпуты.
Надо понять как реализовать анимацию только для монстров в области видимости

Рефакторинг Reaction

Разбить классы на пакеты (сгруппировать их по какому-то принципу, а то у нас там ща уже портянка солидная при открытии пакета)

Запилить дверь

Дверь, должна наследоваться от AbstractEntity. Все живые сущности наследуются от Actor, мб для неживых тоже класс какой-то сделать, но пока не понятно.

• Логика
  • Закрытая дверь не пропускает Actor'a (т.е. не только игрока, но и монстра)
  • Открытая дверь пропускает (Монстр должен мочь открыть дверь)
  • Дверь открывается либо по нажатии специальной кнопки, либо просто при попытке зайти в нее
  • Сначала тратится ход на открытие двери, а потом мы следующим ходом можем встать на нее
• Отображение (на картинке)
  • Закрытая дверь имеет один символ (в идеале коричневая горазонтальная или вертикальная палка (─, │)
  • Открытая другой (коричневый слеш )
  • P.S. Если придумаете более хорошие способы отображения - бомба

Рефакторинг PlayerBehavior

Миллион логики там уже в том числе UI, надо чето придумать

Возможность бросать камни

• Выбираем камень в инвентаре
• Выбираем "бросить"
• Выбираем цель
• Камень анимированно летит, при столкновении с сущностью - наносит ей урон, если уместно, если нет то просто разрушается

Концепция реализации:

• Камень реализует новый интерфейс\абстрактный класс Projectile + существующий Updatable.
  • В дальнейшем появятся пули, пули как минимум отличаются тем, что могут пролетать сквозь сущности нанося урон - соответственно предусмотреть такую возможность.
• После выбора цели, указываем у Projectile позицию куда оно летит
• Создаем Action\Reaction броска камня, наследует TargetedReaction (нужно чтобы мы поняли, что для этой реакции необходимо выбрать позицию (понять нужен ли абстрактный класс, или хватит интерфейса))
  • Reaction добавляет Projectile в World в качестве Updatable.
• Дальше в методе update летит к своей цели.
• При столкновении с сущностью вызывается какой-то другой Reaction, аналогичный AttackReaction , который будет наносить урон + уничтожать камень (или не уничтожать пулю\уменьшать пуле услоное хп (чтобы она не могла через миллион монстров пролетать)). Но возможно камень надо удалить внутри метода update

В принципе если камень как в жизни, то он не должен лететь супер быстро = не должен прилетать в свою цель за один ход. Но на будущее есть смысл попытаться сделать так, чтобы камень долетел за один ход. Идея как это сделать:
Делаем скорость камню = 0, если камень рано или поздно уничтожится - мы его удалим из расписания и бесконечного цикла не будет.

Использование предметов инвентаря