{"id":3842,"url":"\/distributions\/3842\/click?bit=1&hash=4c67e91a2a588f03561899c61c4eabfeb37008500c6498f3b9533b2e8845d454","title":"\u041e\u0431\u043e\u0436\u0430\u0435\u0442\u0435 \u043a\u043e\u043f\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u044b\u0445? ","buttonText":"\u0412\u0430\u043c \u0441\u044e\u0434\u0430","imageUuid":"11cfcef6-3125-52d0-8ef8-49fb205d3efe","isPaidAndBannersEnabled":false}
Gamedev
Закрытый каякер

Лошади были людьми: разработчик из Ubisoft рассказал о «костылях» в оригинальной Assassin's Creed Статьи редакции

Программист Чарльз Рэндалл поделился секретами разработки Assassin's Creed в своём твиттере — вероятно, в честь 15-летия франшизы.

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

Например, разработчики не могли выделить бюджет на дополнительный скелет и меши для Малика после того, как он теряет руку. Поэтому его «отсутствующая» рука просто вывернута наизнанку.

Полагаю, если бы вы смогли засунуть камеру в его модель, вы бы увидели эту маленькую свёрнутую руку.

Чарльз Рэндалл

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

Малик без руки — точнее, с рукой наизнанку

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

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

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

Чарльз Рэндалл

Разработчики из Ubisoft, конечно, далеко не единственные, кто использовал такие приёмы для того, чтобы добиться нужного результата. Один из самых известных примеров в индустрии — поезд из Fallout 3, который оказался головным убором персонажа под ним.

Как говорит Тодд Говард, «это просто работает»
0
148 комментариев
Написать комментарий...
wossup

Почему людей так волнует через какой класс, прототип, интерфейс, абстракцию, протокол, с каким тегом и какой моделью был реализован тот или иной игровой элемент? В разработке ПО в принципе постоянно используются не интуитивные и нестандартные хитрости. Ну выкрутили скелет в форму лошади, как будто их скелет обычной модели прям копия человеческого была, а не примитивная поделка.

Ответить
Развернуть ветку
After

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

Ответить
Развернуть ветку
wossup

ООП последние годы слегка теряет в популярности, на словах, по крайней мере, на деле не вижу особо. К тому же, как по мне, виной являются постоянные приведения в пример машин, геометрических фигур и прочее, как наглядные примеры ООП, но это не означает, что все на деле должно быть так логично, как в этих примитивных и малопригодных примерах. В разработке играют и другие факторы, как сложность масштабирования, оптимизации, сложность работы с инструментами, наглядность и комплексность.
То что разработчик подразумевал как объект человеческого скелета, на деле никаким человеческим скелетом не является, и из него легко, как оказалось можно сделать скелет, который будет применяться для лошади.
Видимо я слишком стар, что бы удивляться таким мелочам.

Ответить
Развернуть ветку
Николай Ксенофонтов

Так, а какая существует альтернатива ООП для описания подобных сложных архитектур?

Ответить
Развернуть ветку
Никита Мязин

ФП, разделение кода на модели (ADT) и бизнес-логику (функции) + ad hoc полиморфизм вместо наследования.

Ответить
Развернуть ветку
AE CHIM
ФП

Опять за своё беретесь.

С ООП бегают сектанты, уже которое десятилетие, сейчас еще и это будут прикручивать от удара "моды в башку".

Ответить
Развернуть ветку
Никита Мязин

За какое - своё? Спросили про альтернативы - я написал.
Они, конечно, не взаимоисключающие, но тем не менее отличаются и труЪ ФП код с ООП общего ничего не имеет.

Ответить
Развернуть ветку
fFamous

Так, а разве раньше такого не было? В итоге ведь пришли к ооп.

Ответить
Развернуть ветку
Никита Мязин

Што? Каким образом мы пришли к ООП, если перечисленные мной вещи - это наоборот то, чем альтернативы отличаются от ооп?

Ответить
Развернуть ветку
fFamous

Может ошибаюсь, но до появления ООП, ведь данные были отдельно, функции тоже. Потом появилось ООП, где "все" инкапсулируется, наследуется и так далее. Хотя, опять же, сейчас изучаю Spring и там что-то похожее на то, что ты описываешь. Есть энтити, которые хранят какие-то данные, есть отдельно классы которые с ними работают, что уже, как мне кажется, отхождение от ООП.

Ответить
Развернуть ветку
Никита Мязин

Были не функции, были методы и процедуры. Разница в том, что ты не можешь передать метод или процедуру в качестве параметра другому методу, процедуре или функции, а функцию - можешь. И инкапсулирование и наследование в этом случае тебе просто не нужно в понимании ООП. Инкапсуляцию ты получаешь бесплатно, потому что когда у тебя есть функция A - > B, ты не можешь её расковырять и посмотреть, как она из A получает B. С наследованием там чуть сложнее, но тоже можно. Полиморфизм, как я сказал, реализуется за счёт другого механизма (что-то типа паттерна visitor).
Ну и самое главное, про что не написал, в ФП должна быть иммутабельность. В обычном программировании надо охуевать и следить за одним состоянием всей программы, а ООП - только за состоянием объекта, а в ФП это состояние меняется только явно, поэтому следить за ним сильно проще.

