Почему только несколько видеоигр написаны на Java? [закрыто]

Почему не много коммерческих 3D-игр (не случайных 2D-игр с открытым исходным кодом) написаны на Java? В теории это имеет большой смысл: вы получаете повышение производительности и кроссплатформенное приложение почти бесплатно, среди прочего, например, огромное количество библиотек Java и встроенную сборку мусора (хотя я признаю, что ' я не уверен, что последнее хорошо). Так почему это редко используется? Я могу только думать о паре популярных коммерческих игр, написанных для платформы Java.

Это из-за производительности? Если это так, разве большая часть тяжелой работы не будет выполнена GPU?

Мир разработки игр забавен: с одной стороны, они часто быстро принимают новые идеи, с другой - они все еще находятся в каменном веке.

По правде говоря, редко бывает так много стимулов для перехода на .NET / Java / что-либо, кроме C / C ++.

Большинство игровых компаний лицензируют части игрового движка от других компаний. Эти части написаны на C ++, и, хотя у вас может быть доступ к исходному коду, чтобы вы могли его портировать, это требует больших усилий (и, конечно, лицензия должна позволять это).

Кроме того, много унаследованного кода уже существует в C ++. Если код из предыдущих проектов можно использовать повторно (скажем, если вы пишете сиквел), это еще больше значит, что нужно придерживаться того же языка, а не переписывать его на новом языке (тем более, что вы, вероятно, будете вводить заново). тонна жуков, с которыми вам придется потратить время на устранение.

Наконец, игры в любом случае редко пишутся на 100% C ++ - многое делается с использованием языков сценариев, независимо от того, являются ли они пользовательскими или просто интегрируют существующие языки (Lua является одним из самых популярных в наши дни).

Что касается сбора мусора, это может быть проблемой. Проблема не столько в том, что он существует, сколько в том, как он работает - сборщик мусора ДОЛЖЕН быть неблокирующим (или, по крайней мере, гарантированно блокировать его очень недолго), поскольку просто недопустимо останавливать игру на 10 секунд, пока он сканирует всю выделенную память, чтобы увидеть, что можно освободить. Я знаю, что Java имеет тенденцию задыхаться в GC'ing, когда она близка к исчерпанию памяти (и для некоторых игр это будет).

Вы также немного более ограничены в том, что вы можете сделать: вы не можете полностью использовать оборудование из-за накладных расходов времени выполнения. Представьте, что Crysis написан на Java ... даже если это единственное видимое отличие, оно не будет таким же (я также уверен, что вам понадобится Core i7 для его запуска).

Это не означает, что эти языки не имеют своего места в разработке игр - и нет, я не просто имею в виду программирование инструментов. Для большинства игр вам не нужна дополнительная производительность, которую вы получаете от C ++, включая 3D-игры, и если вы пишете все это с нуля, может иметь смысл использовать что-то вроде XNA - на самом деле, есть хороший шанс, что так и будет.

Что касается коммерческих игр - RuneScape считается? Это может быть самой успешной Java-игрой.

Я думаю, что Джон Кармак сказал это лучше всего с:

Самая большая проблема в том, что Java очень медленная. На уровне чистого процессора / памяти / дисплея / связи большинство современных мобильных телефонов должны быть значительно лучше игровых платформ, чем Game Boy Advanced. Благодаря Java на большинстве телефонов у вас остается примерно столько же ресурсов процессора, как у оригинального ПК IBM с тактовой частотой 4,77 МГц, и паршивый контроль над всем. [... snip ...] Пиши один раз, беги куда угодно Ха. Hahahahaha. Мы сейчас тестируем только на четырех платформах, и ни одна пара не обладает такими же причудами. Все коммерческие игры настраиваются и компилируются индивидуально для каждой (часто более 100) платформы. Портативность не является оправданием для ужасной производительности.

( источник )

Конечно, он говорил о мобильных платформах, но я обнаружил, что подобные проблемы с Java в целом происходят из C ++. Я скучаю по возможности распределять память в стеке / куче на своих собственных условиях.

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

Все матричные умножения и аффинные векторы, с которыми вам нужно иметь дело, гораздо проще понять, если они находятся в правильно сформированных математических выражениях, а не в объектно-ориентированных выражениях, таких как

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

Это просто ужасно. Математика не должна выглядеть так.

Я думаю, что в .NET было (есть) много тех же проблем, что и в Java. Microsoft только что продвинулась в маркетинге для разработчиков с XNA :-)

Незначительные очки в первую очередь:

