Делал ли кто-нибудь игру используя модуль Graph3D?


#1

Если да, то пожалуйста, поделитесь условием для проверки, не коснулся ли персонаж объекта (прямоугольник). Я тупой, замучился уже пытаться. Буду очень признателен.


#2

Читайте инфу про создание физического движка. Без геометрии вы это не сделаете, если что. А встроенного в Graph3D нету, это модуль только для графики.

Ну, пересечение персонажа с паралелипипедом - сильно геометрии не надо, если не сможете сделать - помочь вам вряд ли кто то сможет.


#3

Печально, но всё же спасибо за ответ.


#4

Unity же… зачем изобретать велосипеды?


#5

Танедайбох. Я визуальные движки вообще недолюбливаю, но юнити худший из всех что я знаю.

Из того что на паскале - я всё с OpenGL делал. Раньше его модуль был… Мягко говоря неюзабелен. Сейчас как раз новый делаю: http://forum.mmcs.sfedu.ru/t/moduli-dlya-raboty-s-opencl-i-opengl


#6

Тогда быть может в Unreal Engine окунуться?


#7

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


#8

Если цель - научиться делать collision detection, то писать самому конечно. Если цель - сделать игру в разумное время, то пользуешь движок. Unity или unreal или чтото еще зависит от личных предпочтений.

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

Для начинающего и в юнити программирования хватит.


#9

Все игровые движки плохие, но Юнити - лучший из них. Никого не слушайте, изучайте Юнити.


#10

толсто)


#11

Иногда и толсто лезет.

Но ждать несколько сотен лет, когда какой-нибудь самодеятельный велосипедостроитель напишет свой движок, который лучше Юнити, - тут уж миль пардон!

И вообще, все споры, что лучше, вчера или сегодня, годятся только для телевидения. Кто умеет, тот и на Юнити напишет. Кто не умеет, тот всю жизнь будет искать чудодейственные движки, которые после нажатия на клавишу ВВОД всё остальное автодополнят.

Надеюсь, я достаточно утолстил своё сугубо личное мнение. А где тоньше, там и рвётся.


#12

Ждать чужих велосипедов - вредно. Но я говорил про написание своего велосипеда, и про это сказал:

Конечно, кривой недодел вроде Box2D это ещё хуже визуального движка. Однако:

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

  1. Визуальные движки порождают вредный для программиста тип лени.

Под полезной ленью - я понимаю нежелание выполнять рутинную работу. Это лучший моторчик для изучения новых технологий.
Простейший пример что могу придумать - установщик паскаля. Мне лень было перетыкивать все “далее далее ок далее” и ждать 2 мин. Поэтому я написал свой установщик. Теперь 1 клик и 10 сек, всё готово. А в процессе я научился автоматически вызывать распаковщик 7z и вообще работать с его консольным .exe, а так же узнал немного о NSIS (установщик которым пользуется паскаль).
Сама готовая возможность быстрой установки - вряд ли стоила времени написания нового установщика (и то если не считать эйфорию которую я получаю от прогресс баров в своих программах). Но знания и опыт - однозначно стоили того.
Таким образом лень была полезна, она подтолкнула начать разработку и обучение новому. А когда начал - уже и не больно)).

А вредная лень это наоборот, мысли аля “И так сойдёт, потом подправлю”. Она толкает на говнокод и вызывается обычно как рефлекс при нежелании глубоко изучать новую технологию. А как известно, если программист перестал учится - это уже не программист а кусок мяса. Поэтому и рефлекс такой стоит избегать.


Теперь ближе к теме.

“При чём тут визуальные движки?” А при том, что даже если их исходники будут открытыми, разбираться в них вряд ли кто то станет. Таким образом программист не знает кишков ни у 1 графического типа и не может судить о их эффективности в той или иной ситуации.

Это проблема вообще чего угодно, добавляющего уровень абстракции. И даже у чего то вроде модулей OpenCL и OpenGL которые я сейчас делаю. Но у графических движков - программирование очень высокоуровневое, поэтому там и этот эффект сильнее чувствуется.

Обычно - это лечится обилием примеров и подробной и хорошо рассортированной документацией.

Но у юнити даже нет нормальных примеров! Про другие движки ничего не скажу, ибо я в такой не лез, а вот юнити пытался недавно освоить 1 мой знакомый. Там вроде какие то библиотеки обновились, а о примерах никто много лет уже не заботился.

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

Как так случилось я могу лишь спекулировать, но факт остаётся фактом, людей использующих юнити - не получается уважать.


Однако это всё было сказано абстрактно. Возможно вы подумаете что я преувеличиваю. Поэтому, пришло время примеров. Текста уже стенка, так что будет 2, но если что - у меня их ещё полно, на все случаи жизни:

  1. Factorio

2D игра, на каком то низкоуровневом движке, вроде не_визуальном. Там постоянно происходит очень много всего, в том числе и на экране. И даже на ноуте эта игра у меня почти никогда не лагала. Только деревья в последних версиях убивают мой GPU, но только когда их полный экран и только потому что там не GPU а встроенный в CPU графический ускоритель, а толпе одинаковых объектов как раз нужно нормальное многопоточие.

  1. YanSim

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

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

То у него ИИ, у которых простейшая траектория движения - садят fps. При чём не ups, а они между собой в нормальных играх вообще не связаны.

То он прилепил зеркала в 5 местах в сцене, но т.к. у него были готовые компоненты - он не парился и даже не настроил их. Таким образом они работали всё время, даже когда игрок небыл рядом.

+ у него самого был видео про то что у него скопилось много говнокода, что он нанимал людей чтоб подчищать. Про это не могу быть уверен, но вот у меня в коде почему то никогда не появляются = true и подобная ересь.

Вот про такое я говорил “И так сойдёт, потом подправлю”. Когда понимаешь что как работает - сразу поймёшь и как делать не стоит, даже не сильно то и стараясь всё подумать. С зеркалами это точно сработало бы.


Перед итогом хочу добавить:
Дополнительные уровни абстракции это замечательно! Я обожаю идею метапрограмминга и почти любые сахарные конструкции. Они позволяют убрать рутину из программирования.

Но когда уровень абстракции это непродуманная мусорка без документации - он делает только больнее.

Это стоит понимать при выборе движков и т.п. И вместе с тем помнить что “и так” не сойдёт. Если уже делаете - добавляйте //ToDo, и только если знаете что потом будет не лень таки исправить.


#13

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

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

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

Ну и список AAA игр на юнити намекает, что не все так печально. Казалось бы у близзард то наверняка хватает ресурсов на свой движок, но hearthstone почему то сделан на unity. И они как раз отвечали, что это банально позволило им выпустить все гораздо быстрее на мобильных и планшетах.