public void artificialIntelligence() { // Искусственный интеллект

new Thread(() -> {

while (ApplicationStates.currentActivity == 2) {

try {

if (currentHp > Math.round (currentHp * 0.66)) tempBonus = 5;

priorityArray[0] [0] = priorityArray[0] [0] + (int) Math.round (hitBonus * GameConfig.randomGenerator.nextInt (7 + tempBonus));

tempBonus = 0;

if (priorityArray[0] [0] >= priorityArray[1] [0]) {

hitSkill.skillExecute();

priorityArray[0] [0] = 0;

}

if (GameBattle.castStatePlayer) tempBonus = 15;

priorityArray[0] [1] = priorityArray[0] [1] + (int) Math.round (blockBonus * GameConfig.randomGenerator.nextInt (7 + tempBonus));

tempBonus = 0;

if (priorityArray[0] [1] >= priorityArray[1] [1]) {

blockSkill.skillExecute();

priorityArray[0] [1] = 0;

}

if (currentHp < Math.round (currentHp * 0.33)) tempBonus = 10;

priorityArray[0] [2] = priorityArray[0] [2] + (int) Math.round (healBonus * GameConfig.randomGenerator.nextInt (7 + tempBonus));

tempBonus = 0;

if (priorityArray[0] [2] >= priorityArray[1] [2]) {

healSkill.skillExecute();

priorityArray[0] [2] = 0;

}

if (currentHp < Math.round (currentHp * 0.66)) tempBonus = 5;

priorityArray[0] [3] = priorityArray[0] [3] + (int) Math.round (leechBonus * GameConfig.randomGenerator.nextInt (7 + tempBonus));

tempBonus = 0;

if (priorityArray[0] [3] >= priorityArray[1] [3]) {

leechSkill.skillExecute();

priorityArray[0] [3] = 0;

}

if (GameBattle.blockStatePlayer) tempBonus = 15;

priorityArray[0] [4] = priorityArray[0] [4] + (int) Math.round (penetrateBonus * GameConfig.randomGenerator.nextInt (7 + tempBonus));

tempBonus = 0;

if (priorityArray[0] [4] >= priorityArray[1] [4]) {

penetrateSkill.skillExecute();

priorityArray[0] [4] = 0;

}

if (GameBattle.castStatePlayer && currentHp > Math.round (currentHp * 0.66)) tempBonus = 10;

priorityArray[0] [5] = priorityArray[0] [5] + (int) Math.round (reflectBonus * GameConfig.randomGenerator.nextInt (7 + tempBonus));

tempBonus = 0;

if (priorityArray[0] [5] >= priorityArray[1] [5]) {

reflectSkill.skillExecute();

priorityArray[0] [5] = 0;

}

Thread.sleep(100);

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}).start();

}

4.4 Проектирование пользовательского интерфейса

Интерфейс приложения проектировался учетом требований, описанных в разделе 3. В ходе выполнения проекта были изучены библиотеки Swing и AWT, позволившие реализовать оконное приложение с графическим интерфейсом.

Различные графические состояния реализуются в одном окне путем выбора из различных возможных вариантов, условно обозначенных как состояния. Пример реализции функции (paint) игрового режима на карте:

public void paint (Graphics g) {

if (ApplicationStates.currentActivity == 1) {

Graphics2D g2 = (Graphics2D) g;

// Фон:

MainWindow.w.getContentPane().setBackground (Color.black);

// Временная переменная тайла:

Image tile;

// Рисуем карту

for (int i = 0; i < ApplicationStates.progressState.mapArray[0].length; i++) {

for (int j = 0; j < ApplicationStates.progressState.mapArray.length; j++) {

tile = Toolkit.getDefaultToolkit().getImage («assets\\map\\tile»+ (ApplicationStates.progressState.mapArray[i] [j] + 1) +».png»);

g2.drawImage (tile, GameConfig.tileSize * j + 3 * GameConfig.tileSize, GameConfig.tileSize * i + 1 * GameConfig.tileSize, this);

}

}

// Рисуем героя

Image img2 = Toolkit.getDefaultToolkit().getImage («assets\\map\\char.png»);

g2.drawImage (img2, ApplicationStates.progressState.characterPositionJ * GameConfig.tileSize + 3 * GameConfig.tileSize

ApplicationStates.progressState.characterPositionI * GameConfig.tileSize + 1 * GameConfig.tileSize, this);

// Инфо

g2.setPaint (Color.WHITE);

Font currentFont = g.getFont();

g.setFont (currentFont.deriveFont (currentFont.getSize() * 2F));

g2.drawString («Этаж:» + ApplicationStates.progressState.mapLevel + «Здоровье:» + ApplicationStates.progressState.currentHp

+ «Очки:» + ApplicationStates.progressState.sumPoints, 10, 30);

// перерисовываем

super.repaint();

}

}

Как мы можем видеть, используется строго заданная последовательность вывода графических элементов, ограничивающаяся условными операторами и заданными параметрами. Функция несколько раз в секунду перерисовывает картинку, что создает эффект динамики.

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

Главное меню (рисунок 4.4) содержит в себе пункты, которые можно переключать с помощью клавиатуры.

Рисунок 4.5. Главное меню программного продукта

Режим игры представляет собой случайно сгенерированную карту, на которой находятся игровые объекты, представленные тайлами. Противники изображаются условно - перекрещенными мечами. В верхней части экрана было решено сделать информационную строку с важными игровыми показателями. Управление осуществляется на стрелки клавиатуры. Выход - на клавишу Esc.

Рисунок 4.6. Режим путешествия

На рисунке 4.6 изображен скриншот боевого режима, на котором видны персонажи, изображенные поверх фонового рисунка. Персонаж противника (справа) использует заклинание, а персонаж игрока бездействует. Снизу видна панель управления, на которой отображены иконки умений. Здесь видно, что первые два умения (клавиши Q и W) недавно использовались и не готовы к повторному использованию. Под персонажами выводятся числа, обозначающие текущий запас здоровья.



Рисунок 4.7. Режим боя

На рисунке 4.7 изображены все варианты облика персонажей и иконок умений.

Рисунок 4.8. Некоторые ресурсы игры, используемые в режиме боя

Остальные экраны построены по одному принципу и включают в себя только отображение текстовой информации. Фон в них задан не изображением, а цветом на визуальном компоненте окна. Выход из них осуществляется на кнопку Esc.



Рисунок 4.9. Экран последних результатов

5. Реализация ПП

5.1 Особенности реализации системы

Одной из особенностей реализации данной системы является выбранный формат для сохранения JSON, являющийся довольно удобным и компактным средством хранения структурированной информации.

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

Сохраненная карта в формате JSON выглядит следующим образом:

[[1,1,1,1,1,2,1,1,1,1], [0,0,1,0,0,1,0,0,0,0], [0,0,1,0,0,1,0,0,0,0], [0,0,1,0,0,3,0,0,0,0], [0,0,1,0,0,3,0,0,0,0], [1,1,3,1,1,1,1,3,3,1], [0,0,1,0,0,1,0,0,0,0], [0,0,1,0,0,1,0,0,0,0], [0,0,3,0,0,3,0,0,0,0], [0,0,1,0,0,3,0,0,0,0]]

5.2 Политика безопасности

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

Использованы два фактора: относительно безопасный язык для пользовательских машин и XOR-шифрование, способное уберечь часть пользователей, не знакомых с криптографией и перехватом данных оперативной памяти, от нечестных действий, которые могут испортить впечатление от игры.

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

Рисунок 5.1. Текст зашифрованного файла

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

Рисунок 5.2. Схема трехуровневой архитектуры системы

6. Тестирование ПП

6.1 Обоснование методики тестирования

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

Метод черного ящика использует представление программы в качестве черного «ящика», системы, устройство которого неизвестно тестировщику. Цель тестирования - это определение обстоятельств, при которых программа ведет себя не так, как заявлено в спецификации. Чтобы обнаружить ошибки, необходимо проводить исчерпывающее тестирование на всех возможных данных. Так как на многих программах такое применить невохможно, используется «разумное» тестирование, когда набор данных ограничивается небольшим подмножеством. Выбираются подмножества с наиболее вероятным ошибочным исходом.

Модульное тестирование представляет собой написание тестов для нетривиальных функций или методов. Данный метод позволяет исключать крупные ошибки еще на этапе разработки. Цель модульного тестирования - демонстрация работоспособности отдельных программных модулей.

6.2 Результаты тестирования

В процессе разработки на разных этапах возникала необходимость тестирования различных методов. Для этого использовался вывод в командную строку при помощи метода «System.out.print()», позволяющего увидеть реальный результат выполнения программы. В качестве примера можно привести вывод строки в формате JSON. В тестируемый метод добавлялась данная конструкция, в которую передавалось значение переменной, хранящей текстовые данные. Таим образом было обнаружено некорректное формирование сериализованного объекта. Данные командной строки показали, что объект не сериализуется, хотя была уверенность в том, что ошибка в чтении или сохранении файла. После доработки была осуществлена передача объекта в json, однако, тестирование показало, что передавался лишь адрес объекта в памяти, что было тоже ошибочной работой программы.

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

После завершения разработки приложения было проведено тестирование методом черного ящика во время использования каждого состояния приложения.

В главном меню была проверена работоспособность всех пунктов, а также, возможность возврата к данному состоянию (на этапе разработки во время такого типа тестирования было обнаружено, что переключение между формами было некорректным и приводило к ситуациям, когда на окне выполнялись действия сразу для нескольких состояний). Было проверено и переключение пунктов меню.

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

В режиме путешествия тестировались возможные варианты перемещений и столкновений. Был обнаружен поставленный в неверном блоке инкремент, приводящий к перескакиванию через клетки.

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

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

На заключительном этапе были измерены затраты ресурсов компьютера и время использования. В задании было указано, что приложение должно быть кроссплатформенным, загружающимся не более 5 секунд и занимающим не более 128 мб оперативной памяти. Тестирование на операционных системах Windows 10 и Debian GNU/Linux показало, что загрузка занимает порядка одной секунды, а объем используемой оперативной памяти (в совокупности с использованием памяти виртуальной машиной Java) находится в диапазоне от 30 до 45 мегабайт.

7. Внедрение системы

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

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

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

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

8. Технико-экономические показатели проекта

В данном разделе учтены затраты на производство программного продукта, так как текущая версия ПО не предназначена для извлечения прибыли или рационализации каких-либо бизнес-процессов организаций или ИП.

Затраты на материальные активы, учтенные за время разработки ПО:

- Стол письменный, 1850 рублей;

Пассивные затраты:

- Месячная подписка на лицензионное использование программного продукта Photochop CC, 644 рублей;

- Электроэнергия за три месяца, 900 рублей;

- Оплата средств связи: 1740 рублей.

Итого: 5134 рубля.

Также, учтена амортизация материальных активов по линейной схеме, приобретенных ранее:

- Амортизация ноутбука, приобретенного в мае 2014 года: 24000 * 10% *0,083 = 200 рублей. Итого, 600 рублей за три месяца разработки;

- Амортизация монитора, приобретенного в сентябре 2015 года: 26000 * 10% *0,083 = 216,66 рублей. Итого, 649,98 рублей за три месяца разработки.

9. Раздел по экологии и безопасности жизнедеятельности

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

В этом разделе ВКР рассматриваются вопросы безопасности и экологии труда. Рабочее место разработчика должно быть оптимальным с точки зрения эргономики и норм, установленных нормативными документами.

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

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

На начальном этапе работы были выявлены такие вредные факторы, как недостаточная освещенность рабочего места в дневное время суток, недостаточная вентиляция и не эргономичное рабочее место. Для решения этой проблемы был приобретен письменный стол стандартных размеров с большой рабочей поверхностью. Рабочее место перенесено в более освещенное место рядом с окном.

Заключение

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

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

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

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

В заключении можно сказать, что цели ВКР достигнуты. Готовый программный продукт соответствует заданным исходным значениям и требованиям к системе. Таким образом, реализован программный продукт, который может выполнять поставленные задачи и служить основой для дальнейшей разработки в том же направлении.

Список использованных источников

1. Федеральное агентство по техническому регулированию и метрологии [Электронный ресурс]: офиц. сайт. - Режим доступа: http://standard.gost.ru:10040/wps/wcm/connect/d661e080413f5db8a4e9fe7ab9890bef/GOST_R_ISO_9241-210-2012.pdf? MOD=AJPERES

2. Компания «Oracle» [Электронный ресурс]: офиц. сайт. - Режим доступа: http://www.oracle.com/technetwork/java/javase/documentation/index.html.

3. Компания «Google» [Электронный ресурс]: офиц. сайт. - Режим доступа: https://sites.google.com/site/gson/gson-user-guide

4. Чмора А.Л. Современная прикладная криптография. 2-е изд. - М.: Гелиос АРВ, 2002.-256 с.:ил.

5. Эккель Б. Философия Java. Библиотека программиста. 4-е изд. - СПб.: Питер, 2009. - 640 с.

6. Благодатских В.А. Стандартизация разработки программных средств: учеб. пособие /В.А. Благодатских, В.А. Волнин, К.Ф. Поскакалов; под ред. О.С. Разумова. - М.: Финансы и статистика, 2006. - 288 с: ил.

Приложение 1

Листинг метода, реализующего генерацию нового игрового уровня

// Генерация

static void generate() {

for (int i = 0; i < GameConfig.mapSizeI; i++) {

for (int j = 0; j < GameConfig.mapSizeJ; j++) {

ApplicationStates.progressState.mapArray[i] [j] = 0;

}

}

// Генератор горизонтальных и вертикальных коридоров

ArrayList<Integer> list1 = new ArrayList<Integer>();

ArrayList<Integer> list2 = new ArrayList<Integer>();

int[][] startArray = new int[2] [(GameConfig.corridorCountI + GameConfig.corridorCountJ) * 2]; // массив концов коридоров

int z = 0; // счетчик массива

int corridorCounter = 0; // заполняем горизонтали

for (int i = 0; i < GameConfig.mapSizeI; i++) { // временный лист для извлечения

list1.add(i);

}

while (corridorCounter < GameConfig.corridorCountI) { // цикл по количеству коридоров

int nextCorridorLocation = list1.get (GameConfig.randomGenerator.nextInt (list1.size()));

for (int i = 0; i < list1.size(); i++) { // удаляем по индексу листа

if (list1.get(i) == nextCorridorLocation) {

list1.remove(i);

}

}

for (int i = 0; i < GameConfig.mapSizeJ; i++) {

ApplicationStates.progressState.mapArray[nextCorridorLocation] [i] = 1;

if (i == 0) {

startArray[0] [z] = nextCorridorLocation;

startArray[1] [z] = 0;

z++;

}

if (i == GameConfig.mapSizeJ-1) {

startArray[0] [z] = nextCorridorLocation;

startArray[1] [z] = GameConfig.mapSizeJ-1;

z++;

}

}

corridorCounter++;

}

corridorCounter = 0; // заполняем вертикали

for (int i = 0; i < GameConfig.mapSizeJ; i++) {

list2.add(i);

}

while (corridorCounter < GameConfig.corridorCountJ) { // цикл по количеству коридоров

int nextCorridorLocation = list2.get (GameConfig.randomGenerator.nextInt (list2.size()));

for (int i = 0; i < list2.size(); i++) { // удаляем по индексу листа, i оставить для следущего можно

if (list2.get(i) == nextCorridorLocation) {

list2.remove(i);

}

}

for (int i = 0; i < GameConfig.mapSizeI; i++) {

ApplicationStates.progressState.mapArray[i] [nextCorridorLocation] = 1;

if (i == 0) {

startArray[0] [z] = 0;

startArray[1] [z] = nextCorridorLocation;

z++;

}

if (i == GameConfig.mapSizeI-1) {

startArray[0] [z] = GameConfig.mapSizeI-1;

startArray[1] [z] = nextCorridorLocation;

z++;

}

}

corridorCounter++;

}

int tempRandStart = GameConfig.randomGenerator.nextInt((startArray[0].length)); // генерируем индекс координат старта в массиве startArray

ApplicationStates.progressState.characterPositionI = startArray[0] [tempRandStart];

ApplicationStates.progressState.characterPositionJ = startArray[1] [tempRandStart];

boolean flag = false;

int tempRandFinal = 0; // индекс координат конца в массиве startArray

while (! flag) {

tempRandFinal = GameConfig.randomGenerator.nextInt((startArray[0].length));

if (tempRandFinal!= tempRandStart) {

flag = true;

}

}

ApplicationStates.progressState.mapArray [startArray[0] [tempRandFinal]] [startArray[1] [tempRandFinal]] = 2;

int monsterCounter = 0; // заполняем монстрами (число)

boolean brakeFlag; // Для избежания лишних циклов, так как в теле может лишний раз пробежать из-за случайноси

while (monsterCounter < (GameConfig.corridorCountJ + GameConfig.corridorCountI) * GameConfig.enemyPerCorridor) {

for (int i = 0; i < GameConfig.mapSizeI; i++) {

brakeFlag = false;

for (int j = 0; j < GameConfig.mapSizeJ; j++) {

if (ApplicationStates.progressState.mapArray[i] [j] == 1) {

if (i!= ApplicationStates.progressState.characterPositionI && j!= ApplicationStates.progressState.characterPositionJ) {

if (GameConfig.randomGenerator.nextInt((GameConfig.mapSizeI * GameConfig.corridorCountI + GameConfig.mapSizeJ * GameConfig.corridorCountJ)

- (GameConfig.corridorCountI * GameConfig.corridorCountJ)) == 1) {

ApplicationStates.progressState.mapArray[i] [j] = 3;

monsterCounter++;

brakeFlag =! brakeFlag;

}

}

}

}

if (brakeFlag == true) { // выходим из цикла

break;

}

}

}

}

Приложение 2

Листинг метода, реализующего действие умений персонажей

public void skillExecute() {

if ((! currentCoolDown &&! GameBattle.blockStatePlayer) &&! GameBattle.castStatePlayer) {

new Thread(() -> {

try {

GameBattle.castStatePlayer = true;

Thread.sleep(castTime);

GameBattle.castStatePlayer = false;

if (heal > 0) {

if (ApplicationStates.progressState.currentHp + heal >= GameConfig.maxHp) {

ApplicationStates.progressState.currentHp = GameConfig.maxHp;

} else {

ApplicationStates.progressState.currentHp = ApplicationStates.progressState.currentHp + heal;

}

new Thread(() -> {

try {

GameBattle.healEffectPlayer = true;

Thread.sleep(300);

GameBattle.healEffectPlayer = false;

} catch (InterruptedException e) {

e.printStackTrace();

}

}).start();

}

if (damage > 0) {

if (! GameBattle.blockStateEnemy || penetration) {

GameBattle.enemy.currentHp = GameBattle.enemy.currentHp - damage

+ GameConfig.randomGenerator.nextInt((int) Math.round (damage * 0.1 + 1)) - (int) Math.round (damage * 0.1 / 2);

new Thread(() -> {

try {

GameBattle.damageEffectPlayer = true;

Thread.sleep(200);

GameBattle.damageEffectPlayer = false;

} catch (InterruptedException e) {

e.printStackTrace();

}

}).start();

if (GameBattle.enemy.currentHp <= 0) {

ProgressState.sumPoints = ProgressState.sumPoints + 15 * ProgressState.mapLevel;

ApplicationStates.currentActivity = 1;

try {

ProgressMethods.saveLast();

} catch (IOException e) {

e.printStackTrace();

}

}

}

}

if (GameBattle.reflectStateEnemy) {

ApplicationStates.progressState.currentHp = ApplicationStates.progressState.currentHp - GameBattle.reflectPowerStateEnemy

+ GameConfig.randomGenerator.nextInt((int) Math.round (GameBattle.reflectPowerStateEnemy * 0.2 + 1)) - (int) Math.round (GameBattle.reflectPowerStateEnemy * 0.2 / 2);

if (ApplicationStates.progressState.currentHp <= 0) {

ApplicationStates.currentActivity = 3;

MainWindow.execute();

}

}

} catch (InterruptedException e) {

e.printStackTrace();

}

}).start();

if (reflectTime > 0) {

new Thread(() -> {

try {

Thread.sleep(timeToReflect);

GameBattle.reflectStatePlayer = true;

GameBattle.reflectPowerStatePlayer = reflectDamage;

Thread.sleep(reflectTime);

GameBattle.reflectStatePlayer = false;

GameBattle.reflectPowerStatePlayer = 0;

} catch (InterruptedException e) {

e.printStackTrace();

}

}).start();

}

if (blockTime > 0) {

new Thread(() -> {

try {

GameBattle.blockStatePlayer = true;

Thread.sleep(blockTime);

GameBattle.blockStatePlayer = false;

} catch (InterruptedException e) {

e.printStackTrace();

}

}).start();

}

currentCoolDown = true;

new Thread(() -> {

try {

Thread.sleep(coolDown);

currentCoolDown = false;

} catch (InterruptedException e) {

e.printStackTrace();

}

}).start();

}

}

Размещено на Allbest.ru