День 88

Летающие числа - это классно 1️⃣

Вчера занимался настройкой темы для проекта и летающими числами (урона и не только)

Пока что в моей мега уникальной теме только шрифт 👀

А насчет чисел поинтереснее, препод напрямую создавал числа в компоненте HurtboxComponent, но мне показалось, что это не совсем корректно, ведь Hurtbox отвечает за получение урона, а не за отображение чисел 🤔

Создал два компонента - первый с коротким названием FloatingTextSpawnerComponent и второй с еще более коротким названием HealthChangedTextSpawnerComponent

FloatingTextSpawnerComponent отвечает за спавн чисел, в него передаю сам текст и тип текста - "урон | лечение | поднятие апельсина". Этот компонент я напрямую добавил к сцене апельсина и вызываю spawn_text("+1", FloatingText.Type.ORANGE_PICK_UP) при поднятии последнего

А вот чтобы показывать изменение жизней (урон или лечение) - мне надо было персонажу и всем врагам добавлять этот компонент и прописывать так же само вручную в каждом скрипте спавн текста, вместо этого я сделал еще один компонент - HealthChangedTextSpawnerComponent, к нему я просто подключаю HealthComponent и этот новый спавнер слушает сигнал "damaged" или "healed" (еще нет такого, но будет) и спавнит текст с подходящим типом, обожаю компоненты и композицию - проект превращается в супер-гибкий конструктор 💃

Еще вот по мере роста этого огрызка недоигры у меня появился вопрос: "А как дебажить игры побольше? Мне уже неприятно"

Мне ж когда надо протестить будет поднятие сорока апельсинов мне надо будет их вручную создавать, а потом удалять. Когда надо врага потестить я отключаю спавнер врагов и добавляю нужного врага, и так далее абсолютно со всем

Но мне уже это как бы не очень приятно делать - я часто забываю что-то вернуть на место. Например при тестировании системы опыта и уровней я захардкодил значение "experience_to_next_level = 1", то есть мне надо только один апельсин поднять для нового уровня (для легкости дебага), но там должна быть цифра "5", а я забываю о таких вещах бывает (да-да, надо смотреть ченжи перед пушем в репозиторий, но епт) и это уже причиняет некоторую попаболь, поэтому мне прям интересно - как же тестируют/добавляют что-то в огромные игры?

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

День 89

Спустя три месяца я считаю уже пора начать.. читать документацию по Godot и GDScript 😎

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

Когда-то там пару месяцев назад я говорил: "С понедельника я начну читать документацию по самому Godot...", ну да, у меня своё время, слегка иначе идёт, затянулось начало

Вчера просто сидел и читал доку годота, поузнавал некоторые полезные вещи (еще бы я не узнал) и заодно наткнулся на демо-игры от комьюнити, которые сделаны на годоте и их даже можно поклацать в браузере - https://godotengine.github.io/godot-demo-projects/

А вот сама ссылка на репозиторий с демками - https://github.com/godotengine/godot-demo-projects, некоторые вещи в теории можно оттуда подсмотреть, так что как-то выделю время на просмотр кода демок

P.S. Демку с названием "Saving and Loading (Serialization)" не открывайте.. у меня браузер и комп умер, я даже словил не синий экран смерти, а красный (чет новое), видосик записал с телефона, потому что.. комп же умер 👀

#godot

День 91

Наконец-то добрался до написания поста, хоть и не очень информативного 🦤

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

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

Шейдеры - это "графика в коде", т.е. тени, свет, цвет, всякие визуальные эффекты типа ветра для деревьев (кстати недавно чел, за которым я слежу, выложил видео с примером шейдеров, ещё прикреплю к посту это видео) - в общем они прям делают графику очень интересной

Да только есть проблемка - в годот в вебе шейдеры нагружают страничку сильно, если верить ребятам из чата, условно какая-то игра на 9мб грузится 10+ секунд, хотя могла бы почти моментально*

*И.. я не проверял это лично, потому что мне шейдеры щас точно не нужны, к шейдерам я активно подойду позже, а сейчас нужно сосредоточиться на другом (я просто ленивый, а клацнуть экспорт и проверить работает ли всё - это выше моих сил)

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

День 94

Переработка оружия и другие мелочи 🔫

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

Сделал WeaponController, которому даётся сцена оружия (в нашем случае пистолет), контроллер создаёт оружие и работает как прослойка между фактически оружием и персонажем. Т.е. в скрипте персонажа что-то такое:

