День 65

Сегодня занимался пиксель-артом, как и хотел. Думал взять размер 128х128 для логотипа - но я тупо потерялся в этом кол-ве пикселей, взял 64х64 и все равно было очень сложно, но я.. не смог. Ну да, вообще не получилось даже колодец сделать. Работать с артом более 32х32 размером уже гипер сложно, так что не буду пока что прям упарываться в ту идею, что сейчас есть (колодец с солнцем и ник под ним), а, вероятно, сделаю лого размером 32х32 или же вообще пока что забью на это и буду продолжать делать игру. Но тот огрызок-недоделок колодца прикреплю к посту, что уж тут

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

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

Завтра (сегодня) начну работу над новым врагом и продолжу смотреть курс - на повестке дня увеличение сложности с течением времени и всякие микро улучшения

#pixelart #godot #ritkarampage #разработка

День 70

Сегодня разработка пошла прям очень хорошо, добавил в игру дикобраза, сделал ему логику атаки и передвижения, но перед этим доделав его страничку у себя в "дизайн-документе" (скрин прикреплю кстати)

Сейчас дикобраз двигается следующим образом - он преследует персонажа, пока не будет рядом с ним, после этого начинается чередование атака — блуждание. Каждые 2 секунды дикобраз атакует, если персонаж в зоне досягаемости, а в перерывах между атакой он блуждает туда-сюда (очень классно получилось, мне прям нравится) и каждые 0.6 секунд меняет своё направление. Иногда даже кажется, что дикобраз убегает от персонажа 😅

Кстати я сейчас подумал над этим - может реально сделать чтобы дикобраз убегал от персонажа, когда Ритка слишком близко приближается к нему 🤔

Завтра потестирую этот вариант, возможно будет даже прикольнее чем сейчас. Будет это работать следующим образом - если дикобраз находится на расстоянии 150 условных единиц (у.е.) и меньше к персонажу - то чередует атаку и брождение туда-сюда, а если дистанция становится менее 50 у.е. - то дикобраз начинает двигаться в противоположную сторону от Ритки с увеличенной скоростью (типа убегает). А чтобы избежать дёрганий в движении когда будет 49-51 расстояние я добавлю задержку перед изменением направления и будет четко вообще

И к мысли про убегающего дикобраза - может ему имя поменять? Например на "Пугливый Дикобраз" / "Timid Porcupine". А то сейчас его имя какое-то слишком обычное что-ли ("Дикобраз Иглострел" / "Quill-Shot Porcupine")

С именами врагов я что-то придумаю точно, как минимум добавлю что-то типа бестиария, в котором будет показано сколько было убито тех или иных врагов, немного описания про врага и все такое, уверен будет полезно такое внедрить

Мне прям понравилось разрабатывать сейчас это все, так что завтра (сегодня, в воскресенье) я доделаю полностью дикобраза и приступлю к Упрямой Корове

#ritkarampage #godot #разработка

День 71

Сегодня полностью доделал врага-дикобраза, теперь он стреляет от 1 до 3 игл с разбросом в 30 градусов в направлении игрока, а также убегает с увеличенной скоростью, когда Ритка слишком близко подходит. Под лапками у дикобраза во время "убегания" еще что-то типа пыли добавил, выглядит очень забавно 😅

Больше всего времени заняла разработка разброса для игл. Я хотел полностью сам все сделать и разобраться, а только потом уже гуглить готовое решение, поэтому долго тупил, зато теперь знаю, что в Godot все на радианах, а не на градусах.. знал бы я раньше, сэкономил бы пол часика как минимум точно 😢

Я даже чет рисовал чтобы визуализировать это все дело, ну оно даже помогло

Еще иглы уменьшают свою скорость по мере "летения" вплоть до половины изначально скорости, это прям добавило динамичности, а то если иглы с одной скоростью летели бы, то это было бы слишком топорно

Вот кстати моё решение для разброса игл:

var direction_to_player: Vector2 = global_position.direction_to(player.global_position) # получаем нормализованный вектор направления к игроку, т.е. значения тут всегда от -1 до 1, но длинна равна 1
  
  for index in quill_count:
    var quill = quill_scene.instantiate() as Node2D
    
    var cone_from: Vector2 = direction_to_player.rotated(deg_to_rad(30)) # определяем первую границу конуса
    var cone_to: Vector2 = direction_to_player.rotated(deg_to_rad(-30)) # определяем вторую границу конуса
    var cone_random_point = Vector2(
      randf_range(cone_from.x, cone_to.x), # выбираем случайную точку по "X"
      randf_range(cone_from.y, cone_to.y), # выбираем случайную точку по "Y"
    )
    
    quill.rotation = cone_random_point.angle() # тут задаём вращение, т.е. в какую сторону полетит игла (в радианах)

И решение с интернета (намного лаконичнее и лучше):

var direction_to_player: Vector2 = global_position.direction_to(player.global_position)
  
  for index in quill_count:
    for index in quill_count:
    var quill = quill_scene.instantiate() as Node2D
    
    var random_angle = deg_to_rad(randf_range(30, -30))
    var random_direction = direction_to_player.rotated(random_angle)
    
    quill.rotation = random_direction.angle()

#ritkarampage #godot #разработка

День 78

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

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

Есть враг Дикобраз-Иглострел и, фактически, его спрайт занимает около 16х16 пикселей, но та анимация с иглами требует места, поэтому я расширил спрайт до 32х32px, а Дикобраз остался в углу, поэтому если просто этому спрайту задавать "flip_h" (отразить по горизнотали) - то дикобраз перемещается с одного угла в другой - поэтому мне нужно было вместо с поворотом спрайта еще менять ему позицию, что казалось диким костылём (так и есть)

И, вчера, когда я смотрел как препод анимирует персонажа и врагов, он (препод) показал как отражать по горизонтали правильно - создавать родительский контейнер Node2D, пихать в этот контейнер спрайты и всякую визуальщину, которая привязана к объекту, а потом просто менять Scale (масштабирование) на -1 и спрайты тоже отражатся, но стоя на месте.. что нереально удобно. Конечно мне кажется что нет "серебряной пули" и это выглядит как слишком идеальное решение, так что спросил у сообщества (кстати это пример очень хорошо составленного вопроса, можете брать на заметку) и посмотрю, что они скажут насчет этого (P.S. ответ получен, все четко, так можно делать если только нода отвечает за визуал)

Прикрепил видео с моей реакцией, объяснением и фиксом к посту

Еще я задал пару вопросов преподавателю (довольно часто задаю вопросы и получаю очень полезные ответы), прикреплю скрины вопросов к посту тоже

Один с вопросов - "Как правильно проверять наличие постоянных улучшений?", т.к. у меня есть улучшение, которое меняет поведение скрипта, а не просто с циферками балуется, то мне нужно каждый раз проверять: "а есть ли улучшение? Ага, есть, тогда делаем так", и сейчас оно выглядит как-то очень-не-очень, каждый раз прописывать mutations.has("some_mutation_id") - ну такое, но если даже сделать какой-то флаг типа var has_run_upgrade: bool и его обновлять когда улучшение было выбрана - это классно, но если мутаций будет довольно много, то очень быстро все превратится в бардак, так что интересно что ответит преподаватель

Второй вопрос про пример кода стейт-машины на GDScript от преподавателя, я видел у него код на C#, но есть определённые трудности в переносе на GDScript, так что тоже жду ответа с нетерпением, а то просто на енамах далеко не уедешь

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

Кстати вот ссылка на репозиторий с игрой, может кому будет интересно/полезно глянуть - https://github.com/Sundwell/ritka-rampage

#godot #ritkarampage #разработка