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

Из баг-репортов тестирования бета-версии ИИ (ЫЫ) для Камрадов на Ксаше

В последние годы я перечитал немало книг о геймдеве и размышляю о том, с чего люди/команды людей начинали делать свои игры.

1) Самое простое, когда команде требовалось сделать продолжение существующей игры. Тут и обсуждать нечего.

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

Однако, есть подход, назовем его #2.5, который позволяет набраться опыта ничего не изобретая, но и не выпуская блеклые клоны популярных игр - это создание модификаций к тем самым популярным играм (half-life, quake). О нём ниже.

3) Далее, подход, при котором человек создаёт свою игру с абсолютного нуля не подражая никому. Я прокомментирую его чуть ниже.

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

Если вы считаете, что есть другие подходы, упомяните их в комментарии.

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

Мне нравится подход #1, но оставаясь независимым разработчиком, начать я с него не могу по очевидным причинам.

Подход #2 - подражать существующему - мне не нравится, хотя он и наиболее прост в реализации.

Подход #3 - создать своё с нуля, в моем случае плох тем, что из-за сложности реализации вероятность провала крайне велика. Не хотелось бы начинать с выпуска провальной игры, согласитесь.

Подход #4 - изобретение нового жанра рассматривать не будем, так как вероятность провала в разы выше чем у пункта #3.

Итак, как выясняется, я опасаюсь провала и при этом достаточно неопытен чтобы следовать по пути #3.

Путь #2 неприятен для моего эго, однако он позволяет достаточно безболезненно дорасти до #3.

Остается #2.5 - создание модификаций. Логическое продолжение - постепенное вытеснение из своих модификаций наследия оригинальной игры вплоть до создания totales convercionem.

Собственно им я и иду.
4 года назад я создал демо-версию модификации для Quake II под названием Comrades.

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

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

Ближе к концу её разработки, параллельно, начнётся создание совершенно нового проекта, за которым не тянется кодобаза q2. Это тот самый почётный подход #3

С сентября продолжаю курс UE и штудирование этой книжки

Такие лимиты idtech2 и не снились

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

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

Механики делятся на уникальные и регулярные, образующие геймплей.

Регулярные у меня скажем:
- сбор оружия
- убийство монстров
- работа с компьютерами для открытия пути

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

Для интересной навигации, а не коридорного шутера и не абстрактного лабиринта как в ку2, нужна интерактивная карта - для этого надо уметь кодить интерфейсы

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

Как же родить идею и сюжет, не имея возможности создавать и пробовать новые механики?

Почему я не могу создавать механики?
- почти не знаю Шот и Ксаш
- почти не знаю необходимые технологии геймдева
- не умею моделлить даже простые вещи

Как этому научиться?
- пройти курс по УЕ
- учиться модифицировать имеющиеся механики в Ксаше
- пройти курс моделирования

Для идеи и сюжета требуется еще:
- дочитать книгу по геймдизайну
- пройти курс по геймдизайну

Все это по идее должно занять весь 2025, после чего я буду в состоянии создавать хоть что-то.

https://cs13.pikabu.ru/video/2024/08/30/1725012958287824535_b84fb7c1_1080x1720.mp4


Очевидно, создание инди-игры с целью обогащения не имеет никакого смысла.

Исключительно ради удовольствия от процесса

Что ж, пора и за учёбу. 2 месяца пауза была в этот раз

Очередная домашка - плавное изменение FOV при прицеливании

Вторая домашка еще более примитивная - всего лишь добавить 2 поля - float-модификаторы, которые ограничивают скорость движения камеры в режиме прицеливания.

Теперь осталось оплатить проверку этих домашек (технически, курс у меня уже закончился, проверки теперь нужно покупать - 2500 руб за 2 недели).

После домашек перехожу к разделу курса "Амуниция".

https://www.youtube.com/watch?v=IaU2Hue-ApI

2 года назад я закрепил это видео во вкладке браузера, пообещав себе его посмотреть и разобрать.

Сегодня я наконец это сделал!

Непонятно зачем, выкачал видео и субтитры и смотрел в VLC. Но возможно это несколько облегчило изучение, так как постоянно перематывал вперёд-назад. Написал конспект в Obsidian.

Теперь можно наконец закрыть вкладку с чистой совестью.

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

у перса есть компонент экипировки, в котором хранится объект оружие (RangeWeapon), в котором есть MakeShot() и число патронов

когда игрок стреляет, MakeShot вызывает делегат у RangeWeapon, который вызывает делегат у компонента экипировки, который уже подписан на класс AmmoWidget, от которого наследуется блупринт, представляющий собой виджет "счетчик патронов" в ХУДе

и так вот они друг другу перекидывают новое число патронов, а ХУД забинден на значение int Ammo в AmmoWidget, и соотв. показывает актуальное число

причем на первый делегат контроллер подписывает компонент экипировки (компонент <-> виджет)

а на второй делегат (оружие <-> компонент) подписывается сам компонент

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