Чому лише кілька відеоігор написано на Java? [зачинено]

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

Це через продуктивність? Якщо так, чи не все-таки більшість важких підйомів зробить GPU?

Світ розвитку ігор є кумедним: з одного боку, вони часто швидко сприймають нові ідеї, а з іншого - вони ще в кам'яному віці.

Правда, рідко виникає такий великий стимул для переходу на .NET / Java / що-небудь інше, ніж C / C ++.

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

Також у C ++ вже існує багато застарілого коду. Якщо код з попередніх проектів можна повторно використовувати (скажімо, якщо ви пишете продовження), це вважає ще більше на користь дотримуватися тієї ж мови, а не переписувати її новою мовою (тим більше, що ви, ймовірно, повторно введіть тонна помилок, які вам потрібно буде витратити час на прасування.

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

Що стосується вивезення сміття, то це може бути проблемою. Проблема не стільки в тому, що вона існує, скільки в тому, як вона працює - сміттєзбірник ОБОВ'ЯЗКОВО не блокує (або принаймні гарантує лише блокування дуже коротко), оскільки просто неприпустимо, щоб гра замерзла на 10 секунд, поки він сканує всю виділену пам'ять, щоб побачити, що можна звільнити. Я знаю, що у GC'ing, як правило, Java задихається, коли це майже не вистачає пам’яті (а для деяких ігор там буде).

Ви також трохи обмежені в тому, що можете робити: ви не можете повною мірою експлуатувати апаратне забезпечення через надмірні витрати часу. Уявіть, що Crysis написаний на Java ... навіть якщо це єдина видима різниця, вона просто не буде однаковою (я також впевнений, що вам потрібен Core i7 для її запуску.)

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

Що стосується комерційних ігор - чи вважається RuneScape ? Це, можливо, є найбільш вдалою грою на Java.

Я думаю, що Джон Кармак сказав це найкраще:

Найбільша проблема полягає в тому, що Java справді повільна. На чистому рівні процесора / пам'яті / дисплея / комунікацій більшість сучасних мобільних телефонів повинні бути значно кращими ігровими платформами, ніж ігровий хлопчик Advanced. У системі Java на більшості телефонів вам залишається приблизно потужність процесора оригінального 4,77 МГц IBM PC і невдалий контроль над усім. [... snip ...] Напишіть один раз запустити будь-де. Ха. Хахахахаха. Зараз ми протестуємо лише на чотирьох платформах, і жодна пара не має таких самих примх. Всі комерційні ігри налаштовуються та складаються індивідуально для кожної (найчастіше 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 ++ є для критично важливих для часу бітів, інші речі, такі як .взаємодія, логіка гри, 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 (які з них? Мені цікаво. Чи є справді інтенсивні CPU / GPU?), Але я думаю, що це більше, тому що багато людей є фахівцями в галузі MS-технологій і слідкують за Microsoft при запуску їх нова технологія.

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

Ви можете запитати, чому веб-додатки теж не записуються на C або C ++. Сила Java полягає в її мережевому стеку та об'єктно-орієнтованому дизайні. Звичайно, це має і C, і C ++. Але на нижній абстракції. Це нічого негативного, але ви не хочете кожен раз винаходити колесо, чи не так?

Java також не має прямого апаратного доступу, а це означає, що ви застрягли з API будь-яких рамок.

Помилковим уявленням про продуктивність та поганими оптимізаціями JVM можна було б припустити. Я кажу про помилки щодо продуктивності, оскільки є деякі Java-порти ігор C ++, які працюють швидше, ніж їхні C ++ (див. Джейк 2). Справжня проблема, IMHO, полягає в тому, що багато Java-програмістів не так зосереджені на ефективності кровоточивості, як на простоті використання та зрозумілості / ремонтопридатності коду. Що стосується C / C ++ сторони речей, які ви, по суті, кодуєте мовою збірки дещо вищого рівня та її приблизно наближеною до апаратних засобів, яку ви можете отримати, не записуючи в збірку або прямого машинного коду.

Список ігрових двигунів у Вікіпедії перелічує багато ігрових двигунів разом з мовою програмування, якою вони написані.

Перелічено кілька ігрових двигунів Java.

Клацнувши на деяких посиланнях, ви перейдете до прикладів ігор та демонстраційних програм, написаних на Java. Ось пара:

• Ardor3D
• Bytonic Software

Для певних ігор та ситуацій можливі компроміси на Java.

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

(... особисто я також думаю, що у них з'явилася нога, коли мова йде про магію між DirectX та .NET)

1. Java повільна, більшість важких підйомів не обробляється GPU. Ще є анімація, фізика та AI, які вражають процесор, і все це забирає багато часу.

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

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

4. Чужий пункт про проміжне програмне забезпечення вище був хорошим, тому я додаю це до своєї відповіді. Існує багато застарілого коду та програмного забезпечення, написаного спеціально для зв'язку з C / C ++, і останнє, що я перевірив, Java не має хорошої сумісності. Використання Java для більшості компаній передбачає викидання великої кількості коду, значна частина яких оплачена так чи інакше.

Насправді, за керованим кодом дуже можливо робити 3d ігри, проблема - це задні двигуни. З .Net протягом короткого періоду з'явилася обгортка Managed DirectX для DirectX 9 від Microsoft. Це було до абстракції, яка зараз є XNA.

Отримавши повний доступ до apx DirectX, ігри .Net - це задоволення. Найкращий приклад, про який я знаю, - це www.entombed.co.uk, написаний у VB.Net.

На жаль, з боку Java це серйозно не вистачає - головним чином з тієї причини, що DirectX недоступний для Java, а ігрові програмісти знають і розуміють програму DirectX api - навіщо вивчати ще один api, коли ви повернетесь до DirectX?

Ігровий маркетинг - це комерційний процес; видавці хочуть оцінити рентабельність низьких ризиків від своїх інвестицій. Як наслідок, акцент робиться, як правило, на технологічних приладах (за винятком), які споживачі купуватимуть для отримання надійної віддачі - це, як правило, поверхневі візуальні ефекти, такі як відблиски лінз або більша роздільна здатність. Ці ефекти є надійними, оскільки вони просто використовують збільшення процесорної потужності - вони експлуатують апаратне забезпечення / Закон Мура збільшується. це означає використання C / C ++ - java, як правило, занадто абстрагується від обладнання, щоб використовувати ці переваги.

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

PS3 має java, через підтримку синього променя. Перевірте сайт bd-j.

Навіть ігри, написані на платформі .Net, часто дуже оптимізовані для такої швидкості, як прямий доступ до пам'яті та шини. .Net дозволяє використовувати C / C ++ та змішувати його з мовами вищого рівня, такими як C #.

Студії розвитку ігор часто співпрацюють з постачальниками апаратних засобів, які забезпечують доступ до інтерфейсів своїх продуктів на низькому рівні. Це світ, де вам потрібно використовувати ASM та C для зв'язку пристроїв. Віртуальне середовище сповільнить ці програмні частини.

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

Я погоджуюся з іншими публікаціями про використання елементів попередньої / ліцензованої кодової бази, продуктивності тощо.

Хочеться додати одне, що важко виводити противні хитрощі DRM через віртуальну машину.

Також я думаю, що є компонент hubris, де керівники проектів думають, що вони можуть зробити стабільний / надійний код із C ++ з усіма перевагами, як, наприклад, абсолютний контроль над своїми інструментами та ресурсами, АЛЕ без усіх негативів, які ускладнюють і пригнічують конкуренцію, тому що "ми" re розумніші, ніж вони ".

Runescape by 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, не було б жодного комп’ютера в цьому світі, який міг би впоратися з цим ... + Збір сміття працює нормально для віджетів, які щойно знищили зображення але це все ще є кешоване там і його потрібно прибрати, але не для ігор, напевно, у вас буде ще більше відставань від кожної активації збору сміття.

Edit : Тому що хто - то попросив статті, тут, я шукав в веб - архіві , щоб отримати це, я сподіваюся , що ви задоволені ... MIT Case Study

І додати, ні, Java для ігор все ще жахлива ідея. Буквально кілька днів тому велика компанія, яку я не назву, почала переписувати їх ігровий клієнт з Java на C ++, оскільки дуже проста гра (з точки зору графіки) була відставанням та обігрівом i7 Ноутбуків з потужними відеокартами nVidia GT 5xx та 6xx покоління ( не тільки nVidia, справа тут у тому, що ця потужна карта, яка може працювати з налаштуваннями Макса більшості нових ігор і не може впоратися з цією грою), а споживання пам'яті склало ~ 2,5 - 2,6 ГБ оперативної пам’яті. Для такої простої графіки йому потрібен звір машини.