Прошёл неделю тому назад я REPLACED. Очень был впечатлён визуальным стилем.
Понравилось мне, как спрайты реагируют на свет. И да, я понимаю, что там ребята использовали честное три дэ, а я сваю игру делаю в два дэ, но это не значит, что я не могу вдохновиться и решить что-то своё.
Сделал я вот такую систему:
Как я добился того, чтобы объекты реагировали на свет именно подсветкой края?
Правильно, написал свой шейдер для этого.
Логика работы шейдера такая: по альфа (прозрачности) выясняем какие пиксели картинки являются крайними, потом получаем текстуру 2Д освещения и соединяем информацию из текстуры освещения с найденными ранее пикселями.
Стоит оговориться, что речь не просто про Godot как таковой. Потому как я сделал форк Redot'а (форка Godot'а) и там уже в исходниках движка внёс исправления.
Мне показалось странным, что такой базовой вещи, как менеджер пакетов нет в движке из коробки, поэтому я вооружился буквами и пошёл насыпать их в код. В качестве первого этапа разработки подключил АПИ NuGet'а, дальше в будущем планирую добавить добавление пакетов из гита и в последствии, думаю, это будет логично, планирую поднять собственный репозиторий, чтобы хранить там свои какие-то переиспользуемые пакеты или пакеты, предназначенные только для движка.
Вообще, если вы используете для работы не встроенный редактор скриптов, а VS, то стандартного нюгет пакета вполне хватит на первое время, но так как я сморю чуть дальше и чуть глубже, я пошёл по пути собственного инструмента. Дополнительно: я пишу на шарпе, а Годот по умолчанию работает с GDScript и шарп у него подключается отдельно. Я сбилдил свою версию так, чтоб она по умолчанию работала с шарпом.
И так, что же у нас тут по менеджеру пакетов?
В папочке modules/mono/editor/GodotTools/GodotTools/ создаём новую папку нашего инструмента, я назвал её NuGet на текущем этапе. При доработках думаю, переименую уже во что-то более универсальное.
Внутри папки создаётся три файла: NuGetManagerWindow.cs
Класс описывающий окно, наследует и имплементрирует ConfirmationDialog, ISerializationListener. Описать обязательно несколько методов:
public override void _Ready()
{
Title = "NuGet Package Manager";
Size = new Vector2I(800, 600);
Exclusive = true;
_apiClient = new NuGetApiClient();
BuildUI();
RefreshInstalledPackages();
}
BuildUI и RefreshInstalledPackages соответственно это не обязательные прям с точки зрения Годота методы, просто я в них вынес нужную мне логику.
Второй класс NuGetPackageInfo - это буквально описание каждого пакета. То есть просто DTO для пакетов с основной информации:
/// <summary>
/// Represents a NuGet package from search results.
/// </summary>
public class NuGetPackageInfo
{
[JsonPropertyName("id")]
public string Id { get; set; } = string.Empty;
[JsonPropertyName("version")]
public string Version { get; set; } = string.Empty;
[JsonPropertyName("description")]
public string Description { get; set; } = string.Empty;
[JsonPropertyName("authors")]
[JsonConverter(typeof(StringOrArrayConverter))]
public List<string> Authors { get; set; } = new();
[JsonPropertyName("projectUrl")]
public string ProjectUrl { get; set; } = string.Empty;
[JsonPropertyName("iconUrl")]
public string IconUrl { get; set; } = string.Empty;
[JsonPropertyName("totalDownloads")]
public long TotalDownloads { get; set; }
[JsonPropertyName("versions")]
public List<NuGetVersionInfo> Versions { get; set; } = new();
public string AuthorsString => string.Join(", ", Authors);
}
Ну и NuGetApiClient – логично, что дёргает запросы в сторону нюгета, для получения информации о пакетах.
После того, как мы всё что нужно описали, надо отредактировать GodotSharpEditor.cs и добавить туда ссылку на наше окно, добавить пункт меню и его обработчик для открытия нашего окна
Как вы могли заметить, я люблю программировать всякую фигню. Пишу иногда полезные штуки, иногда просто что-то для себя. Но что касается именно разработки игр, то я занимаюсь своей «Игрой мечты» уже очень много лет и конца и края этому не видно, а вот такие небольшие или условно небольшие игры, как те же танчики – это дешёвый эндорфин, который в первую очередь даёт не забыть, что я всё ещё на что-то способен и могу делать готовые вещи, а не только долгострои.
@vervolph пошутил (пошутил же, правда?) про третьих героев, @Kukabara пошутила (не, ну она-то точно пошутила) по циву. А я сижу и думаю: «А может правда что-то взять да сделать?».
Я набил руку на вопросах IO, я люблю классические игры, мне нравится идея дать вторую жизнь чему-то забытому/умершему/устаревшему. Может, чисто ради общей движухи и чтоб потом ещё и поиграть, забубеним что-то общими силами? Можно выбрать какую-то интересную игру и сделать её клон/духовного наследника. Можно даже и герои, если делать только вертикальный срез, а дальше как пойдёт. У нас тут дофига народу, кто умеет рисовать, чтобы взять на себя графику, есть те, кто шарят за программирование, а кто-то, возможно, не шарит ни в том ни в другом, но очень хочется, можем это превратить это даже в некий элемент наставничества местами.
Если никто не воспылает идеей, то в этом нет ничего плохого ) Но если пара тройка человек найдётся, то, это может быть интересно.
В общем-то, сегодняшний пост будет совсем без кода, так как игра механически была готова ещё в прошлый раз, теперь же я хочу просто показать, что в итоге получилось и как оно работает.
Видео записывал для ютуба, так сказать, чтоб привлечь свежую кровь, поэтому тут много лишнего, но суть, думаю, по нему понять можно)
Ещё раз всем спасибо! Ушёл писать какую-нибудь очередную ерунду.
Прошлой ночью мы накатили обновление на Лиспублику, о нём вы можете прочитать в официальном посте, но там не было рассказано маааа-а-а-аленькое обновленьице. А дело всё в том, что мы запустили на базе Лиспублики игровую платформу. Называется она Лиспублика-Аркады.
На данный момент там лежат мои поделки, о которых я тут много писал. Вы можете зайти, поиграть, посоревноваться друг с другом (есть таблицы лидеров), играйте совместно (в танчиках есть есть онлайн режим :) ).
А ещё! И это очень важно, если вы уметете создавать игры, способные работать под веб, то загружайте их к нам!
У платформы есть SDK, который даёт вам доступ к основному функционалу: сохранение прогресса, сохранение рекордов, накопление и расходование токенов(если ваша игра хочет, чтоб игроки тратили некие очки). Если будут идеи по расширению функционала, я всегда готов почитать ваши предложения в комментариях!
Но они этого не говорили! Это люди придумали. Но выглядит правдоподобно.
Некоторое время назад появилась информация, что Сони отказывается от политики временной эксклюзивности своих игр в пользу полной эксклюзивности. Как это было раньше, как это есть сейчас, например, у Нинтендо. Сторонние студии по прежнему могут делать игры куда хотят, но вот внутренние студии Сони будут работать только на то, чтобы их игры выходили лишь на родной платформе.
Предположений почему так мыло много, но в итоге пока что побеждает мысль о том, что стим машина, которая будет поддерживать всю библиотеку Стима просто обесценит даже мысль о покупке консолей Сони. Зачем, если можно купить СтимМашину и подождать порта любимой игры на ПК?
СтимМашина и как на неё попасть
Чтоб не отходить далеко от темы. Игры будут иметь плашку совместимости со СтимМашиной, аналогично тому, как это сделано для СтимДека. Так вот, если у вашей игры уже есть плашка совместимости со стимДеком, Значит на СтимМашин игра 100% уже "Да". В остальном же, Валв для получения сертификации будет требовать от вашей игры 30 кадров в ФуллХд. Так сказать, обеспечивайте производительность, господа и дамы. Причём, если я правильно понял, речь идёт именно о нативном разрешении и ФПС, без использования апскейлеров, дорисовщиков кадров в рантайме и т.д.
Изменение возрастного рейтинга для стран Евросоюза
Система Пеги внесла правки в свои правила пометки игр и выдачи возрастного рейтинга. Там, на мой взгляд, практически ничего интересного. Но если в кратце: если в вашей игре есть лутбоксы, то она 18+, если есть аналоги казино – тоже, если просто есть платный контент какой-то или контент скрытый за пейволом (например, боевые пропуски), то минимум 13+. В общем, все изменения связаны именно с монетизацией проектов и попыткой вытащить из игроков денежки.
У СтимМашины есть конкурент
Никак не могу отпустить СтимМашину... В общем, Майки вывалили анонс своей новой версии ИксБокс. Пока известно три стопроцентно достоверных факта (может больше, но я только эти пока уловил):
Она будет запускать игры, собранные для винды
Для ИксБокса не надо будет делать отдельную сборку. Одна сборка и для него и для винды
АМД специально для майков сделает уникальный графический чип.
А ещё они говорят, что очень подумают над обратной совместимостью, но пока ничего не обещают.
То есть конкурент как бы есть, но пока не очень полноправный.
Вот и всё за прошедшую неделю, что я смог интересного собрать. К следующей неделю попробую собрать побольше)
Вопрос оптимизации очень обширный и чаще всего за него отвечают всё-таки программисты и 3Д художники. Одни пишут более качественный код, вторые делают менее тяжёлые модели, объединяют материалы, пилят ЛОДы и занимаются прочей монотонной, но важной ерундой, без которой мы получим современный геймдев, где любая выглядящая как кусок пластилина игра тормозит на топовом железе.
Но и в руках левел дизайнеров есть инструменты, работающие на оптимизацию, и именно о них я хотел бы сейчас поговорить. Хотя изначально именно этот этап был посвящён просто наведению на сцене порядка.
Однако, темы на поверку оказались смежными, так что давайте посмотрим, какие инструменты у нас есть для всего этого безобразия.
1. Иерархия объектов на сцене.
Вот так сейчас выглядит моя сцена
Можно заметить, что объектов не так и много, но я могу развернуть, например, ПолиШейп объект и увидеть, что там внутри каждая ступенька, стенка, уголок спрятаны
Помимо просто визуального порядка и удобства работы это даёт нам возможность дополнительных манипуляций:
Можно перемещать, менять масштаб и дублировать сразу группы объектов
Можно деактивировать целые группы для большего удобства в работе
Можно задавать свойство статичности всем дочерним объектам одной галочкой
Пример деактивации. Тут я просто выключил все источники света на сцене
Что за статичность? Зачем?
Установка это галочки просто обязательна для объектов, которые не будут изменять своего положения в процессе игры (ну или по крайне мере в рамках данной сцены). Движок такие объекты запоминает и обрабатывает пачкой, не тратя на них доп. ресурсы. Именно такие объекты движок не будет рендерить, например, если они не попадают в камеру, если предварительно запечь окружение (Occlusion Culling).
Есть, кстати, ещё один очень похожий способ оптимизации, но с ним надо быть чуть осторожнее и он уже требует навыков программирования. Которых, если мы говорим о чистом дизайне уровней, может и не быть. Поэтому без кода, но на алгоритме я его сейчас всё же опишу: Предположим, у вас есть моделька ящика. Вам надо из этого ящика нагромоздить кучу, которая двигаться не будет, а создана лишь для захламления и заполнения пространства.
Вы красивенько расставляете ящички, а потом скормили их скрипту, который возьмёт их все и склеит в один меш (это же можно попросить сделать и художника, но кто вам гарантирует, что он сделает именно так, как вам нужно?)) ) и таким образом сотня ящиков делает не сотню дроуколов, а один! Из важного: а) объединить можно только объекты, использующие один материал. б) лучше объединять такие объекты, которые будут попадать в камеру всей пачкой, чтоб не получилось, что большая часть из них в камеру не попадает, а ГПУ их всё равно обрабатывает.
Я вот сейчас это пишу и думаю: «А какого лешего я заговорил об оптимизации в середине цикла?».
А всё дело в том, что, как я и написал в самом начале, я хотел рассказать просто про порядок на сцене, а оптимизация сама за собой подтянулась. Но вообще этим вопросм лучше озадачиваться на каждом этапе работы, чтобы под конец не пришлось переделывать весь уровень...
P.S. Если вам код склеивания мешей в один таки нужен, пишите в комментарии, покажу)
Пост совершенно незапланированный, а стихийный. Так уж получилось, что я написал свой движок для создания визуальных новелл. Сделал я это по весьма простой причине: главенствует на этом поприще РенПай. Но как я смог понять, там всё печально. Использовать Юнити, Годот, Анреал для таких целей – выстрел из пушки по воробьям.
Поэтому я решил, что попробую написать свой квест и элементами визуальной новеллы на самописном движке с рендером через HTML5 канвас.
Собирался сделать это чисто для себя и зарегистрировал на npm чисто чтобы было удобнее обновлять на реальных проектах. Но в итоге за двое суток существования движка набралась почти тысяча скачиваний
Немного неожиданное явление для меня, но я пришёл к выводу, что вопрос актуальный и востребованный, так что буду рад, если кто-то движок попробует и навалит на меня обратной связи.
Для создания шаблона игры достаточно выполнить команду:
npm create @variussoft/vn-game my-game
Обновить движок в уже существующем проекте можно командой:
npm i @variussoft/vn-engine
На текущий момент поддерживается минимальный базовый функционал: стартовая заставка; главное меню; сцены, на которых есть статичные (картинки) или динамичные (видео) фона сцен, анимированные объекты (покадровая анимация через спрайт-шиты), фоновая музыка, интерактивный объекты, кат-сцены через смену кадров, диалоговая система с условиями и последствиями, мини-игры (отдельная сущность для тех случаем, когда хочется сделать что-то уникальное). Мне для моего проекта этого достаточно, но я с радостью доработаю движок, если кто-то принесёт мне набор предложений по улучшению.
Обратную связь пишите здесь в комментариях или на почту: nick@variussoft.ru
кстати, облако похоже на то нло, кадры с которым на днях опубликовали.
чо за борзота пошла?