Поговорим об Unreal

Когда кто-то в команде ломает всё, до чего его руки дотягиваются, ни один уважающий себя программист с ней связываться не будет. Если туда и придут, то только такие же тяп-ляп погромисты-пофигисты. Можно было бы попробовать делать форк, но непонятно, с чего начинать. Если с версии 226, то там нужны годы работы, чтобы догнать качество того же 227i, не говоря уже про 227j по состоянию на 2018-й год. А дал бы или нет основатель 227-патча свою кодовую базу - ещё большой вопрос.

 

То, что Вы описываете, возможно, если программисты не используют GIT или ему подобное. Когда есть система контроля версий, то форкнуть можно практически на любом этапе, и никаких долгих лет не понадобится, чтобы догнать 227i. Ну и соответственно, откатиться тоже проще простого.

Не ему решать, код-то Эпикам принадлежит. Ему дали исключительное право на модификацию кода.
А на их форуме как-то даже Тим Суинни даже сказал, что в теории код могут открыть, но там типа дофига стороннего кода, что создаёт проблемы с лицензией.

 

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

 

я уже задолбался пропагандировать всех вокруг себя !

 

Была бы статья, а человек найдётся

Шило на мыло. Что анрил, что турмач, они не сильно отличаются, движок практически один и тот же.

 

Можно взять код от 200 версии и начать всё с нуля) уже давно по сети гуляет

 

ХЗ. Почему-то у многих при мысли об открытых исходниках в воображении сразу рисуется утопическая картина, что откуда ни возьмись должны прийти именно хорошие программисты и чего-нибудь толковое смастерить. Но ведь прийти-то могут и кодеры-колхозники, бурная деятельность которых будет вызывать лишь недоумение. Пример с нынешним положением 227 показателен тем, что бывает, когда исходники попадают не в те руки.

Там порой доходит до смешного: чел правит код и даже не удосуживается хотя бы по минимуму проверить результаты своего творчества. Так, например, одна из его недавних правок в скриптовом коде, отвечающим за ближний бой монстров, привела к тому, что подавляющее большинство монстров в игре полностью утратило способность наносить урон вблизи. Тестирование? Не, не слышали. В самом деле, зачем программисту от бога смотреть, как работает то, что он там накодил? Это удел обычных юзеров.

Отдельного внимания заслуживает то, как фиксятся некоторые дефекты. Так уж повелось, что часть проблем фиксится за счёт... добавления новых проблем взамен старых Вот, к примеру, есть у нас самонаводящаяся ракета, которая в сетевой игре летит некрасивыми рывками. Почему бы не сделать интерполяцию её движения на стороне клиента, прорисовывая ракету позади её реального расположения? Ну да, игроку будет чуть сложнее уклониться (пока он видит её в двух метрах от себя, она уже вовсю буравит его лоб). А ещё этот дым теперь появляется не позади ракеты, а ВПЕРЕДИ неё Зато теперь ракета плавно движется. Ура, ещё одна проблема решена и пополнила списочек пофиксенных багов ))

 

Притча про программиста и качели -- давно известна, да...

 

Для этого существует рецензирование патчей, т.е. их сразу не добавляют, а вначале проверяют хотя бы на соотвествие стандартам, кроме того, я уже упоминал Git: всегда есть возможность откатить изменение. Кстати, то, что Вы боитесь кодеров-колхозников, напоминает мне Microsoft 20 лет назад, которая примерно так же утверждала.

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

В общем, моё мнение: от открытия исходников движка под свободной лицензиие выиграют все, это доказывает опыт того же DooM'а и Quake.

 

А какая версия последнего патча 2.27 без этих глюков?

 

Вот именно ! А по сути, зачем ремонтировать то, что не ломалось !! Лучше бы кадрирующую рамку в редакторе поправили, а то как-то не очень клево ловить рандомно.

 

Насколько я понимаю, текущая реализация в 227j делает как раз интерполяцию движения на основе точек, которые ракета уже прошла. Из-за этого игрок видит её положение где-то в прошлом. Собственно, из-за сетевых задержек он по-любому не сможет видеть актуальное положение ракеты, но тут к задержке передачи данных добавляется ещё смещение позиции назад из-за применения интерполяции.

Основная сложность кроется в том, что механизм синхронизации должен быть един для клиента и сервера, а это проблематично обеспечить с учётом наличия старых версий игры, которые тоже предполагается поддерживать и как серверы и как клиенты, которые могут подсоединяться к новой версии клиента/сервера соответственно.

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

Вот так выглядит прерывистое движение самонаводящейся ракеты при 64 тиках в секунду на сервере и 59 тиках в секунду на клиенте

Вот так выглядит движение с экстраполяцией (реализовано мной в рамках сетевого мода к игре; параметры tick rate те же - 64 и 59)

Вот так выглядит движение с интерполяцией, реализованной в клиентской части новой версии патча (параметры tick rate те же)

