Инвентарь в Godot

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

Важный этап разработки продуктов

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

Хотя я немного разочаровался в web-движке PlayCanvas, после того как его апгрейды поломали мне первый диаблоид - для каких-то очень маленьких легковесных игр он остаётся достаточно хорош. Поэтому для разнообразия реанимировал аккаунт и немного погрузился в программирование на js, написав аркаду (с механикой что-то вроде специфического урезанного BattleCity, но на сфере), где инопланетный космический кораблик летает над некоей планеткой.

Два разных проекта на движке Godot. Первым был Tesserfact — попытка перенести урезанную часть механик из настольно‑ролевой тактической игры в игру компьютерную. Но в процессе, в силу принципиальной невозможности переноса всех аспектов, подумал переориентировать его в игровой стол (Монстробой: Тактика — второй проект), где игрок управляет всем мануально и может «эмулировать» любые, незакодированные, правила. Что из этого лучше — вопрос открытый, как и то, что обязательно ли компьютерные игры должны быть именно играми общераспространённого вида, где весь интерактив целиком автоматизирован.

Прототип adventure-rpg в мире маленьких планет, где игрок управляет разумным звездолётиком, который посещает различные планетки.

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

Однажды было настроение собрать проект с управлением в стиле WoW, геймплеем куда-то в направлении Skyforge, экспериментальными игромеханиками и игрой за чистых magic user'ов - получился экшен-рогалик с заклинаниями от комбинаций. Также в этом деле оказалась замешана настольно-ролевая система "Неоновый миф" и её необычные герои.

Концепт настольной игромеханики для дуэльной асинхронной игры, сочетающей в себе тактику с миниатюрами на доске и управляющие их действиями колоды карты.

Что если вместо Невангеров делать аналог Вангеров, подумал я и сделал прототип торгово-гоночной игры на движке Godot. Собрав в нём некоторое комбо из различных наработок за все годы и заложив в игру классический вангерский процесс - развоз грузов. Естественно, с какими-то своими особенностями тоже.

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

Мне нужно было снять АЧХ фильтра в схеме измерения тока на основе дифференциального усилителя. Требование — ≥3 dB ослабление на частоте 1 kHz. Однако имеющийся в распоряжении лабораторный спектроанализатор с векторным анализатором не подошел, так как измеряет s-параметры только от 2 MHz.
Для решения задачи я использовал Analog Discovery 2 (сокращенно AD2) от Digilent — универсальный инструмент для тестирования и анализа сигналов. Я настоятельно рекомендую его инженерам. В нашей компании он появился благодаря директору, который активно интересуется новинками в электронике. Digilent на смену AD2 уже вывели на рынок Analog Discovery 3, но они взаимозаменяемы, поэтому инструкция подойдет и для AD3.
В этой статье я покажу, как использовать AD2 для построения АЧХ фильтра. Уверен, что эта инструкция будет полезна и познакомит вас с возможностями устройства.
Для выполнения задачи я буду использовать векторный анализатор цепей (VNA), который позволяет увидеть, как схема реагирует на входные сигналы разной частоты. Векторный анализатор тестирует цепь, подавая на нее сигнал, и измеряет, как она его меняет.

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

Фильма Стивена Спилберга «Первому игроку приготовиться» — не просто один из любимых моих фильмов. Те, кто смотрел, поймут, о чем я. Эдакий «Назад в будущее» наших дней, но вполне самодостаточный, с глубокими смыслами и кучей «пасхалок».
Одной из таких «пасхалок» стал для меня способ прохождения испытания для получения первого ключа. Напомню, по сюжету фильма, проходя «смертельную гонку» нужно было ехать не вперед, а двигать назад — задним ходом обратном направлении. И как ни странно, я нашел отражение этого принципа в реальной жизни.
В определенных ситуация я заметил, что если действовать не так как привык я, как принято действовать в подобных ситуациях, можно добиться не просто успеха, а даже превзойти свои изначальные ожидания. Объяснить это можно тем, что планируя путь к достижению поставленной цели через прямой путей решая набор последовательных задач, ты с одной стороны фокусируешься на результате (что безусловно неплохо), но в то же время ограничиваешь себя и не замечаешь возможности, которые могут тебе помочь и даже облегчить путь.
Я проанализировал ряд ситуаций, в которых я оказывался и действовал (зачастую неосознанно) не так, как обычно, я понял, что вряд ли мог бы получить именно такой результат. Мои достижения были бы намного скромнее.

