Решил сделать турельку в изометрии.

Собственно вот результат, он же КДПВ:

Создание 3D шутера для Android #4 | Godot Engine 3 2 | Настройка сцены, ...

Пользователь ScanerSoft создал очередной видеоурок, кому интересен движок Godot, переходите, там много полезной информации.

Сигналы.

   Итак, разобрался с подключением/отключением сигналов, как и хотел. Оказалось просто. 

Сделал в догонку пример полосы здоровья с помощью узла ColorRect.

   Собственно, самый цимес этого примера - в принципе
 расчета цвета для  полосы здоровья. Суть в том, что изменение цвета из красного в зеленый, через желтый, требует изменения только двух каналов - R и G. Синий при этом лучше вообще выкрутить в ноль и не трогать. Если подробнее, то  градиент выглядит так:
Красный - 1.0, 0.0, 0.0
Желтый - 1.0, 1.0, 0.0
Зеленый - 0.0, 1.0, 0.0
Видно, что первую половину градиента красный остается неизменно равным 1.0, а вторую половину уменьшается до нуля, зеленый же наоборот в первую половину увеличивается до 1.0, а вторую половину остается неизменным. Код, который создает список цветов:

var colorList = []

for i in range(101):
        var R = 0.0
        var G = 0.0
        var B = 0.0
       
        if i > 50:
            R = (100 - i)*0.02
            G = 1.0
        if i < 51:
            R = 1.0
            G = i * 0.02
        colorList.append(Color(R, G, B))

КДПВ:

Сделал стреляющую турельку.

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

Скачать здесь: Turret.7z

Таки добил движение юнитов как в стратегиях...

    Хотя уже в процессе пришло понимание, что неплохо бы вообще весь код, отвечающий за отдачу команд, в том числе юнитам,  упаковать в отдельный узел, вроде как интерфейс отдельно, мухи сцены/юниты отдельно.
    Еще неплохо было бы отправлять юниту не просто координаты точки, куда ему двигаться надо, а приказ, например {'MOVE', Vector2(128.0, 54.0)} или {'ATTACK', 'KinematicBody2D: 1016'} и прочее, типа 'GUARD', 'RETURN_TO_BASE', MOVE_AND_ATTACK', на что фантазии хватит.
    Замечу так же, что блок - схемы рулят. Если бы не они, то я еще полгода бы размышлял, как бы это получше организовать.

   КДПВ из предыдущего сообщения, в этом смысле существенно ничего не поменялось.

Управление понятно какое, плюс клавиша Shift работает.

Собственно ссылка: Move_TO_ClickII.7z (~400 kB)

Перерисовал текстуры.

   Сочетание цветов мне всё равно не нравится, но смысла долго возиться с подгонкой я не вижу. Картинка ниже:

Переделал спрайт юнита.

   Поскольку даже мне предыдущая версия резала глаз. Собственно, результат целого дня возни:

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

Сделал управление юнитом почти как в стратегиях.

   Почему почти? Потому что без выделения рамкой. Хотя оно там есть, но мне пока не нравится как работает, надо допиливать.

Оказывается в Godot уже встроено простое движение по пути.

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

    Код движения для жука тоже прост до неприличия:

func _process(delta):
#    # Called every frame. Delta is time since last frame.
#    # Update game logic here.
    self.offset += 1

Ноу комментс, как говорится...

Опять часы, но уже на BGE.

   Решил проверить, как получиться сделать часы в BGE. Однако хлопотнее оказалось.

Пришлось для поворота стрелок возиться с матрицами ориентации и поворота. Хотя можно было и анимацией обойтись...

Clock.7z (~66 kB)

Заинтересовался Godot.

   Скачал на предмет посмотреть - пощупать. Что можно сказать - 3D я пока особо не трогал, все же изучать лучше начинать с простого, тем более что в самоучителе на их сайте показывают работу на примере двухмерных игр. Что подкупает - встроенный прямо в редактор справочник по API и готовые элементы управления, вроде кнопок и прогресс баров. Ну и конечно Питон-подобный язык скриптов под названием GDScript. Отличия конечно есть, но по большей части то же самое. Если интересно, то можно зайти в ютубе на канал ScanerSoft, там есть хорошего качества уроки и довольно подробные. Ссылка, если что.
  
В общем, поигравшись с Godot, и немножко с ним разобравшись, решил вспомнить молодость и сделать приложение - часы. Давным-давно, когда я только начинал вникать в азы программирования, я делал свой аналог виджета часов на рабочий стол еще на VisualBasic 6.0. Или уже на VB.Net? Не помню. НО помню, что возился тогда долго, знаний не было, спросить тоже было не у кого. Вот, решил сейчас повторить подвиг, скачал текстуры циферблата и стрелок и за пару часов сделал. Картинка:

 