• любое повышение производительности от Java является гипотетическим. Синтаксис почти идентичен C ++, так что вы действительно просто экономите на управлении памятью и стандартных библиотеках. В библиотеках есть немного, чтобы предложить игры разработчикам и управление памятью является спорным вопросом из-за сборки мусора.

• кроссплатформенность «бесплатно» не так хороша, как вы думаете, потому что немногие разработчики хотят использовать OpenGL, а нескольким ключевым платформам, вероятно, не хватает хорошей реализации Java или оболочек для их собственных библиотек, будь то для графики, аудио, сетей и т. д.

Но в основном проблема заключается в обратной совместимости. Разработчики игр перешли на C ++ из C и в C из сборки только потому, что путь миграции был плавным. Каждый тесно взаимодействует с предыдущим, и весь их предыдущий код можно было использовать на новом языке, часто с помощью одного компилятора. Поэтому миграция была настолько медленной или быстрой, насколько вам понравилось. Например, некоторые из наших старых заголовков, используемых сегодня, все еще имеют #ifdef WATCOMCв, и я не думаю, что кто-то использовал компилятор Watcom здесь в течение десятилетия или более. В старый код вкладываются огромные средства, и каждый бит заменяется только по мере необходимости. Этот процесс замены и обновления битов и кусочков из одной игры в другую далеко не столь практичен, если вы перешли на язык, который изначально не взаимодействует с вашим существующим кодом. Да, совместимость с C ++ / Java возможна, но очень непрактична по сравнению с простым написанием «C с небольшим количеством C ++» или встраиванием asm-блоков в C.

Чтобы должным образом заменить C ++ в качестве языка выбора разработчиков игр, он должен сделать одну из двух вещей:

1. Быть легко совместимым с существующим унаследованным кодом, таким образом сохраняя инвестиции и поддерживая доступ к существующим библиотекам и инструментам, ИЛИ
2. Достаточно наглядно продемонстрировать, что повышение производительности труда означает, что затраты на переписывание всего собственного кода (или переработку интерфейсов в повторно используемые компоненты, которые можно использовать на этом языке) более чем покрыты.

Субъективно, я не думаю, что Java отвечает ни одному из них. Язык более высокого уровня может встретиться со вторым, если кто-то достаточно смел, чтобы быть пионером. (EVE Online, вероятно, лучший пример того, как Python можно использовать, но который использует форк основного языка Python, много компонентов C ++ для производительности и даже для довольно нетребовательной игры в современных условиях.)

Я играю в Sims 3, и я немного покопался. Графический движок - C ++, а скриптовый и поведенческий - C # / Mono. Таким образом, в то время как C ++ предназначен для битов, критичных ко времени, другие вещи, такие как .interaction, игровая логика, AI - это объектно-ориентированный управляемый язык.

• Есть ли хорошие порты игровых движков / библиотек?
• Многие разработчики на C / C ++, особенно разработчики под Windows (где написано большинство коммерческих игр), знакомы с Visual Studio. В IDE нет сравнения.
• В целом, Java была продана предприятиям из-за ее строгой типизации и восприятия отсутствия проблем с управлением памятью.
• И да, Java все еще страдает от ощущения, что она медленная, управление памятью плохое, а для игр она, вероятно, не подходит для этой задачи. Как указано в некоторых других ответах, сборка мусора просто не приведет к ее сокращению, когда вы работаете с высокопроизводительными требованиями в реальном времени. Видеоигры расширяют возможности процессоров и графических процессоров.

Одна из главных причин, по которой Java и другие языки виртуальных машин не используются в играх, связана с сборкой мусора. То же самое относится и к .NET. Сборка мусора прошла долгий путь и прекрасно работает в большинстве типов приложений. Однако, чтобы выполнить сборку мусора, вам нужно приостановить и прервать приложение, чтобы собрать мусор. Это может вызвать периодическую задержку, когда происходит сбор.

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

Дело не в том, что Java медленная. Дело в том, что Java плохо справляется с задачами в реальном времени.

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

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

