burningrain / planetbot

planetBot

go to wiki

planetbot's Issues

update to javafx

Задача: перевести main-app со swing на javafx.
Также это означает переход на java 8.
Цели:

• ускорение отзывчивости интерфейса
• уменьшение размера модуля за счет выкидывания jung 2.0 и тянущихся с ним библиотек, и написания собственного функционала отображения графа
• увеличение гибкости ui-я, уменьшение boilerplate-кода, за счет лямбд и двустороннего биндинга
• просто потому что по-хипстерски!

Переход будем делать в несколько этапов:

1. Просто hello world java fx, который запускается в нашем контейнеры
2. Добавление в новый модуль логики из main-app посредством свинг-нод. Рефакторинг.
3. Избавление от свинга и сопутствующих библиотек, написание своей/использование чужой библиотеки графов для java fx. (Задел на события клика мышкой по отдельным узлам графа, их перетаскивание и т.п.)

game-ui and ui-plugin-api

Необходимо сделать каркасный модуль для ui-plugin. Данный модуль является "скелетом, на который будет наращиваться мясо", а именно: модуль содержит логику по отрисовке основных панелек/менюшек/тулбара и добавлению/удалению компонентов на них из ui-plugin-ов.
Как предполагается писать класс ui-plugin-а:

1. Имплементируем какой-то интерфейс (н-р, IMenu или IToolbar)
2. Ставим osgi-аннотацию @component
3. Имплементируем в данном классе логику по обработке действий
   Разумеется, один ui-plugin может поставлять множество таких классов.

В связи с этим и требуется некий каркас, в ячейки которого декларативно через интерфейсы и аннотации и будут встраиваться ui-plugin-ы.
Необходимо разработать как сам game-ui, так и ui-plugin-api

planet's master choose is wrong

Воспроизведение:

1. добавил стратегии Unpredictable1 и Unpredictable2
2. выбрал карту test2.gv
3. запустил ботов играть

Наблюдаю:

1. иногда захват планет происходит не с первого раза.
2. при попытке удара по 3-м пустым планетам захвата трех планет не происходит.

UiSharedState

Для согласования состояний ui-plugin-ов помимо отправки событий возникнут моменты, когда будет необходимо сохранять состояние, которое необходимо передавать между различными ui-plugin-ами. Предполагается решать эту проблему с помощью еще одного модуля (н-р, назовем его SharedState), через который будет происходить чтение/запись некоторых ui-данных.

Требования:

• изменение в ui-plugin-е не должно требовать пересборки этого модуля (SharedState)
• возможность перелезть на другую бд нам не важна. ui-plugin-ы не будут использоваться в недесктопной версии приложения (по причине тесной связи с javafx-классами).
• завязывать модели на этот модуль строго не рекомендуется.

Решение:
Это означает, что решения типа jooq не подходят. Предпочтительна разработка от бизнес-логики, а не базы. Также это означает, что по причине слабой, но зависимости ui-plugin-ов друг от друга (сильную не делаем, чтобы один плагин не вешал другой) между ними может возникать несочетаемость. Это тоже надо учитывать при разработке ui-plugin-а.

1. Новые entity будут подкладываться к SharedState через osgi-fragments, и находиться в пакете с конкретно-заданном названием
2. Накатка базы create-update происходит каждый раз при старте модуля SharedState. Модуль находит все entity в конкретном пакете и по ним накатывает бд.
3. Наружу выставляется api, которое скрывает часть работы с бд. Т.е. все entity и часть функционала для запросов.

Необходимо рассмотреть за и против в плане:

• реляционное решение: "hibernate+h2/hypersonic" или подобное
• нереляционное: "Xodus от JetBrains" или подобное

UI crash when load map

private class UglyHuckRenderer extends BasicRenderer<Planet, String>{
   super .....
}

Point2D p = (Point2D)layout.transform(v);
после этого
p=null
и падает
float x = (float)p.getX();

    private final Set<Planet> planets;
    private final Set<Planet> startPoints;

Связывать не по обжектам а по ид планет в Сете

map service validation

В парсер необходимо добавить валидацию. Предлагаю сделать в парсере простую валидацию обязательных и необязательных параметров. В случае отсутствия обязательного параметра выкидывать исключение (н-р, MapValidationException, который расположить в map-api).
То есть парсер будет валидировать исключительно корректность формата.
Более сложная валидация, включающая в себя логику и зависимость одних параметров от других (н-р, что на карте "большие базы" должна быть только одна малая планета) будет размещаться в game-core. Проверка корректности галактики будет происходить при попытке создания игры. И в случае некорректности выкидываться исключение.
Такая "размазанность" валидации сделает парсер более тупым, а значит:

1. упростит переход на новый формат и написание нового парсера (не придется дублировать сложные логические проверки в новом парсере)
2. двигло остается защищенным, и не начнет обработку некорректной галактики.И это независимо от того, откуда галактика получена (ну а вдруг не из парсера?! Ну, мало ли...).
3. в случае нескольких движков у каждого из них может свое представление о корректности галактики (н-р, один считает нормальным планеты без связей, а другой нет и т.п.), поэтому эта логика валидации в теории может различаться.
4. имхо, вполне логично валидировать данные тому, кто их получает. Галактику получает движок, а не парсер. Парсер получает .gv файл и отдает галактику движку. Иллюстрация к моей мысли - это работа технического переводчика. Он может перевести технический текст с английского на русский, но он может не понимать сам предмет. Насколько плохо он перевел, понимает специалист в технической области, который, однако, не понимает исходный английский язык. Задача переводчика в данном случае сводится к тому, чтобы перевести текст так, чтобы спец поменьше матерился, читая данный перевод. Но это не значит, что переводчик должен знать тонкости технического предмета.

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

Map Service

Необходимо сделать возможность загрузки карт для бота из популярного формата для описания графов - https://ru.wikipedia.org/wiki/DOT_(%D1%8F%D0%B7%D1%8B%D0%BA) http://www.graphviz.org/Documentation/dotguide.pdf
Возможно, хорошие парсеры и билдеры ужу существуют (https://github.com/shevek/graphviz4j)
http://zvtm.sourceforge.net/zgrviewer/doc/ajapad/dotParser.html
https://github.com/nidi3/graphviz-java
https://mvnrepository.com/open-source/graphviz-libraries
надо поискать
https://wiki.eclipse.org/GEF/GEF4/DOT/User_Guide
http://git.eclipse.org/c/

Integration Tests

Необходимо разобраться с интеграционным тестированием в OSGi. Как писать, как запускать, как использовать совместно с Travis.