День 78
Вчера.. почему часто вчера? К сожалению (на самом деле к огромному счастью) я работаю, подрабатываю и учусь, поэтому очень часто (последнее время практически всегда), я заканчиваю учится именно уже ближе к ночи или даже ночью, подготавливаю все скриншоты и видео для поста, а вот сам пост писать уже сил вообще нет и, поэтому, к написанию поста я возвращаюсь уже на следующий день, когда освобождаюсь от работы и остальных бытовых дел, обычно это снова вечер-ночь🥲
В общем - вчера в игру я добавил.. фикс моего легендарного костыля про поворот "нестандартных" спрайтов, о котором я забыл рассказать
Есть враг Дикобраз-Иглострел и, фактически, его спрайт занимает около 16х16 пикселей, но та анимация с иглами требует места, поэтому я расширил спрайт до 32х32px, а Дикобраз остался в углу, поэтому если просто этому спрайту задавать "flip_h" (отразить по горизнотали) - то дикобраз перемещается с одного угла в другой - поэтому мне нужно было вместо с поворотом спрайта еще менять ему позицию, что казалось диким костылём (так и есть)
И, вчера, когда я смотрел как препод анимирует персонажа и врагов, он (препод) показал как отражать по горизонтали правильно - создавать родительский контейнер Node2D, пихать в этот контейнер спрайты и всякую визуальщину, которая привязана к объекту, а потом просто менять Scale (масштабирование) на -1 и спрайты тоже отражатся, но стоя на месте.. что нереально удобно. Конечно мне кажется что нет "серебряной пули" и это выглядит как слишком идеальное решение, так что спросил у сообщества (кстати это пример очень хорошо составленного вопроса, можете брать на заметку) и посмотрю, что они скажут насчет этого (P.S. ответ получен, все четко, так можно делать если только нода отвечает за визуал)
Прикрепил видео с моей реакцией, объяснением и фиксом к посту
Еще я задал пару вопросов преподавателю (довольно часто задаю вопросы и получаю очень полезные ответы), прикреплю скрины вопросов к посту тоже
Один с вопросов - "Как правильно проверять наличие постоянных улучшений?", т.к. у меня есть улучшение, которое меняет поведение скрипта, а не просто с циферками балуется, то мне нужно каждый раз проверять: "а есть ли улучшение? Ага, есть, тогда делаем так", и сейчас оно выглядит как-то очень-не-очень, каждый раз прописывать
Второй вопрос про пример кода стейт-машины на GDScript от преподавателя, я видел у него код на C#, но есть определённые трудности в переносе на GDScript, так что тоже жду ответа с нетерпением, а то просто на енамах далеко не уедешь
В первой игре я делал стейт машину отдельными нодами, как в этом видео, и мне казалось это очень удобным, но сейчас.. создание ноды на каждое состояние.. даже небольшое? Ну не знаю. Препод делал это все в скрипте игрока, и это вообще не было никак не нагроможденно, а все чистенько-аккуратненько
Кстати вот ссылка на репозиторий с игрой, может кому будет интересно/полезно глянуть - https://github.com/Sundwell/ritka-rampage
#godot #ritkarampage #разработка
Вчера.. почему часто вчера? К сожалению (на самом деле к огромному счастью) я работаю, подрабатываю и учусь, поэтому очень часто (последнее время практически всегда), я заканчиваю учится именно уже ближе к ночи или даже ночью, подготавливаю все скриншоты и видео для поста, а вот сам пост писать уже сил вообще нет и, поэтому, к написанию поста я возвращаюсь уже на следующий день, когда освобождаюсь от работы и остальных бытовых дел, обычно это снова вечер-ночь
В общем - вчера в игру я добавил.. фикс моего легендарного костыля про поворот "нестандартных" спрайтов, о котором я забыл рассказать
Есть враг Дикобраз-Иглострел и, фактически, его спрайт занимает около 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 #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
День 79
Наконец-то теперь у меня есть идеальный (для меня) вариант создания и использования стейт-машины, я прям преисполнен радостью, от души отлегло💃
Вчера получил ответы на свои вопросы от автора курса (я очень доволен тем, что он не только вообще отвечает, так еще и быстро это делает)
На первый вопрос "Как правильно проверять наличие постоянных улучшений" он ответил, что он бы делал так же, как и я (ого) и посоветовал как можно улучшить, я так и сделал
На второй вопрос про стейт-машину он дал ссылку на свою имплементацию стейт-машины и пример использования, и я побежал сразу разбираться и внедрять это в скрипт игрока🐸
Теперь мне ну очень хочется сделать видео про стейт-машину и как её можно реализовать, объяснить что к чему и как работает и чем этот подход лучше и хуже других (как по мне - идеальный подход 👀)
Я вообще люблю делиться знаниями и помогать другим в обучении, уже на протяжении 3х лет я так или иначе кого-то обучаю, менторю и подобное
Я выделяю как минимум три причины, из-за которых в основном преподают практикующие специалисты:
Деньги
Можно много получать если менторишь уже серьёзных спецов и помогаешь им развиваться дальше, но это не обо мне, с моими пятью годами опыта в веб-разработке я конечно стал специалистом какого-то уровня, но сейчас я и сам тот человек, которому нужен ментор (был бы нужен). Еще можно в школах айтишных преподавать, но это вообще не деньги в сравнении с обычной работой
Найм/Хантинг
При обучении людей в тех же школах айтишных можно найти людей с потенциалом и горящими глазами и таких забирают преподаватели к себе в компанию (команду) и выращивают специалиста, очень классный подход, хоть и рискованный немного
Желание.. помогать?
Не знаю как эту причину описать, но я постараюсь
У меня в начале пути было столько проблем, столько страхов, глаза разбегались что учить? Зачем учить? Где это пригодится? Где то пригодится? А надо ли вообще это учить и.. как это использовать? А не трачу ли я свое время зря? А получится ли у меня?
И мне почему-то нравится делиться своими знаниями с другими, конечно же это взаимовыгодно - когда кому-то рассказываешь что-то, то ты обязан подготовится ко всем возможным вопросам, разобраться в теме глубже, чем обычно, таким образом я укрепляю и улучшаю свои знания, а условный "ученик" получает ответы на вопросы и какое-то направление, а не просто непроглядную тьму, ведь я уже это все проходил, я знаю что будет дальше и как к этому прийти
В моём случае мною движет желание помогать, это не такая уж и редкая причина, впрочем как и остальные две, в любом случае это не альтруизм, ведь я выгоду тоже получаю
Вернемся к разработке - сейчас занимаюсь переписыванием скрипта врагов на стейт-машины, чтобы структурировать код еще больше - обожаю порядок (только не в своей комнате, тут тихий ужас)
Прикреплю скриншоты ответов от преподавателя и код ДО и ПОСЛЕ рефакторинга моего скрипта для игрока
#godot #ritkarampage #разработка
Наконец-то теперь у меня есть идеальный (для меня) вариант создания и использования стейт-машины, я прям преисполнен радостью, от души отлегло
Вчера получил ответы на свои вопросы от автора курса (я очень доволен тем, что он не только вообще отвечает, так еще и быстро это делает)
На первый вопрос "Как правильно проверять наличие постоянных улучшений" он ответил, что он бы делал так же, как и я (ого) и посоветовал как можно улучшить, я так и сделал
На второй вопрос про стейт-машину он дал ссылку на свою имплементацию стейт-машины и пример использования, и я побежал сразу разбираться и внедрять это в скрипт игрока
Теперь мне ну очень хочется сделать видео про стейт-машину и как её можно реализовать, объяснить что к чему и как работает и чем этот подход лучше и хуже других (как по мне - идеальный подход 👀)
Я вообще люблю делиться знаниями и помогать другим в обучении, уже на протяжении 3х лет я так или иначе кого-то обучаю, менторю и подобное
Я выделяю как минимум три причины, из-за которых в основном преподают практикующие специалисты:
Деньги
Можно много получать если менторишь уже серьёзных спецов и помогаешь им развиваться дальше, но это не обо мне, с моими пятью годами опыта в веб-разработке я конечно стал специалистом какого-то уровня, но сейчас я и сам тот человек, которому нужен ментор (был бы нужен). Еще можно в школах айтишных преподавать, но это вообще не деньги в сравнении с обычной работой
Найм/Хантинг
При обучении людей в тех же школах айтишных можно найти людей с потенциалом и горящими глазами и таких забирают преподаватели к себе в компанию (команду) и выращивают специалиста, очень классный подход, хоть и рискованный немного
Желание.. помогать?
Не знаю как эту причину описать, но я постараюсь
У меня в начале пути было столько проблем, столько страхов, глаза разбегались что учить? Зачем учить? Где это пригодится? Где то пригодится? А надо ли вообще это учить и.. как это использовать? А не трачу ли я свое время зря? А получится ли у меня?
И мне почему-то нравится делиться своими знаниями с другими, конечно же это взаимовыгодно - когда кому-то рассказываешь что-то, то ты обязан подготовится ко всем возможным вопросам, разобраться в теме глубже, чем обычно, таким образом я укрепляю и улучшаю свои знания, а условный "ученик" получает ответы на вопросы и какое-то направление, а не просто непроглядную тьму, ведь я уже это все проходил, я знаю что будет дальше и как к этому прийти
В моём случае мною движет желание помогать, это не такая уж и редкая причина, впрочем как и остальные две, в любом случае это не альтруизм, ведь я выгоду тоже получаю
Вернемся к разработке - сейчас занимаюсь переписыванием скрипта врагов на стейт-машины, чтобы структурировать код еще больше - обожаю порядок (только не в своей комнате, тут тихий ужас)
Прикреплю скриншоты ответов от преподавателя и код ДО и ПОСЛЕ рефакторинга моего скрипта для игрока
player.gd#godot #ritkarampage #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1
День 80
Вчера мало вышло времени выделить на разработку, так что успел только переписать скрипты врагов с помощью нового подхода со стейт-машиной
Сейчас прохожу все так дальше часть курса с анимациями, и тут разобрали немного партиклы (визуальные эффекты), препод делает анимацию смерти с помощью партикла - когда враг умирает, то он как бы прыгает вверх в случайную сторону, крутится от -720 до 720 градусов (случайное вращение в пределах этих двух чисел) и потом падает и уменьшается и все это сделано тоже компонентом, чтобы для каждого врага не делать одинаковое, довольно прикольно вышло
А я скорее всего сделаю так, чтобы при смерти любого врага и персонажа тоже проигрывался кадр смерти (для Ритки это будет анимация + замедление времени) и чтобы лужа крови появлялась изпод врага и во время этой смерти будет вылетать полупрозрачная душа этого врага, типа снизу такой хвост как у привидения, сверху часть тела врага и лапы/руки скрещены на груди или же сложены вместе типа молитвы, а сверху нимб над головой, и эта душа будет улетать вверх, становиться все более прозрачной и во время полёта будет двигаться влево-вправо 😅
Мило и жестоко одновременно, как раз в тему для игры
Сейчас же это все доделываю, а завтра уже наконец-то добавлю случайный спавн разных врагов (вес к врагам добавлю и улучшу EnemyManager)
#godot #ritkarampage #разработка
Вчера мало вышло времени выделить на разработку, так что успел только переписать скрипты врагов с помощью нового подхода со стейт-машиной
Сейчас прохожу все так дальше часть курса с анимациями, и тут разобрали немного партиклы (визуальные эффекты), препод делает анимацию смерти с помощью партикла - когда враг умирает, то он как бы прыгает вверх в случайную сторону, крутится от -720 до 720 градусов (случайное вращение в пределах этих двух чисел) и потом падает и уменьшается и все это сделано тоже компонентом, чтобы для каждого врага не делать одинаковое, довольно прикольно вышло
А я скорее всего сделаю так, чтобы при смерти любого врага и персонажа тоже проигрывался кадр смерти (для Ритки это будет анимация + замедление времени) и чтобы лужа крови появлялась изпод врага и во время этой смерти будет вылетать полупрозрачная душа этого врага, типа снизу такой хвост как у привидения, сверху часть тела врага и лапы/руки скрещены на груди или же сложены вместе типа молитвы, а сверху нимб над головой, и эта душа будет улетать вверх, становиться все более прозрачной и во время полёта будет двигаться влево-вправо 😅
Мило и жестоко одновременно, как раз в тему для игры
Сейчас же это все доделываю, а завтра уже наконец-то добавлю случайный спавн разных врагов (вес к врагам добавлю и улучшу EnemyManager)
#godot #ritkarampage #разработка
❤2🔥1
День 81
Наконец-то готовы и внедрены анимации смерти врагов
Вчера я сделал DamageComponent (вероятно название могло быть и понятнее) и DeathComponent. Первый отвечает за "выброс" крови и мигание спрайта красным при получении урона врагами, а второй при смерти испускает дух врага 😅
Враги есть, логика игры улучшается, а у главного персонажа все еще нету даже анимации ходьбы, не то что смерти, займусь этим на днях
Еще обязательно нужно доделать чтобы при смерти врагов и Ритки растекались лужи крови
Сейчас занимаюсь улучшением спавна врагов, чтобы все враги спавнились с какой-то вероятностью, наконец-то я дошел до этого этапа
Также прикрепил видео с результатом на сейчас и еще с небольшим процессом пиксель-арта
#godot #ritkarampage #разработка
Наконец-то готовы и внедрены анимации смерти врагов
Вчера я сделал DamageComponent (вероятно название могло быть и понятнее) и DeathComponent. Первый отвечает за "выброс" крови и мигание спрайта красным при получении урона врагами, а второй при смерти испускает дух врага 😅
Враги есть, логика игры улучшается, а у главного персонажа все еще нету даже анимации ходьбы, не то что смерти, займусь этим на днях
Еще обязательно нужно доделать чтобы при смерти врагов и Ритки растекались лужи крови
Сейчас занимаюсь улучшением спавна врагов, чтобы все враги спавнились с какой-то вероятностью, наконец-то я дошел до этого этапа
Также прикрепил видео с результатом на сейчас и еще с небольшим процессом пиксель-арта
#godot #ritkarampage #разработка
🔥1
День 82
Вчера снова большой прогресс в понимании - я разобрался с linear interpolation (еще раз), вот классное видео, которое рассказывает о ней и статья (снова та же), которую в конце уже сложновато понять, ну в любом случае полезно
— Начало математических извращений —
Что я понял вообще - что lerp это плавный путь к достижению цели НО без достижения самой цели, то есть у нас есть функция, которая вызывается каждый кадр (будь-то 10, 60 или 300 кадров в секунду) это все работает идеально именно из-за этого "НО" и просчитывается все практически пропорционально, например:
У нас есть delta - время, которое прошло с момента предыдущего кадра, если FPS 60 - то каждый кадр delta = секунда / кол-во кадров = 1 / 60 = 0.0167, если бы кадров было 2 в секунду - то delta = 1 / 2 = 0.5, что делает игру независимой от кол-ва кадров (как-то расскажу об этом тоже), ну щас о другом
Пример из реальной жизни - вы пнули дверь ногой (ну а шо), она быстро начала закрываться и постепенно замедляется, и, как на зло, до конца никак не закрывается
Максимальная скорость закрывания двери - 60км/ч (нормальный пинок кста), назовём эту скорость
1 секунда - 60км/ч
2 секунда - 30км/ч
3 секунда - 15км/ч
...и так далее, и она никогда не будет равна нулю (странная дверь, закрываться не хочет и останавливаться тоже)
Как нам воссоздать такую же логику в нашей игре? На помощь приходит та самая линейная интерполяция - linear_interpolation или сокращенно
Что у нас означает замедление - банально уменьшение скорости от 60 до 0, вот формула
У нас 60 кадров в секунду в игре
1 кадр - 60км/ч
2 кадр - 30км/ч
3 кадр - 15км/ч
...
То есть буквально за 7-8 кадров (это почти десятая часть секунды) дверь уже будет закрыта, но нам же надо закрывать дверь плавно, а не быстро, каждую секунду надо, а не кадр
Я упущу расчеты коэффициента.. для уменьшения вдвое каждую секунду он должен быть 0.6931
То есть каждый кадр при 60 кадрах в секунду у нас текущая скорость двери приближается к желаемой со скоростью 1.16% за кадр (т.к. 1 = 100%, 0.0167 = 1.16%). В таком случае каждую секунду у нас будет уменьшаться скорость двери примерно вдвое
0 кадр - 60.0000
1 кадр - 59.3040
2 кадр - 58.6161
3 кадр - 57.9241
4 кадр - 57.3282
...
60 кадр - 30.0000
...
120 кадр - 15.0000
Вообще лучше это делать через экспоненциальную интерполяцию, типа через
— Конец математических извращений —
Также сделал VelocityComponent, который отвечает за движение - его можно и нужно переиспользовать, чтобы не копипастить логику движения, его код прикреплю скрином, очень классный подход
Еще улучшил стейт-машину - я раньше явно передавал во все начальные состояния delta, даже туда, где оно не надо было, я задал про это вопрос преподу и он ответил, что можно использовать get_physics_process_delta_time функцию и, грубо говоря, это та же delta с того же кадра, но доступ можно получить отовсюду и работает оно точно так же, что написано в документации + препод подтвердил
Рандом спавн еще не сделал - но завтра доделаю, логику уже понял
Сегодня занимался обустройством рабочего места, а сейчас монтирую видео об этом, поучиться особо не получилось, зато будет интересный (наверное) контент из жизни, не просто же читать посты от непонятного эфемерного лица
#godot #ritkarampage #разработка
Вчера снова большой прогресс в понимании - я разобрался с linear interpolation (еще раз), вот классное видео, которое рассказывает о ней и статья (снова та же), которую в конце уже сложновато понять, ну в любом случае полезно
— Начало математических извращений —
Что я понял вообще - что lerp это плавный путь к достижению цели НО без достижения самой цели, то есть у нас есть функция, которая вызывается каждый кадр (будь-то 10, 60 или 300 кадров в секунду) это все работает идеально именно из-за этого "НО" и просчитывается все практически пропорционально, например:
У нас есть delta - время, которое прошло с момента предыдущего кадра, если FPS 60 - то каждый кадр delta = секунда / кол-во кадров = 1 / 60 = 0.0167, если бы кадров было 2 в секунду - то delta = 1 / 2 = 0.5, что делает игру независимой от кол-ва кадров (как-то расскажу об этом тоже), ну щас о другом
Пример из реальной жизни - вы пнули дверь ногой (ну а шо), она быстро начала закрываться и постепенно замедляется, и, как на зло, до конца никак не закрывается
Максимальная скорость закрывания двери - 60км/ч (нормальный пинок кста), назовём эту скорость
DOOR_SPEED, и каждую секунду дверь замедляется наполовину от текущей скорости, т.е.:1 секунда - 60км/ч
2 секунда - 30км/ч
3 секунда - 15км/ч
...и так далее, и она никогда не будет равна нулю (странная дверь, закрываться не хочет и останавливаться тоже)
Как нам воссоздать такую же логику в нашей игре? На помощь приходит та самая линейная интерполяция - linear_interpolation или сокращенно
lerp. Функция описывается так: lerp(начальное_значение, целевое_значение, коэффициент_увеличения)Что у нас означает замедление - банально уменьшение скорости от 60 до 0, вот формула
lerp для такого:lerp(текущая_скорость_двери, 0, 1 - (delta * 30) = lerp(текущая_скорость_двери, 0, 1 - (0.0167 * 30) = lerp(текущая_скорость_двери, 0, 0.5) => это значит, что каждый кадр скорость двери будет уменьшаться наполовину от текущей скорости, что в свою очередь значит.. что дверь за долю секунды практически закроется с бешеной скоростью..У нас 60 кадров в секунду в игре
1 кадр - 60км/ч
2 кадр - 30км/ч
3 кадр - 15км/ч
...
То есть буквально за 7-8 кадров (это почти десятая часть секунды) дверь уже будет закрыта, но нам же надо закрывать дверь плавно, а не быстро, каждую секунду надо, а не кадр
Я упущу расчеты коэффициента.. для уменьшения вдвое каждую секунду он должен быть 0.6931
lerp(текущая_скорость_двери, 0, 1 - (delta * 0.6931) => lerp(текущая_скорость_двери, 0, 1 - (0.0167 * 0.6931) => lerp(текущая_скорость_двери, 0, 0.0116То есть каждый кадр при 60 кадрах в секунду у нас текущая скорость двери приближается к желаемой со скоростью 1.16% за кадр (т.к. 1 = 100%, 0.0167 = 1.16%). В таком случае каждую секунду у нас будет уменьшаться скорость двери примерно вдвое
0 кадр - 60.0000
1 кадр - 59.3040
2 кадр - 58.6161
3 кадр - 57.9241
4 кадр - 57.3282
...
60 кадр - 30.0000
...
120 кадр - 15.0000
Вообще лучше это делать через экспоненциальную интерполяцию, типа через
e (2.71828), это число используется для плавного затухания/сглаживания, но это уже другая история (я еще сам не до конца догоняю)— Конец математических извращений —
Также сделал VelocityComponent, который отвечает за движение - его можно и нужно переиспользовать, чтобы не копипастить логику движения, его код прикреплю скрином, очень классный подход
Еще улучшил стейт-машину - я раньше явно передавал во все начальные состояния delta, даже туда, где оно не надо было, я задал про это вопрос преподу и он ответил, что можно использовать get_physics_process_delta_time функцию и, грубо говоря, это та же delta с того же кадра, но доступ можно получить отовсюду и работает оно точно так же, что написано в документации + препод подтвердил
Рандом спавн еще не сделал - но завтра доделаю, логику уже понял
Сегодня занимался обустройством рабочего места, а сейчас монтирую видео об этом, поучиться особо не получилось, зато будет интересный (наверное) контент из жизни, не просто же читать посты от непонятного эфемерного лица
#godot #ritkarampage #разработка
🔥3
День 83-84
Двойной пост (не в новинку) - догонять то надо
Вчера (пятница) и сегодня (суббота) особо не занимался разработкой, очень много монтировал видео и занимался обустройством рабочего места и ну очень много разных дел было (сходить в мак, полежать в кровати)
У меня проблема в комнате - есть жуткая реверберация в углу (это когда в конце каждого звука такой гул продолговатый), а место моё в углу значит тут я рабочее пространство себе и "назначил", да вот только в этом же пустом углу у меня ужасная акустика, этот гул напрягает очень сильно и ну прям мешает жить. Вот можете глянуть пример реверберации тут - https://youtu.be/cGBn7sU6m3k, у меня Small Room тип ревёрба, а хочеться простого, человеческого Clean Loop (чистый звук)
Мне очень хотелось сделать видео как можно интереснее, динамичнее, смешнее и в общем прикольное, так что я запарился с монтажем видео, прикреплю два видео к посту - одно это превьюшка, второе это более полное видео со всем процессом, а в комментариях закину видос, где я 2 минутыразговариваю ни о чем жалуюсь на реверберацию и показываю своё рабочее место
#life
Двойной пост (не в новинку) - догонять то надо
Вчера (пятница) и сегодня (суббота) особо не занимался разработкой, очень много монтировал видео и занимался обустройством рабочего места и ну очень много разных дел было (сходить в мак, полежать в кровати)
У меня проблема в комнате - есть жуткая реверберация в углу (это когда в конце каждого звука такой гул продолговатый), а место моё в углу значит тут я рабочее пространство себе и "назначил", да вот только в этом же пустом углу у меня ужасная акустика, этот гул напрягает очень сильно и ну прям мешает жить. Вот можете глянуть пример реверберации тут - https://youtu.be/cGBn7sU6m3k, у меня Small Room тип ревёрба, а хочеться простого, человеческого Clean Loop (чистый звук)
Мне очень хотелось сделать видео как можно интереснее, динамичнее, смешнее и в общем прикольное, так что я запарился с монтажем видео, прикреплю два видео к посту - одно это превьюшка, второе это более полное видео со всем процессом, а в комментариях закину видос, где я 2 минуты
#life
❤1🔥1😁1
Хотели бы вы время от времени видеть видео из моей повседневной жизни, а не только о разработке игр?
Anonymous Poll
77%
Да, это интересно (но в меру)
23%
Предпочитаю видеть только разработку
День 85
Вчера занимался продумыванием и визуализацией системы сложности, потому что в курсе очень простую систему препод сделал
Уровень сложности измеряется.. "уровнями", начинается все с "0" и каждые 5 секунд увеличивается на единицу, то есть каждую минуту уровень сложности повышается на 12
Вот как у препода сейчас это все сделано в EnemyManager (скрипт, который отвечает за спавн врагов и все что с этим связано):
1. Делаем ресурс "Enemy" у которого есть weight и enemy_scene, про вес уже рассказывал, а сцена - это просто враг, который будет спавниться
2. В EnemyManager мы ставим всех начальных врагов, описывая их вес
3. Когда сложность повышается до условных 20 единиц - добавляем в список врагов нового врага
У меня же будет совсем иначе, сейчас попытаюсь объяснить (очень доволен этой простой, но гибкой системой)
Главные переменные, отвечающие за логику:
1. TTS - Time To Spawn / Время для спавна врага в секундах. Если значение 1.0s - каждую секунду будет спавниться враг, если же значение 0.5 - каждые пол секунды
2. Ресурс "Enemy", который будет иметь следующие настройки:
2.1 enemy_scene - сам враг, которого мы будем спавнить
2.2 weight - вес врага
2.3 count - кол-во врагов, которое будет спавниться за раз (полезно для мелких врагов, типа Bird Swarm, которые будут группами спавниться)
3. И, самое главное - ресурс "DifficultyLevel". Он будет вместе собирать пункт 1 и 2 выше и потом использоваться в EnemyManager, вот что в нём будет:
3.1 enemy_resources- список настроек врагов (их вес, кол-во спавна и сами объекты)
3.2 difficulty_level - сложность, при которой будут применяться эти настройки
3.3 time_to_spawn - TTS из первого пункта
А в самом EnemyManager у меня будет список из гибко настраиваемых ресурсов "DifficultyLevel", в редакторе это нереально удобно делается (не надо создавать каждый раз новое - просто прям в редакторе добавляешь/редактируешь/удаляешь сколько хочешь), и будет проверка на DifficultyLevel, который должен применяться на данный момент
На эту идею меня подтолкнул коммент под видео про сложность из курса одного чела, я перенял часть его идей и добавил своего, что посчитал нужным
Прикреплю скрины как я это вижу (визуализировал же) для Meadow (Луг) локации
Ах да.. еще я понял что рисовать и визуализировать идеи это классно-прикольно, но таблицы с расчетами все-таки надо делать в каком-то Excel, потому что это нереально рисовать столько и считать, надо реактивность в подсчете total_weight, spawn_chance и все такое, к чему это я - купил курс по Excel на юдеми, длится пару часов, так что на днях гляну и буду уже как белый человек пользоваться экселькой не на прям базовом уровне, прикреплю пару скринов его предложения, на последнем скриншоте вы можете видеть как это будет выглядеть в редакторе - просто бомбезно удобно (хоть на первый взгляд, вероятно, не так)
Забыл поделится инструментом, в котором "визуализирую" - Excalidraw (вот ссылка чтобы скопировать текущее состояние моего проектика)
#godot #ritkarampage #разработка
Вчера занимался продумыванием и визуализацией системы сложности, потому что в курсе очень простую систему препод сделал
Уровень сложности измеряется.. "уровнями", начинается все с "0" и каждые 5 секунд увеличивается на единицу, то есть каждую минуту уровень сложности повышается на 12
Вот как у препода сейчас это все сделано в EnemyManager (скрипт, который отвечает за спавн врагов и все что с этим связано):
1. Делаем ресурс "Enemy" у которого есть weight и enemy_scene, про вес уже рассказывал, а сцена - это просто враг, который будет спавниться
2. В EnemyManager мы ставим всех начальных врагов, описывая их вес
3. Когда сложность повышается до условных 20 единиц - добавляем в список врагов нового врага
У меня же будет совсем иначе, сейчас попытаюсь объяснить (очень доволен этой простой, но гибкой системой)
Главные переменные, отвечающие за логику:
1. TTS - Time To Spawn / Время для спавна врага в секундах. Если значение 1.0s - каждую секунду будет спавниться враг, если же значение 0.5 - каждые пол секунды
2. Ресурс "Enemy", который будет иметь следующие настройки:
2.1 enemy_scene - сам враг, которого мы будем спавнить
2.2 weight - вес врага
2.3 count - кол-во врагов, которое будет спавниться за раз (полезно для мелких врагов, типа Bird Swarm, которые будут группами спавниться)
3. И, самое главное - ресурс "DifficultyLevel". Он будет вместе собирать пункт 1 и 2 выше и потом использоваться в EnemyManager, вот что в нём будет:
3.1 enemy_resources- список настроек врагов (их вес, кол-во спавна и сами объекты)
3.2 difficulty_level - сложность, при которой будут применяться эти настройки
3.3 time_to_spawn - TTS из первого пункта
А в самом EnemyManager у меня будет список из гибко настраиваемых ресурсов "DifficultyLevel", в редакторе это нереально удобно делается (не надо создавать каждый раз новое - просто прям в редакторе добавляешь/редактируешь/удаляешь сколько хочешь), и будет проверка на DifficultyLevel, который должен применяться на данный момент
На эту идею меня подтолкнул коммент под видео про сложность из курса одного чела, я перенял часть его идей и добавил своего, что посчитал нужным
Прикреплю скрины как я это вижу (визуализировал же) для Meadow (Луг) локации
Ах да.. еще я понял что рисовать и визуализировать идеи это классно-прикольно, но таблицы с расчетами все-таки надо делать в каком-то Excel, потому что это нереально рисовать столько и считать, надо реактивность в подсчете total_weight, spawn_chance и все такое, к чему это я - купил курс по Excel на юдеми, длится пару часов, так что на днях гляну и буду уже как белый человек пользоваться экселькой не на прям базовом уровне, прикреплю пару скринов его предложения, на последнем скриншоте вы можете видеть как это будет выглядеть в редакторе - просто бомбезно удобно (хоть на первый взгляд, вероятно, не так)
Забыл поделится инструментом, в котором "визуализирую" - Excalidraw (вот ссылка чтобы скопировать текущее состояние моего проектика)
#godot #ritkarampage #разработка
👍1