# player.gd
@onready var weapon_controller = $WeaponController
...
if Input.is_action_pressed('fire'):
    weapon_controller.shoot()

Также прикреплю скриншоты с деталями реализации

Забыл в прошлом посте написать что не все так гладко, баги тоже присутствуют и я случайно наткнулся на еще один - в EnemyManager изначально стоит 1 секунда на спавн врага и скорость спавна менялась только когда менялся уровень сложности (в смысле новая волна), это значит, что даже если бы я установил в настройках волны time_to_spawn = 0.1 то оно не применилось бы, если волна была бы первой. Сложно объяснить человеческим языком, надеюсь вы поняли 🫡

Добавил микроулучшение для оружия "Damage Up" просто чтобы протестировать, что всё работает как и надо (всё работает как и надо - подтверждаю)

Пока переделывал оружие возникло очень много вопросов на будущее, всё задал преподу (ну как обычно), всё еще не могу нарадоваться его подходу с композицией - это реально бомба 💣

Щас в процессе добавление улучшений для оружия, но я снова впал в неопределённость по поводу апгрейдов, думаю как бы их сделать интересными 🤔

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

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

День 96

Вернемся немного на 2й день разработки, где я говорил, что всё хочу делать сам 😱

Последние пару недель меня не покидала мысль над созданием своей небольшой команды, как минимум так будет веселее, как максимум (что самое главное) - эффективнее

Так вот - я потихоньку начал искать себе по разным чатикам/каналам и просто по поиску в телеге пиксель арт художника и саунд-дизайнера + композитора

Очень хотелось бы все это дело делать с знакомыми или друзьями, но не все так просто

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

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

Так к чему это я - хотеть это всегда хорошо, но надо быть реалистом, все-таки делать игры вместе будет очень классно и, что самое главное, намного, намного быстрее и качественнее, чем быть человеком-оркестром. Конечно хочется чтобы было всё "свое", но таким образом можно стать разработчиком Kenshi (18 лет разработки, из них 6 лет в одиночку) или 7 Days To Die (вечная альфа/бета, недавно релизнулись спустя 20 тыщ лет.. а её разрабатывает команда, хотя сначала было только 2 человека)

Примеры выше это офигенные и очень интересные игры, да только с огромным кол-вом багов и очень-очень длительными перерывами между обновлениями. Могу смело предположить что это всё из-за того, что изначально игры делались маленькой командой (2 человека) или же вообще в одиночку, что не позволяло тщательно протестировать-поплейтестить игру, спроектировать её, сделать баланс и, в итоге, это все стало снежным комом - "чем дальше в лес тем злее волки", технический долг рос до бесконечности, а теперь, вероятно, вместо 1 часа на добавление фичи приходится тратить 20 часов на неё же из-за нерасширяемого кода и вечных компромиссов (тоже в коде, и я не преувеличиваю)

Но ведь эти игры популярны и реально успешны и.. да, все так, но просто прикинуть сколько десятков тысяч людей делают уникальные игры в одиночку годами и о них никто не знает и они ничего не добиваются в итоге и забрасывают игры - это просто не счесть. Kenshi и 7 Days To Die по моему мнению это игры "1 на миллион" и что-то типа "ошибки выжившего"

Ошибка выжившего — это логическая ошибка, когда люди делают выводы только на основе тех, кто "выжил" или успешно прошёл отбор, игнорируя тех, кто не дошёл до цели. Это приводит к искажённой оценке ситуации, так как не учитываются неудачи или провалы.

Возможно я слишком серьёзно подхожу к этому всему, но, мне кажется, это хороший путь, ведь я учусь на ошибках других и продумываю наперёд

В идеале на данный момент хочу следующую команду:
- Разработчик
- Геймдизайнер
- Художник
- Звукарь

Разработчиком буду я, как и геймдизайнером, уже материалов для изучения набралось огромное кол-во, в особенности по балансировке, числам, прогрессии, левел-дизайне. И т.к. я делегирую работу со звуком и арт-дизайном другим, то у меня освобождается много времени, поэтому я смогу заниматься и геймдизайном полноценно тоже

Ну и не зря же я помимо основной работы подрабатываю - надо развивать своё дело, вкладываться, будет моя маленькая инди-компания 🙈

P.S. ох и долго же я делаю эту мини игру R.I.T.K.A. Rampage, но я никуда не спешу, главное успевать прокрастинировать несколько часов в день - это самое главное 😬