Сигналы.

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

Сделал в догонку пример полосы здоровья с помощью узла 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)

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

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

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

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

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

Clock.7z (~66 kB)

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

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

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 я так же пролетаю, по той же причине. "О, на этом месте мы горько плачем и не можем писать в рифму!.."(с)

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

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

Снова здравствуйте...

И вот я снова дома. Вроде отоспался, выпил беларуской водки, поел нашего хлеба с нашей же колбасой, вкусно... Включил комп, и стал вспоминать, где какая клавиша для чего в Блендере нужна, а самый лучший способ вспомнить — что-нибудь сделать. Решил сделать пример полосы загрузки уровня и расстановки объектов, благо об этом когда-то просили, понимаю что давно это было, но лучше поздно, чем никогда. Ну и чтобы тупо не дублировать пост типа «вот скачайте пример, кому надо» попробую расписать работу примера поподробнее. Тем более, что склероз не дремлет, могу и сам забыть. Да, версия Блендера в примере 2.78а, более поздние у меня не идут, надо обновления на мой Линь поставить, но мне лень. Да и интернет у меня не сказать, что хорошего качества и не дешевый. Из-за качества интернета и общего устаревания системы этот пост решил набрать в LibreOffice, а потом просто скопипастить текст, чтобы избежать постоянных предпросмотров в самом Блоггере, тоже эксперимент получается.

Не прошло и года, как я написал следующий пост.

    Ситуация такая получилась - комп у меня стационарный, а я сам почти всё прошедшее время в прямом смысле слова дома не был, вот на Новый год только домой приехал. А в телефоне я запустить Блендер не могу. Чистый же Питон сам по себе как-то не интересен, короче не получилось и не знаю как оно дальше будет продолжаться, вполне может статься, что опять год меня не будет. Хотелось бы летом дома побыть, но не уверен, что получится. Посмотрим.

Сделал пример полосы загрузки.

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

Падал прошлогодний снег.

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

Кому интересно, можете скачать, 655 kB:
snow.blend.zip

Управление- просто запустить, если хотите поиграть с количеством снежинок, то просто удаляйте, копируйте их в режиме редактирования.

Покамест замораживаю.

    Может быть, если пойму, в чем проблема со столкновениями, переделаю. А пока добавил пару параметров в систему частиц, плюс анимации и кривые теперь имеют более осмысленные имена, ну и перепаковал архив в .zip. Циклов стало больше, толку правда чуть.

Вершины в словаре.

    Время доступа по ключу к записанному в словаре значению величина постоянная и не зависит от размера словаря. Казалось бы, что сразу не сообразить, закидывать в словарь всякое разное? А вот поди же... Сообразил, что если вершины меша записать в словарь, то для изменения каких-то характеристик конкретной вершины не надо перебирать их всех циклом, а просто вызвать по ключу.
   Ключи в словарях это нечто невероятно удобное. Достаточно сказать, что они могут быть разных типов. Как вам понравится идея использования в качестве ключа например числа типа float? Или экземпляр собственноручно написанного класса? А ведь можно. Потому что всё есть объект.
    Вот, сообразив всё вышеописанное, соорудил даже не пример, нет, это скорее альфа - прототип ландшафта, в котором рельеф задается изменением z-координаты вершин меша. Оно еще весьма корявое, но если кому интересно:

SculptLand.blend.7z (108 kB)

Оформил пример меню со сменой картинок.

Скачать здесь. scrollPicMenu.7z ~70 kB

Склепал маленький пример.

    Меню с как бы перебором картинок. Пока не оформлено, в примеры выкладывать не буду.

scrollPicMenu.7z (70 kB)