Ответить
Развернуть ветку
fFamous

ФП подразумевает иммутабельность всего? Иммутабельность хорошая тема, но получается, что у нас каждый раз будет создаваться новая сущность. Разве это не будет довольно таки сильно бить по перфомансу?

Я вообще не шарю в ФП, но в Java есть штука stream-api, функциональные интерфейсы и лямда выражения. То есть, если какой-нибудь метод в параметрах принимает функциональный интерфейс Predicate<T>, то можно туда передать любой метод, который подходит по сигнатуре и вуаля. Да, удобная вещь, но насколько она реально соответствует ФП, тут не знаю.

Ответить
Развернуть ветку
Никита Мязин
ФП подразумевает иммутабельность всего

Да

Разве это не будет довольно таки сильно бить по перфомансу?

Зависит от. В некоторых случаях это будет наоборот быстрее, так как это открывает возможности для всяких разных оптимизаций, в некоторых случаях медленнее, тогда эти медленные участки переписываются с мутабельностью. Но у меня на практике (3 года на скале) ни разу не было случая, когда проблема с производительностью была в этом. Но это от области проекта зависит, у кого-то бывает и такое.
Обычно всем насрать на это, код на питоне обычно медленнее кода на ассемблере, но что-то желающих вести разработку на голом ассемблере немного.

насколько она реально соответствует ФП, тут не знаю

как напишешь, так и будет :) в целом да, это большой шаг в сторону ФП и предикат по сути функция A -> Boolean, но в джаве решили наплодить функциональных интерфейсов на все случаи жизни. Если реализация этого предиката не ходит во внешний мир (не пишет и не читает из базы, например), то это норм чистая функция. Короче что-то типа "obj - > obj.toString.length() < 10" - норм предикат в ФП стиле

Ответить
Развернуть ветку
fFamous

Ладно, это все конечно весело, но нужно сначала джаву добить со всем этим гребаным стектом и работу найти, а там уже можно будет что-то другое поковырять xD

Ответить
Развернуть ветку
Романтический цветок

Императивное != функциональное

Ответить
Развернуть ветку
Charlie King

Я возможно не совсем понимаю, но вроде проблема решается в рамках системы компонентов (Entity Component System), когда любой объект является набором отдельных подобъектов вплоть до чисел.
Я не трогал никакие проприетарные движки вроде тех же Unity, Unreal Engine & CryEngine, но в O3DE, по крайней мере, вся система сущностей основана на этом.

Ответить
Развернуть ветку
Vitaliy A.

О хоспади, борец с ООП в 2022. The blast from the past.

Ответить
Развернуть ветку
After

Говнокодер порвался, даже не вникнув в суть поста, лол

Ответить
Развернуть ветку
Vitaliy A.

О, но вы хоть самокритичны. Тоже плюс. Или два.

Ответить
Развернуть ветку
After

Так вы еще и говнокодинг с работой стрелочника совмещаете, уважуха

Ответить
Развернуть ветку
Vitaliy A.

Да как угодно, считайте меня говнокодером, если хочется. Только что это меняет в том, что вы порвались с упоминания ООП? И что борцы с ООП должны уже лет десять как вымереть бы.

Ответить
Развернуть ветку
After

Лоль бро, пост был про говнокодеров, а не про хейт ооп

Ответить
Развернуть ветку
Vitaliy A.

Действительно, что этом я...

Потому что нам постоянно втирают про ООП, ООП, ООП, как это четко и позволяет не плодить костыли
Ответить
Развернуть ветку
Неизменный лолипоп

Слышит звон, да не знает где он.

©Джейсон Стетхам

Ответить
Развернуть ветку
Никита Лукьянов

"Осторожно: ООП вызывает рак жопы"

Ответить
Развернуть ветку
fFamous

Я не особо шарю в том, как там это в играх работает, но это же не косяк ооп, не? Разве это вина парадигмы, если у разрабов были только двуногие скелеты, а денег на другие не выделяли или инструменты не позволяли? Вот наваяли там модель скелета человека, а вы пляшите как хотите 😆 Условно, тут ничего бы не поменялось какую парадигму не используй.

Ответить
Развернуть ветку
Nikita Novokreshchenov

Кто тебе вещает, где?

ООП как раз нихуя не подходит для игр, и де-юре, если прям доебаться до формулировок - даже уже и не используется

ООП хорош для энтерпрайза и софта

Ответить
Развернуть ветку
Читать все 148 комментариев
null