Подборка игромеханик для использования в диаблоподобных action‑rpg (и не только).
В этом выпуске — изучение способностей с предметов, новая идентификация, ловля искр как база для прочих механизмов, комбинирование изученных рун с рунами оружия, переосмысление свитков и книг, левелапы через ачивменты, эволюционирующее оружие и монстры, зодиакальное пространство умений, само исследуемое подземелье в роли древа умений для персонажа и прочее.

Привет, Хабровчане! Я Рома — продуктовый дизайнер Tomoru.Team.
Дизайнеры и разработчики работаю вместе над перекладываем макетов из Фигмы в прод. В этой статье хочу рассказать как за полгода мы с командой смогли выстроить достаточно рабочую схему по передаче макетов без болей и горения пятой точки

Концепт альтернативной версии старого советского конструктора - своеобразный "Полёт 2.0", ремейк классики на новый лад.

В свете некоторого разбора Olden Era, подумал над концептом игры в похожем жанре - с геймплеем примерно в стиле симбиоза-микса Heroes 3 c Disciples 2, но что-то такое, более простое в разработке. И тут можно было бы уйти в некий фэнтэзийный "космос", где вместо героев у нас были бы звездолёты, а вместо замков - планеты.

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

Что может быть интереснее, чем создать на 3D-принтере нечто, что обычно делают на заводах? Например - старые добрые подшипники качения?
Приветствую сообщество Хабра. Это моя первая статья, поэтому сделаем все хорошо =)

Два моих хороших товарища потратили несколько лет на разработку адаптивной автоматической системы управления. Управления эвакуацией людей из здания. При пожаре. Слово «адаптивная» здесь означает, что система должна уметь сама приспосабливаться к меняющейся ситуации.
Что же тут необычного? Мало ли тех, кто создаёт автоматические системы профессионально. За хорошую зарплату. Согласно словарю, профессионал — это тот, кто за работу получает деньги. Но тут — особый случай. Мои товарищи системой занимаются в свободное время, не получая ни рубля.
Почему они это делают? Из сочувствия к гибнущим на пожарах людям? Конечно. Но... бесплатно работать в течение нескольких лет... Всё ясно: любители. Не подумайте, что это означает некомпетентность. Мои товарищи компетентны. Ещё как! Нет, это означает, что они влюблены в задачу. Хотя временами ненавидят её. В любви это бывает: задача трудная.
Не знаю, хорошо это или плохо, но любительство — заразительно. Однажды, «эти двое» мне говорят: «Как здорово было бы, если бы система знала, как люди прямо сейчас распределены по зданию. Сколько их находится на каждом этаже. Эх, да чего там! Общее количество людей в здании знать — и то было бы полезно.»
Я, не задумываясь даже, ответствую им: «Подумаешь, проблема какая! Надо лишь расставить кое‑где инфракрасные счётчики людей. Вроде тех, что установлены на входах в магазины. Счётчик замечает человека, когда тот пересекает невидимый инфракрасноый луч. Если у счётчика два параллельных луча, один рядом с другим, то он может „сообразить“, входит человек или выходит. Счётчики должны быть связаны в сеть, чтобы сеть суммировала людей по всем входам и выходам. Это же просто.»
Как известно, инфракрасные счётчики зарабатывают себе на жизнь, считая людей. Обычно, на входах в торговые центры и отделы.
Самый бесхитростный из них — счётчик с одним инфракрасным лучом. Он считает подряд всё, что движется. Точнее, всё, что прерывает его луч. Неважно, входит человек или выходит: счётчик добавит к переменной‑сумматору одну единицу.
Польза от такого счёта проявится только ночью, когда все, кто входил в торговый центр, выйдут из него. Тогда можно будет разделить показания счётчика на два и узнать, сколько за день было посетителей. Плюс‑минус погрешность счёта, которая для счётчиков этого типа обычно составляет... процентов.
Счётчик с двумя параллельными инфракрасными лучами сложнее. По последовательности прерывания двух своих лучей он может определить, входит посетитель в торговый центр или выходит. Это, теоретически, даёт новую, фантастическую возможность: не дожидаясь полуночи, узнать, сколько людей находится в торговом центре прямо сейчас. Нужно лишь из числа вошедших вычесть число вышедших. Разумеется, это знание тоже будет слегка расплывчатым: плюс‑минус погрешность счёта.
Как оценить эту расплывчатость? Какова типичная величина ошибок счёта для этого случая? Выясним это на практике.