Если да, то пожалуйста, поделитесь условием для проверки, не коснулся ли персонаж объекта (прямоугольник). Я тупой, замучился уже пытаться. Буду очень признателен.
Читайте инфу про создание физического движка. Без геометрии вы это не сделаете, если что. А встроенного в Graph3D нету, это модуль только для графики.
Ну, пересечение персонажа с паралелипипедом - сильно геометрии не надо, если не сможете сделать - помочь вам вряд ли кто то сможет.
Печально, но всё же спасибо за ответ.
Unity же… зачем изобретать велосипеды?
Танедайбох. Я визуальные движки вообще недолюбливаю, но юнити худший из всех что я знаю.
Из того что на паскале - я всё с OpenGL делал. Раньше его модуль был… Мягко говоря неюзабелен. Сейчас как раз новый делаю: http://forum.mmcs.sfedu.ru/t/moduli-dlya-raboty-s-opencl-i-opengl
Тогда быть может в Unreal Engine окунуться?
На здоровье конечно, но всё же велосипеды в программировании это лучшее чем можно заниматься, в плане обучения.
Если цель - научиться делать collision detection, то писать самому конечно. Если цель - сделать игру в разумное время, то пользуешь движок. Unity или unreal или чтото еще зависит от личных предпочтений.
Если это первая игра - очень полезно сначала узнать как все внутри работает, а уже потом пилить свое или будут сплошные грабли.
Для начинающего и в юнити программирования хватит.
Все игровые движки плохие, но Юнити - лучший из них. Никого не слушайте, изучайте Юнити.
толсто)
Иногда и толсто лезет.
Но ждать несколько сотен лет, когда какой-нибудь самодеятельный велосипедостроитель напишет свой движок, который лучше Юнити, - тут уж миль пардон!
И вообще, все споры, что лучше, вчера или сегодня, годятся только для телевидения. Кто умеет, тот и на Юнити напишет. Кто не умеет, тот всю жизнь будет искать чудодейственные движки, которые после нажатия на клавишу ВВОД всё остальное автодополнят.
Надеюсь, я достаточно утолстил своё сугубо личное мнение. А где тоньше, там и рвётся.
Ждать чужих велосипедов - вредно. Но я говорил про написание своего велосипеда, и про это сказал:
Конечно, кривой недодел вроде Box2D это ещё хуже визуального движка. Однако:
Вот внутри это как раз кишки. Если сначала пилить высокоуровневое - оптимизация катится в… никуда. Надо всегда знать как что устроенно или иметь точное описание всех возможностей, чтоб правильно пользоваться.
- Визуальные движки порождают вредный для программиста тип лени.
Под полезной ленью - я понимаю нежелание выполнять рутинную работу. Это лучший моторчик для изучения новых технологий.
Простейший пример что могу придумать - установщик паскаля. Мне лень было перетыкивать все “далее далее ок далее” и ждать 2 мин. Поэтому я написал свой установщик. Теперь 1 клик и 10 сек, всё готово. А в процессе я научился автоматически вызывать распаковщик 7z и вообще работать с его консольным .exe, а так же узнал немного о NSIS (установщик которым пользуется паскаль).
Сама готовая возможность быстрой установки - вряд ли стоила времени написания нового установщика (и то если не считать эйфорию которую я получаю от прогресс баров в своих программах). Но знания и опыт - однозначно стоили того.
Таким образом лень была полезна, она подтолкнула начать разработку и обучение новому. А когда начал - уже и не больно)).
А вредная лень это наоборот, мысли аля “И так сойдёт, потом подправлю”. Она толкает на говнокод и вызывается обычно как рефлекс при нежелании глубоко изучать новую технологию. А как известно, если программист перестал учится - это уже не программист а кусок мяса. Поэтому и рефлекс такой стоит избегать.
Теперь ближе к теме.
“При чём тут визуальные движки?” А при том, что даже если их исходники будут открытыми, разбираться в них вряд ли кто то станет. Таким образом программист не знает кишков ни у 1 графического типа и не может судить о их эффективности в той или иной ситуации.
Это проблема вообще чего угодно, добавляющего уровень абстракции. И даже у чего то вроде модулей OpenCL и OpenGL которые я сейчас делаю. Но у графических движков - программирование очень высокоуровневое, поэтому там и этот эффект сильнее чувствуется.
Обычно - это лечится обилием примеров и подробной и хорошо рассортированной документацией.
Но у юнити даже нет нормальных примеров! Про другие движки ничего не скажу, ибо я в такой не лез, а вот юнити пытался недавно освоить 1 мой знакомый. Там вроде какие то библиотеки обновились, а о примерах никто много лет уже не заботился.
Но настоящая причина, почему я так ненавижу юнити - я не видел ещё ни 1 игры на нём, у которой была бы нормальная оптимизация и небыло бы тупейших багов. Все игры с тем же уровнем графики, сделанные с юнити - запускались в 10 фпс на минималках на моём ноуте, в то время как игры с той же графикой, но построенные на чём то другом - давали не меньше 40 фпс на средних настройках. И с физикой та же фигня.
Как так случилось я могу лишь спекулировать, но факт остаётся фактом, людей использующих юнити - не получается уважать.
Однако это всё было сказано абстрактно. Возможно вы подумаете что я преувеличиваю. Поэтому, пришло время примеров. Текста уже стенка, так что будет 2, но если что - у меня их ещё полно, на все случаи жизни:
- Factorio
2D игра, на каком то низкоуровневом движке, вроде не_визуальном. Там постоянно происходит очень много всего, в том числе и на экране. И даже на ноуте эта игра у меня почти никогда не лагала. Только деревья в последних версиях убивают мой GPU, но только когда их полный экран и только потому что там не GPU а встроенный в CPU графический ускоритель, а толпе одинаковых объектов как раз нужно нормальное многопоточие.
- YanSim
Я давно слежу за разработкой, хоть сам и не играю, но процесс создания интересный и учит во многом как делать не надо))
Разработчик там всего 1, и явно хочет сделать игру как можно качественнее. Но, в то время как сюжет и т.п. он продумывает до мельчайших деталей - для графики он выбрал юнити. И он сам говорил - это чтоб не парится. И теперь:
То у него ИИ, у которых простейшая траектория движения - садят fps. При чём не ups, а они между собой в нормальных играх вообще не связаны.
То он прилепил зеркала в 5 местах в сцене, но т.к. у него были готовые компоненты - он не парился и даже не настроил их. Таким образом они работали всё время, даже когда игрок небыл рядом.
+ у него самого был видео про то что у него скопилось много говнокода, что он нанимал людей чтоб подчищать. Про это не могу быть уверен, но вот у меня в коде почему то никогда не появляются = true и подобная ересь.
Вот про такое я говорил “И так сойдёт, потом подправлю”. Когда понимаешь что как работает - сразу поймёшь и как делать не стоит, даже не сильно то и стараясь всё подумать. С зеркалами это точно сработало бы.
Перед итогом хочу добавить:
Дополнительные уровни абстракции это замечательно! Я обожаю идею метапрограмминга и почти любые сахарные конструкции. Они позволяют убрать рутину из программирования.
Но когда уровень абстракции это непродуманная мусорка без документации - он делает только больнее.
Это стоит понимать при выборе движков и т.п. И вместе с тем помнить что “и так” не сойдёт. Если уже делаете - добавляйте //ToDo, и только если знаете что потом будет не лень таки исправить.
Это все замечательно, если вы знаете как в целом устроен движок. Если вы в принципе не представляете себе как оно должно работать - самое разумное это посмотреть на что-то уже существующее. Опять же, даже собственные движки студий так или иначе имеют редакторы, потому что в конечном итоге программисты пишут код, но еще куча народу отвечает за дизайн, уровни, освещение, музыку и т.п.
Естественно, что самописный движок под конкретную игру будет работать лучше, при условии прямых рук у программиста, но для начинающего это почти наверняка будет означать что ты закопаешься в движке и ничего не напишешь в итоге, если это не что-то совсем простое.
В юнити тоже есть “обычный” подход и DOTS. Вот как раз обычном варианте начинает тормозить при наличии кучи всего в сцене, при этом сделать на нем что-то относительно простое можно за разумное время даже новичку. Есть профайлер, который позволяет понять где у вас все ложится. Примеров тоже куча, да часть из них по старым версиям юнити и много откровенно фиговых на ютубе, но все же у юнити гораздо больше доступных обучалок.
Ну и список AAA игр на юнити намекает, что не все так печально. Казалось бы у близзард то наверняка хватает ресурсов на свой движок, но hearthstone почему то сделан на unity. И они как раз отвечали, что это банально позволило им выпустить все гораздо быстрее на мобильных и планшетах.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021