Скопипастю код функции, управляющей движением стрелок:

 

func _process(delta):

    var currTime = OS.get_time()
   
    var currSecond = currTime['second']
    var secondHand = self.get_node("Second_hand")
    secondHand.rotation_degrees = currSecond * 6
   
    var currMinute = currTime['minute']
    var minuteHand = self.get_node("Minute_hand")
    minuteHand.rotation_degrees = currMinute * 6 + currSecond * 0.1
   
   
    var currHour = 0
    if currTime['hour'] >= 12:
        currHour = currTime['hour'] - 12
    else:
        currHour = currTime['hour']
    var hourHand = self.get_node("Hour_hand")
    hourHand.rotation_degrees = currHour * 30 + currMinute * 0.5
 

Пример использования поля зрения камеры.

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

cameraAngle.blend.7z (~60 kB)

Управление: WSAD, колесо мыши.

IDDQD

    Сделал еще один маленький пример, на этот раз вроде даже понятно, зачем такое нужно, в отличии от предыдущего, про который я до сих пор понять не могу, нафига я его делал. Как понятно из названия, пример читов, точнее изменения какого-либо проперти в зависимости от последовательности нажатых клавиш. Как оно работает: у объекта, должного реагировать на читы, есть строка, в конец которой при нажатии на клавишу добавляется буква, соответствующая нажатой клавише, то есть, нажали "W", значит добавляется "W". А дальше идет поиск вхождения имени специального проперти в эту строку, правда специальность эта отмечена символом, указывающим тип проперти, которое при поиске вхождения опускается. Объясняю, имя проперти-читов начинается с "_" или "$", например _IDDT или &MONEY. Первое булевое и при обнаружение последовательности "IDDT" значение проперти "_IDDT" будет изменено на TRUE. Практически так же будет вести себя и $MONEY, с той лишь разницей, что к её значению будет добавлено +100. Ну и после обнаружения последовательности строка нажатых клавиш создается заново , чтобы избежать повторного срабатывания чита. Ниже КДПВ, код и ссылка на пример:

Еще один пример. На этот раз ограничения камеры.

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

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

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

cameraRestriction.blend.7z (~65 kB)

   Управление - WSAD, колесо мыши.

Поиск пути в ширину.

    Однако как-то прошел мимо меня алгоритм поиска пути в ширину, как бы знал о нем, но совершенно не интересовался, есть такой и ладно. А вот на днях заинтересовался, оказывается незаменимая вещь для игр жанра Tower Defense или даже для шутеров, везде где враги должны набегать на одинокую цель, или небольшое количество целей. И главное - простая. Причем, в силу своей простоты исполняется один раз, а дальше результатами может пользоваться куча юнитов, во всяком случае, пока цель не сдвинется с места. А ведь делал что-то подобное - генератор регионов для навигационных карт и даже не сообразил, вот что значит лень и отсутствие специализированного образования.

Фейковое освещение в БГЕ.

    Опять долго не писал, причина - перефразируя шутку из КВН - "беспробудное пьянство победило природную лень". И даже не буду обещать писать часто, хотя бы потому что BGE вроде как того... заменяется другим движком, который Armory3d - лично для меня довольно - таки демотивирующая новость, потому что для перехода на этот движок мне надо новый комп покупать, а я еще BGE толком не изучил. В общем одно не слишком стабильное изделие заменяется на другое, тоже не слишком стабильное. Мимо UPBGE я так же пролетаю, по той же причине. "О, на этом месте мы горько плачем и не можем писать в рифму!.."(с)

Балуюсь с туманом войны.

   Давным - давно, в одной очень далекой гала... еще на БУ обсуждался вопрос создания эффекта тумана войны с помощью кучи расставленных плейнов, которые бы перекрывали собой обзор из камеры в собственных координатах. И становились бы невидимыми, когда их сенсор показал бы приближение юнита, принадлежащего игроку. Тогда дело не пошло, потому что этих самых плейнов надо было очень много, чтобы перекрыть всю карту, я уже молчу о обработке сигналов сенсоров. А я тогда только - только изучать БГЕ и Питон начал, так что не сообразил, что  камера небольшое количество плейнов с собой таскать может по карте всей, остается только вычислить координату частицы тумана на карте и из списка этой координате извлечь значение видимости. Дальше уже дело техники. Вот мне это недавно в голову и пришло. Как говориться, лучше поздно, чем никогда... Ниже КДПВ и ссылка на черновик. Там еще пилить надо, но для понимания принципа оно уже вполне пригодно к употреблению.

Баловался с материалом HALO в интернале.

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

Хм...

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