История изменений

Иронично, но виндовые версии игр на юнити — самые беспроблемные в плане совместимости с wine (+dxvk), особенно последних версий. Что актуально, если разработчик принципиально не хочет делать/поддерживать билд под онтопик и игра напрямую не запускается с нативным unity-плеером

Как человек, кучу времени посвятивший работе с оффтопом, не могу удержаться от комментария.

Причина проблем с wine — это кривое использование штатного API и использования недокументированных фич. То есть, разрабы действуют методом тыка: заработало — не трогай. В свою очередь, разрабам винды из Microsoft для переноса софта на новые версии винды приходилось извращаться, вплоть до того, что делать в операционной системе workaround-ы для одной единственной софтины. Я вот в казаков пробовал играть на семерке — такое себе удовольствие. И это совместимость винда-винда!

Source и UE прекрасно работают под вайном, и я уверен, что куча других качественных, но более закрытых проектов.

Касательно убогости — она, как правило, проистекает из высокой дуракопригодности Unity3D

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

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

Когда ты делаешь инструмент разработки для профессионалов, то ты можешь сконцентрироваться на максимизации производительности обученного профессионала. Можно сделать инструмент, который подойдет одновременно для профессионала и для дурака, но проблема в том, что создатели Unity выкрутили дуракопригодность на максимум — в этом смысл закона Мерфи «сделай что-то, чем может пользоваться каждый дурак, и только дураки будут этим пользоваться», то есть, ориентация на полнейшего дебила сильно бьет по функциональности, что и произошло с Unity.

И да, очевидно что нативный движок будет эффективней и производительней «мерзкого сишарпа». Но тут уже вопрос компромиссов — время разработки, уровень требуемых навыков для разработчиков, итд/итп

По мере роста проекта неизбежно придется избавляться от C#, потому что внутри него нет никаких способов избавиться от мерзких неожиданных зависаний (или огромного жора памяти, если GC отключить). Ты не можешь сказать «мне этот объект не нужен — удалите, пожалуйста», нет, хрен тебе — подождем цикла GC, чтобы огранизованно подвиснуть. Я понимаю, что есть проекты вроде
https://github.com/jacksondunstan/UnityNativeScripting
но это уже пошла каша из топора, выходящая за рамки Unity — идя по такому пути и решая проблему за проблемой в результате ты получишь гору надстроект и костылей, за которой самого Unity уже не видно. И тогда ты поймешь, что лучше было взять UE, где все проблеы уже решены из коробки.

Иронично, но виндовые версии игр на юнити — самые беспроблемные в плане совместимости с wine (+dxvk), особенно последних версий. Что актуально, если разработчик принципиально не хочет делать/поддерживать билд под онтопик и игра напрямую не запускается с нативным unity-плеером

Как человек, кучу времени посвятивший работе с оффтопом, не могу удержаться от комментария.

Причина проблем с wine — это кривое использование штатного API и использования недокументированных фич. То есть, разрабы действуют методом тыка: заработало — не трогай. В свою очередь, разрабам винды из Microsoft для переноса софта на новые версии винды приходилось извращаться, вплоть до того, что делать в операционной системе workaround-ы для одной единственной софтины. Я вот в казаков пробовал играть на семерке — такое себе удовольствие. И это совместимость винда-винда!

Source и UE прекрасно работают под вайном, и я уверен, что куча других качественных, но более закрытых проектов.

Касательно убогости — она, как правило, проистекает из высокой дуракопригодности Unity3D

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

Когда ты делаешь инструмент разработки для профессионалов, то ты можешь сконцентрироваться на максимизации производительности обученного профессионала. Можно сделать инструмент, который подойдет одновременно для профессионала и для дурака, но проблема в том, что создатели Unity выкрутили дуракопригодность на максимум — в этом смысл закона Мерфи «сделай что-то, чем может пользоваться каждый дурак, и только дураки будут этим пользоваться», то есть, ориентация на полнейшего дебила сильно бьет по функциональности, что и произошло с Unity.

И да, очевидно что нативный движок будет эффективней и производительней «мерзкого сишарпа». Но тут уже вопрос компромиссов — время разработки, уровень требуемых навыков для разработчиков, итд/итп

По мере роста проекта неизбежно придется избавляться от C#, потому что внутри него нет никаких способов избавиться от мерзких неожиданных зависаний (или огромного жора памяти, если GC отключить). Ты не можешь сказать «мне этот объект не нужен — удалите, пожалуйста», нет, хрен тебе — подождем цикла GC, чтобы огранизованно подвиснуть. Я понимаю, что есть проекты вроде
https://github.com/jacksondunstan/UnityNativeScripting
но это уже пошла каша из топора, выходящая за рамки Unity — идя по такому пути и решая проблему за проблемой в результате ты получишь гору надстроект и костылей, за которой самого Unity уже не видно. И тогда ты поймешь, что лучше было взять UE, где все проблеы уже решены из коробки.