суббота, 2 марта 2019 г.

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

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


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

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

    self.offset += 1

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




четверг, 7 февраля 2019 г.

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

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






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

воскресенье, 3 февраля 2019 г.

Заинтересовался 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
 

воскресенье, 19 августа 2018 г.

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

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


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

вторник, 14 августа 2018 г.

IDDQD

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

воскресенье, 12 августа 2018 г.

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

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


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


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

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

воскресенье, 1 июля 2018 г.

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

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