Тёмная тема
What is locomotion in games?
In virtual reality and video games, many locomotion systems, that is, methods that move users through a virtual environment...
GLoom
I understand :)
Вы планируете реализовывать? (уточняющий вопрос)
Когда нибудь. Например в первых же уроках настраивается выбор анимации по 2д карте. Этого в урхе нет, по этому надо будет делать что то такое в первую очередь
Появление IK.
Куча обсуждений по вопросу Character Controller (fps, tps)
Наработки от Lumak-а, Ивана и др.
Или вот (без доступа к исходникам) от Lumak
Все это следствие того, что потенциальная возможность
конечно же есть, но реализации из коробки нет.
Поэтому, народ тратит время на изобретение и отлаживание подсистем.
База с Компонентами, Подсистемами для геймплейных техник
упростила бы такие задачи (Изи-старт)
Возможность для Way-points навигации есть,
но не как подсистема из коробки, а лишь как потенциальная возможность.
И т.д.
P.S.
А где у rbfx Newton-physics плагин? Вроде был судя по офф. форуму.
Вот так и живём - вместо того чтоб делать PRы в движок все сидят по углам и пилят что то.
Newton не актуально насколько я помню, вроде есть планы переводить на PhysX.
ёж
а вы думаете в UE или Unity это из коробки? )))
нет, такого там нет, это отдельный специалист который всё это настраивает (обычно аниматор, который и пилит анимации), а за неимением его, тот кто прикручивает анимации.
Да, там есть события и флаги, но это совсем не облегачает многочасовую работу, скорее её усложняет. Ведь для каждого персонажа надо настраивать свою, при чём одну и ту же логику... ах-х-ха))
А сколько там различных Cache Pose.. сколько дополнительных трансформаций костей, сколько слоёв анимации.. для отдельного проигрывания верхней части костей (тела) и нижней части.
UE персонаж настроен на всё это
в Unity есть персонажи настроенные, но эту работу же кто то делал, пусть и не вы.
а код, который в rbfx, прекрасно можно настроить сразу и под всех. И он отлично переносится в любой из проектов. Вот и думайте кто лучше.
Проблема в том, это лишь для тестов, прототипов и прочего они есть. А для Вашей игры, это всё придёться делать по новой потому что персонаж будет другой и старые схемы ему не подойдут (из-за разницы названий анимаций, из-за скелета, из-за ещё чего нить). А в rbfx это не имеет значение, помеять имя анимации проблемы не вызовет. К тому же это всё можно задать динамически.
В UE правда тоже (но об этом знают единицы). Правда не через код 8( Там это вообще отдельный Blueprint который не может быть сделан в виде кода.
В Unity вообще стоит изменить иерархию и анимации перестают работать))) (что вполне логично, ведь иерархия это часть скелета)
GLoom
> PRы в движок
У кого-то цель скиллы прокачать и только.
У кого-то игровая механика, которую в философию "онли-движок" не запихаешь.
Кто-то не хочет тратить время на "проталкивание" идей.
И прочие причины.
Тут многое зависит от самих "движко-девелоперов".
В каких вопросах они заинтересованы, такие ответы они и ищут и внедряют.
Тут нет никакой критики совсем - каждый делает что хочет.
Salamandr
> думаете в UE или Unity это из коробки?
Абсолютно верно - что нет. (я движки не сравнивал)
Потому там и куча туториалов и middleware решений (порой платных)
А более-менее ббб-шного класса игры выпускают еденицы (чаще студии)
Конечно, конкретный проект будет стремится все затачивать и
адаптировать под свои условия.
Тоесть, правильнее писать и сочинять системы и компоненты зная эти условия.
Но вот программисты, когда им чего-то не хватает
вполне себе не считают зазорным подключить какую-нибудь либу,
где грамотный человек уже все сделал.
Даже не сильно подходящее под проект решение
может стать источником идей или кода.
У мну, кстати, нет однозначного отношения к анимационным технологиям.
Наверное самое "продвинутое" - euphoria physics и ее производные аналоги.
Но про это лучше забыть.
С одной стороны "технологично", а с другой даже у LiXin-а
вполне все выглядит прилично, а он даже блендинг анимаций не юзает.
Больше склоняюсь к отсутствию "лишних" вычислений.
IK - для ног?
Еще в Half-Life2 наблюдал и "хотел" :)
Думаю не такая большая жертва, а отсутствие этого может бросатся в глаза
и говорить о "отсталости" движка.
А если начнем погружатся в суть идеи,
то шаг за шагом прийдем к какому-то аналогу Locomotion.
GLoom
Обратил внимание в туторе на Input биндинг и схемы для него.
Прыгание персонажа в тачку или из нее переключает на другую Схему ввода.
Как правило, при таких схемах используются псевдонимы (экшены) для действий
и в коде юзаются именно они, а не имена клавиш.
Какая-никакая подсистема.
ёж
> Как правило, при таких схемах используются псевдонимы (экшены) для действий
Все так, все это будем делать.
ёж
> Прыгание персонажа в тачку или из нее переключает на другую Схему ввода.
отличная идея для будущих samples, must have
https://github.com/orgs/rbfxSamples/repositories
https://glprojects.itch.io/horror-survival
Первая подветочка:
https://github.com/rbfxSamples/rbfxHorrorSurvival/tree/TE/Application
Некто ƬΉΣӨ Σ. TheophilusE из Канады проявил активность
3 дня назад форкнул и rbfx и rbfxHorrorSurvival
По структуре папочек выглядит не как simple-sample,
а как комплексный проект от запуска, конфигурации до BehaviourTree, Network и др подсистем.
Тоесть, это нексколько больше, чем просто Туториал.
ёж
Мог бы просто спросить. Тебе подробности интересны?
GLoom
Коли объявлено, то всегда желаю наблюдать и подробности, и прогресс,
а не висящее на столбе объявление, которое со временем будет
потрёпано ветром и дождиком и вызывать уныние :)
Иначе приходится самому как-то выковыривать.
Project Trello board: https://trello.com/b/6bbtG6cW/horrorsurvival
Со старыми браузерами не дружит,
но на новых отражает "дорожную карту" проекта от Gloom для мастер ветки.
Подветка (заготовка) представляет логику приложения
и некоторые заготовки игровой логики,
с относительной полезностью и полноценностью реализации.
Загрузка (карт, уровней) - нужно расследовать
BehaviourTree - только заготовка
VoxelWorld - специфичная потребность, но отключаемый
И прочее.
Есть просто опечатки.
Например, дважды написанная строка кода.
У начинающего есть 2 пути:
Один (прототипирование) - это как делал std::cin.
Когда вы сразу получаете играбельный прототип
с игровыми механиками, а потом наращиваете логику приложения и подсистем.
Меньше кода, логика только необходимая и целевая.
Отличный подход для прототипирования,
но возможны накладные расходы связанные с последующим переписыванием кода,
что немного легче из-за малой кодовой базы.
В теории, игровой проект может быть очень прямолинейно-просто
написан. И это будет работать!
Меньше кода - легче твикать,
а в конечном итоге нужен-то результат.
Другой (системный) - это начать с базовой логики приложения.
Грубо говоря - с main функции.
Таким образом вы далеки от получения результата,
у вас могут быть лишние расходы и даже тупики,
поскольку реальные потребности игрового проекта не определены.
Код разрастается, но если логика обоснованная,
то не потребуется переписывать,
а ее использование должно (по идее) облегчать дальнейшее кодописание.
Тут главное не сильно увлекатся "систематизацией" и не забывать о результате :)
Ну, как предпологал, подветка взята из https://github.com/urnenfeld/Urho3D-Project-Template
App template with the following features:
Continuous integration with artifact publishing to itch.io (Android, OSX, Windows, Linux, WEB)
Level management
UI Window management
LUA/AS mods with hot-reload
Sound management
Input mapping
Splitscreen support
Achievement logic
Console command management
INI configuration file loading/saving
Settings window to configure all aspects of the engine
UI Joystick controls
Пожалуй, что единственный пример системного подхода.
Есть как лишнее, так и нужное.
Расковыриванию поддается.
Возможно Network будет несколько препятствовать,
если он вам не нужен,
т.к. левелы и игроки содержат код для сервер-клиент.
Вероятно оптимальным будет выдяргивать из него только нужное.
Писался под оригинальный Urho3D