Рекомендую заценить положение дымка по отношению к ракете в последнем ролике ))

 

Ну получается, что автор патча действительно что-то намудрил. Но, пока ещё 227j официально не вышел, то ещё рано критиковать недочёты.

 

В этом случае по итогу обсуждения сей странной фичи стало понятно, что автору больше нравится плавное движение, а дымок спереди его не смущает. Чтобы данную фичу отключить, надо писать мод, по-другому пока никак. А выход патча задерживается, прежде всего, потому, что разработчики никак не могут пофиксить все баги, которые сами же добавляют )) Весь процесс у них идёт примерно по следующей схеме:

1. Фиксится какое-то количество своих багов, созданных на предыдущей итерации.
2. Фиксится и "оптимизируется" куча какой-нибудь ерунды, заодно добавляются новые баги (нередко добавляемые баги намного хуже, чем исходные проблемы, которые пытаются устранять).
3. Реализуются какие-нибудь новые фичи, здесь тоже можно багов налепить.
4. На GitHub заливается сборка для бета-тестеров.
5. Бета-тестеры играют, плюются и доносят: "у вас опять какое-то гуано получилось здесь, там и ещё вон там".
Дальше переходим к п.1 и циклично повторяем вышеописанные шаги до второго пришествия.

Насколько я вижу, никаких долгосрочных планов развития проекта у команды нет. За что первым случайно зацепится глаз, за то и берутся. С такой "стратегией" можно очень долго держать бету на сырой стадии и продолжать кормить народ завтраками "да мы тут уже скоро 227j выпустить собираемся, осталось чутка допилить и усё". Это "скоро" я уже не раз слышал несколько лет назад.

--- добавлено 25 дек 2021, предыдущее сообщение размещено: 25 дек 2021 ---

Как по мне, самая толковая версия - это 227j_42. Она не лишена изъянов (есть в ней и некоторые ухудшения в сравнении с 227i), но в целом достаточно хороша. Даже главный разраб писал, что её стоило бы зарелизить для широкой публики, но сейчас типа уже поздно.

 

Вроде как над патчем работает всего один человек, поэтому всё так медленно идёт.

 

Сейчас минимум два: Smirftsch и Marco (на форуме oldunreal его ник .:..: ), который присоединился с разрешения Epic Games. Частично помощь также поступает от людей, занимающихся разработкой патча UT469, - AnthraX и CacoFFF.

 

@Masterkent, как то грустно все это. Сам не пробовал попроситься работать над патчем?

 

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

В отличие от кода на C++, исходники на UnrealScript открыты для всех желающих, и по ним любой может вносить свои предложения по улучшению. Было время, когда я предлагал свои исправления и их принимали. Исправления эти были разной степени сложности: от маленького фикса в одной строчке кода до написания объёмных классов и интеграции их в нужные места.

Например, одна из странностей Unreal заключается в том, что без применения нетривиальных в реализации модов игрок, находящийся в приседе или положении лёжа (притворившись мёртвым), имеет ту же физическую высоту, что и в положении стоя. Нельзя войти в невысокий коридорчик, пригнувшись, если в полный рост туда не пролазишь. В Unreal 227i (и, возможно, более ранних версиях патча, я не проверял) для решения этой проблемы есть флаг bSupportsRealCrouching. В целом он работает, но в нескольких ситуациях при его использовании возникают весьма необычные странности из-за кривой реализации.

И вот решил я, значит, что надо бы это дело поправить. Да так, чтоб картостроители и мододелы имели возможность быстро настроить, когда и как игрок способен группироваться в высоту: стоя на полу, находясь в воздухе (скажем, в прыжке), плавая в воде (при этом в воде имеется опция группироваться по направлению к потолку, если игрок прижимается к нему). Забабахал целый класс, много времени потратил, разбирая разные частные случаи, чтобы всё работало корректно практически при любых обстоятельствах.

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

 

@Masterkent, не в курсе, какие ограничения на освещенность статик мешей есть ? насколько влияют размер и полигонаж ?

 

Я мало что знаю про static meshes. Моя деятельность сосредоточена вокруг скриптов, а карты я не делаю. Пользовательских карт, которые используют эти меши, мне попадалось немного. Я замечал, что динамическое освещение на static meshes работает криво - прям как на обычных мешах. В 227j в этом плане, походу, ничего не улучшилось. Даже наоборот, теперь для всех мешей зачем-то сделали какой-то дурацкий эффект постепенного повышения их освещённости до полной яркости. В итоге, когда светишь чем-нибудь, например, на деревянные ящики, получается этакая сюрреалистичная картина: вся геометрия вокруг акторов сразу же освещается нормально, а акторы постепенно из тёмных становятся светлыми. Вспышки от взрывов из-за такой заторможенности в модели освещения просто не успевают освещать акторы по-нормальному, потому что они кратковременные.