Проблема производительности является первой причиной. Когда вы видите вид гипероптимизированного кода C ++, который есть в движках Quake ( http://www.codemaestro.com/reviews/9 ), вы знаете, что они не будут тратить свое время на виртуальную машину.

Конечно, могут быть некоторые .NET-игры (какие? Мне интересно. Есть ли какие-нибудь действительно ресурсоемкие / интенсивно использующие GPU?), Но я думаю, это больше, потому что многие люди являются экспертами в технологиях MS и следили за Microsoft, когда они запускали их новые технологии.

Да, и кроссплатформенность просто не предназначена для компаний, занимающихся видеоиграми. Linux занимает лишь около 1% рынка, Mac OS - еще несколько%. Они определенно думают, что не стоит отказываться от технологий и библиотек, предназначенных только для Windows, таких как DirectX.

Вы можете спросить, почему веб-приложения также не написаны на C или C ++. Сила Java заключается в его сетевом стеке и объектно-ориентированном дизайне. Конечно, в C и C ++ это тоже есть. Но о более низкой абстракции. В этом нет ничего негативного, но вы не хотите изобретать велосипед каждый раз, не так ли?

Java также не имеет прямого доступа к оборудованию, что означает, что вы застряли с API-интерфейсом любых фреймворков.

Я думаю, неправильные представления о производительности и плохой оптимизации JVM. Я говорю неправильное представление о производительности, потому что есть некоторые порты Java игр C ++, которые работают быстрее, чем их аналоги из C ++ (см. Jake 2). Реальная проблема, IMHO, заключается в том, что многие Java-программисты не уделяют столько внимания высокопроизводительной производительности, сколько простоте использования и понятности / поддерживаемости кода. Со стороны C / C ++ вы, по сути, кодируете на языке ассемблера чуть более высокого уровня, и он настолько близок к аппаратному обеспечению, насколько вы можете получить без написания на ассемблере или прямом машинном коде.

Список игровых движков в Википедии перечисляет множество игровых движков вместе с языком программирования, на котором они написаны.

В списке есть несколько игровых движков Java.

Нажав на некоторые ссылки, вы увидите примеры игр и демонстраций, написанных на Java. Вот пара:

• Ardor3D
• Байтонское программное обеспечение

Для определенных игр и ситуаций компромиссы Java могут быть приемлемыми.

У .NET определенно есть те же проблемы, что и у Java, когда речь идет о высокой производительности 3D. Microsoft также вложила гораздо больше времени и денег в разработку библиотек, когда дело доходит до работы с тяжелыми трехмерными операциями.

(... лично я также думаю, что они имели дело с магией между DirectX и .NET)

1. Java работает медленно, большая часть тяжелой работы не обрабатывается графическим процессором. Все еще анимация, физика и ИИ поражают процессор, и все это занимает очень много времени.

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

3. Многие из более опытных программистов в игровой индустрии использовали C и C ++ задолго до того, как Java стала популярной. Два вышеприведенных пункта могут способствовать этому, но я ожидаю, что многие профессиональные программисты игр просто не очень хорошо знают Java.

4. Чужое замечание о промежуточном программном обеспечении выше было хорошим, поэтому я добавляю его к своему ответу. Существует много устаревшего кода и промежуточного программного обеспечения, написанного специально для связи с C / C ++, и в последний раз я проверял, что Java не обладает хорошей совместимостью. Использование Java для большинства компаний подразумевало бы выброс большого количества кода, большая часть которого была оплачена тем или иным способом.

На самом деле, управляемый код вполне может делать 3d-игры, проблема в задних движках. В течение короткого периода времени в .Net появилась управляемая оболочка DirectX для DirectX 9 от Microsoft. Это было до абстракции, сейчас XNA.

Предоставляя полный доступ к API DirectX, .Net игры работают на ура. Лучший пример, который я знаю, это www.entombed.co.uk, который написан на VB.Net.

К сожалению, на стороне Java его серьезно не хватает - главным образом по той причине, что DirectX не доступен для Java, а программисты игр знают и понимают API DirectX - зачем изучать еще один API, когда вы вернетесь к DirectX?

Игровой маркетинг - это коммерческий процесс; издатели хотят, чтобы их инвестиции приносили измеримую прибыль с низким уровнем риска. Как следствие, основное внимание обычно уделяется технологическим уловкам (за исключением), которые покупатели будут покупать для получения надежной отдачи - это, как правило, поверхностные визуальные эффекты, такие как блики на объективе или более высокое разрешение. Эти эффекты надежны, потому что они просто используют увеличение вычислительной мощности - они используют аппаратное обеспечение / увеличение закона Мура. это подразумевает использование C / C ++ - java обычно слишком абстрагирован от аппаратного обеспечения, чтобы использовать эти преимущества.

Я предполагаю, что скорость - все еще проблема. Кроссплатформенность будет проблемой, не так ли, поскольку вы не знаете, какая 3d карта доступна, когда пишете код? Есть ли в Java что-нибудь для поддержки автоматического обнаружения 3d-возможностей? И я предполагаю, что есть инструменты для облегчения портирования игры между wii, xbox и ps3, но я бы поспорил.

PS3 имеет Java, через поддержку Blue Ray. Проверьте сайт bd-j.

Даже игры, написанные на платформе .Net, часто сильно оптимизированы для такой скорости, как прямой доступ к памяти и шине. .Net позволяет использовать C / C ++ и смешивать его с языками более высокого уровня, такими как C #.

Студии по разработке игр часто работают в тесном сотрудничестве с поставщиками оборудования, которые предоставляют доступ к интерфейсам своих продуктов низкого уровня. Это мир, где вы должны использовать ASM и C для связи с устройством. Виртуальная среда будет тормозить эти части программы.

Во всяком случае, современные 3D-игры на самом деле используют языки более высокого уровня. Часто вы найдете игровую логику, написанную на таких языках, как Lua или Python. Но ядро ​​(ввод / вывод, потоки, планирование задач) типичной трехмерной игры будет написано на языках низкого уровня в течение следующих 25 лет, или поскольку длинные устройства сами не позволяют абстрагирование и виртуализацию (что произойдет).

Я согласен с другими постами об использовании элементов существующей / лицензированной кодовой базы, производительности и т. Д.

Одна вещь, которую я хотел бы добавить, состоит в том, что с виртуальными машинами сложно справляться с неприятными уловками DRM.

Кроме того, я думаю, что есть компонент hubris, где руководители проектов думают, что они могут создавать стабильный / надежный код на C ++ со всеми преимуществами, такими как полный контроль над своими инструментами и ресурсами, НО без всех негативных факторов, которые усложняют и подавляют их конкуренцию, потому что «мы» умнее их ».

Runescape от Jagex написан на Java, тэг «видеоигры» может и не относиться конкретно к онлайн-игре, но у него есть достойные последователи.

Об этом уже много говорили, даже в вики можно найти причины ...

• C / C ++ для игрового движка и всего интенсивного.
• Lua или Python для скриптинга в игре.
• Java - очень-очень плохая производительность, большое использование памяти + она недоступна на игровых приставках (она используется для некоторых очень простых игр (да, здесь есть Runescape, это не Battlefield, не Crysis или что-то еще) только потому, что есть много программистов, которые знают этот язык программирования).
• C # - использование большой памяти (используется для некоторых очень простых игр только потому, что есть довольно много программистов, которые знают этот язык программирования).

И я слышу все больше и больше Java-программистов, которые пытаются убедить людей в том, что Java не медленная, она не медленная для рисования виджета на экране и рисования некоторых символов ASCII на виджете, для получения и отправки данных по сети (и это рекомендуется использовать его в этих случаях (манипулирование данными сети) вместо C / C ++) ... Но это чертовски медленно, когда речь идет о серьезных вещах, таких как математические вычисления, распределение / манипулирование памятью и многое другое.

Я помню статью на сайте MIT, где они показывают, что C / C ++ может делать, если вы используете функции языка и компилятора: матричный множитель (2 матрицы), 1 реализация на Java и 1 реализация на C / C ++ с функциями C / C ++. и активация соответствующей оптимизации компилятора, реализация C / C ++ была ~ 296 260 раз быстрее, чем реализация Java.

Я надеюсь, теперь вы понимаете, почему люди используют C / C ++ вместо Java в играх, представьте себе Crysis на Java, в этом мире не было бы компьютера, который мог бы справиться с этим ... + Сборка мусора работает нормально для виджетов, которые только что уничтожили изображение но он все еще там кешируется и требует очистки, но не для игр, наверняка, у вас будет еще больше лагов при каждой активации сборки мусора.

Изменить : потому что кто-то попросил статью, здесь я искал в веб-архиве, чтобы получить это, я надеюсь, что вы удовлетворены ... MIT Case Study

И добавить, нет, Java для игр все еще ужасная идея. Всего несколько дней назад крупная компания, которую я не назову, начала переписывать свой игровой клиент с Java на C ++, потому что очень простая игра (с точки зрения графики) отстала и обогревала ноутбуки i7 мощными видеокартами nVidia GT 5xx и 6xx поколения ( дело не только в nVidia, дело здесь в том, что это мощные карты, которые могут обрабатывать на настройках Макса большинство новых игр и не справляются с этой игрой), а потребление памяти составило ~ 2,5 - 2,6 ГБ ОЗУ. Для такой простой графики нужен зверь машины.