фиииии, они это и без того давно делают ну-сколько юзверов реально могут оценить адекватность "физики" в играх, да и на кой чёрт ОНО им нужно? юзверу нужна красочность, динамичность и широта сюжетной линии. Да, всё ЭТО очень желательно получить без покупок топовых железок. А вот пихать в гамис РЕАЛЬНУЮ ФИЗИКУ приводит к большой ПЕЧАЛЬКЕ == ресурсоёмкость алгосов чудовищно растёт, а вот {красочность, динамичность и широта сюжетной линии} только ухудшается --- Сообщение объединено, 21 янв 2021 --- неплохая статейка по теме https://www.techspot.com/article/1960-video-game-physics/ и ключевой момент тамо.. Ragdoll physics is used in most, if not all, games with player or NPC models.
Физика в играх конечно должна быть! Но не слишком точно реалистичная. В прочим, в некоторых должна быть близка к физических движкам. Вот например BeamNG.drive, физика разрушения очень хороша. А вот физика взрыва очень плоха. Вот и думай, как её можно реализовать, так, чтобы и точная была и ресурсов брало умеренно. Да и реалистичная физика, впечатляет гораздо лучше чем какой то там графон. Мне и первого Кризиса хватает. Остальное для идиотов.
Так не бывает и рыбку съесть и на рыбку сесть, всегда это компромисс в производительности, зачастую движок может выдать и что-то лучшее, но это потребует от юзеров сильного железа.
и как подобные упрощения отражаются на программистах и т.д.(кажется с самого начала речь о них шла)? Как выжимали из бедолаг всё, что можно, так и продолжают это делать. В подобном режиме работы не до сочинения оптимальных алгоритмов.
1. кто и кому обещал лёгкой житухи в наших бренных реалиях? 2. а кому сейчас легко? 3. всяк недовольный галерами гемдева, может попробовать себя в кочегарнях ИнПа (инженерного проганья), когда надо НАСТОЯЩИЙ ФИЗ ПРОЦЕСС запихнуть в алго и, что-то мне подсказывает, что те недовольные зарыдают В ГОЛОС.. И ЕЩЁ РАЗ В ГОЛОС 4. в гемдеве нужно дружить с маркетологами и желательно стать одним из них 5. в куче случаев заместо реального 3д можно пользовать видео вклейки, что очень сурово роняет затраты на цпу/гпу --- Сообщение объединено, 23 янв 2021 --- ЗЫ.. та же работёнка в датацентрах кудааааа поэнергичней по трудозатратам
Ну тут без матана никуда. П: Вы любите играть в игры? Ю: Я люблю. П: Вы любите игры с реалистичной физикой? Ю: Да. П: Но у нас есть проблемы с её реализацией. Ю: Что? А можно вы сделаете так, чтобы мы сами юзверы, её сами как-то за программировали? П: Хм! Надо договорится с руководством... П: Мы поговорили с руководством! И они решили что мы так сможем сделать! И сможем предоставить вам исходники игры Ю: Ура! П: Но это только спустя некоторое время и на определённых условиях. Ю: Ээ, на каких? П: Все ваши модификации принадлежат нам! П: И исходники мы можем предоставить в общий доступ спустя несколько лет спустя релиза игры. Ю: Эээ это никуда не годится. А можно сделать так, чтобы игру и во обще игровые объекты, можно было модернизировать без использования исходников. То есть перекомпиляции движка? Ю: С помощью скриптовых языков. П: Да! Наш движок работает на основе Lua. Ю: Lua? Это круто! Ладно... to be continued
На самом деле удивительно, как в эпоху подавляющей популярности ООП родились два ЯП без ООП и при этом дожили до наших дней и стали популярны в своих узких юз кейсах (имею ввиду ДжаваСкрипт и Луа, канеш в одном есть словари и прототипы, а в другом таблицы и метатаблицы, но это далеко не тоже самое, что в привычных ЯП, поддерживающих ООП). Наверное потому, что не было хороших альтернатив в этих самых узких юз кейсах.
ООП в Lua есть, Lua Binding. Не совсем полный ООП, но использовать можно, и нужно. В таком движке как XRay, можно создавать новые скриптовые Lua классы на основе движковых. Я например, решил ПЗРК скриптами на основе гранатомётов делать, просто так легче. А ракеты полностью в движке, т.к. им надо высокое быстродействие.
дело не в нём == все необходимые функи на уровне справочных данных, тч вполне их можно тупо копипастить да втыкать свои параметры. Однако, такой подход чреват жуткой тормозухой, поэтому стандартные функи упрощают под искомую задачу и запиливают с условием имеющихся железок. короче, выглядит так.. 1. разбиваем задачу на подзадачи. 2. решаем все подзадачи. 3. собираем решение искомой задачи. ======== на каждом этапе надо делать Балансировку Погрешностей, а с ростом кол-ва подзадач/элементов обсчёта Б-П приобретает очень дикие формы. убер решение пролегает в использование длинной арифметики. Но с большими числами можно смело забыть о плюшках цпу а-ля кэш и внеочередное исполнение команд. вообще, имеется весьма уныло-забавное неравенство.. То бишь энергия мат. модели > энергии оригинального процесса при 100%-ой достоверности модели. поэтому ооп бесполезная штука при стругание мм-ок вообще, в инженерных делах хороших решений по-определению нет. Есть лишь плохие и очень плохие == плохие по ресурсоёмкости и/ль качеству и/ль социальной компоненте. Акь изрёк один Товарищ == в инженерном ремесле остались только дурачки, а "умные" убЁгли в гламур, кушают гранты и совсем не тужат. Впрочем, последние дурачки уйдут в отвал и гламур не жилец
