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

Я не розробник ігор чи нічого, але знаю, що Java не дуже широко використовується для розробки ігор. Java повинна бути досить швидкою для більшості ігор, тож де улов? Я можу придумати деякі причини:

• Відсутність розробників ігор з досвідом роботи на Java
• Відсутність хороших рамок розвитку ігор
• Програмісти не хочуть сприймати Java як мову програмування ігор. Більшість лише приймає C ++ як це?
• Немає підтримки ігрових консолей (хоча ринок ПК все ще існує)

Звичайно, це може бути щось інше. Чи може хтось, хто знає бізнес краще за мене, пояснити, чому Java не набирає обертів, коли справа стосується розвитку ігор?

Кілька причин:

• За старих часів вам потрібен був "прямий доступ" для продуктивності та інтерфейсу користувача. Це передує таким мовам VM, як Java та C #.
• Більшість консолей (наприклад, 360, PS3) не мають JVM, тому код не можна повторно використовувати з версії ПК. Набагато простіше скласти код C ++ для підтримки різних пристроїв.
• Більшість основних ігрових двигунів (наприклад, Unreal) мають C ++ прив’язки. Є кілька роз'ємів Java (наприклад, для OpenGL), але нічого подібного немає.
• Для ігор на ПК DirectX насправді не має сильної підтримки Java (якщо вона взагалі є).
• Ігри на веб-основі працюють у JavaScript або Flash. Ви можете писати їх на Java, використовуючи такі речі, як GWT.
• В iPhone працює варіант Objective-C.

В даний час Java в основному використовується в іграх для Android, просто тому, що це основна мова для цієї платформи.

Технічні причини:

• Більшість найкращих ігрових технологій 3D написані на C / C ++. Це велика справа, оскільки більшість розробників ігор не хочуть йти на компроміси зі своїм 3D-механізмом, але також не хочуть писати його з нуля. У Java є jMonkeyEngine, який є відкритим кодом і насправді дуже хороший, але він все ще не може конкурувати з Unreal Engine .
• У деяких дуже рідкісних ситуаціях є переваги в тому, щоб наблизитись до металу " мовою С" або мовою складання, спеціально для доступу до спеціальних апаратних функцій. Сьогодні це не так важливо, але професійні розробники ігор все ж люблять мати можливість .....
• У Java є зібране сміття , керований час виконання. У 99% випадків це величезна перевага, але це, безумовно, робить кодування простішим і менш схильним до помилок і є однією з головних причин того, що Java настільки популярна. Однак це призводить до випадкових проблем із затримкою для ігор, оскільки цикли вивезення сміття можуть спричинити помітні паузи. Це стає менш проблемою з новими JVM з низькою затримкою, але все ще залишається проблемою для графічно інтенсивних ігор, де підтримка високого FPS має вирішальне значення.

Нетехнічні причини:

• Будинки професійного розвитку ігор значно інвестують у C / C ++ навички та технології. Це створює величезну кількість інерції .
• Багато в чому ірраціональне сприйняття того, що Java повільна. Можливо, це правда в 90-х, зараз точно не правда - ви, звичайно, можете написати вигідну комерційну 3D-гру з Java ( Runescape будь-хто? Або як щодо Minecraft ?)
• Досить справедливе уявлення, що Java більше орієнтована на бізнес-додатки та Інтернет, а не ігри. Це може змінитись із ростом мобільних пристроїв та потребою в більшій розробки платформ, але це, безумовно, актуально в даний час.

Цікаво, що є також кілька вагомих причин, чому розробники ігор повинні розглянути Java:

• Переносність - у міру того, як кількість цільових платформ збільшується, Java стає все більш привабливою завдяки своїй незрівнянній здатності створювати справді кросплатформні бінарні файли
• Бібліотечна екосистема - за дуже важливим винятком 3D-ігрових двигунів, Java має найкращий спектр бібліотек загалом на будь-якій платформі. Мережа, звук, AI, обробка зображень, сховища ключів / цінностей, ви називаєте тему, і, ймовірно, існує бібліотека Java з відкритим кодом для неї.
• Розробка серверної сторони - Java - це чудовий ланцюг / платформа для сервера, і оскільки більшість ігор, що включають в себе масово багатокористувацькі елементи, сторона сервера стає все більш важливою. Java в Linux виглядає тут досить виграшно як платформа.
• JVM - це, мабуть, найкраще розроблене середовище виконання VM у світі, з фантастичним збиранням сміття, компілятором JIT, підтримкою одночасності тощо. Це лише покращиться, і оскільки розробники ігор все частіше починають використовувати динамічні мови в своїх іграх, які вони захочуть найкраще можливе середовище виконання.
• Інші мови JVM - Java є надійним робочим конем, але справжня інновація відбувається з новими мовними програмами JVM (зокрема, Scala, Clojure). Ці мови отримують усі переваги платформи Java / JVM, плюс вони є надзвичайно потужними сучасними мовами.

Гаразд, у цій темі багато дезінформації.

Я надзвичайно добре знаю ігровий бізнес , займаючись ним 25 років. Я також знаю Java в іграх надзвичайно добре, бо був технічним євангелістом Java від Java Ігр Sun та читав лекції експерта з програмування продуктивності Java.

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

Що стосується використання пам'яті, у Java є деяка надмірна голова. HelloWorld - програма 4K в Java. Але ця накладні витрати є досить безглуздими в сучасних системах з декількома ГБ. Нарешті, у Java більше часу на запуск. Я б не рекомендував використовувати Java для коротких утиліт виконання, таких як команди командного рядка Unix. У цих випадках запуск буде домінувати над вашою продуктивністю. У грі, однак, це досить незначно.

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

Що стосується прямого доступу до пам'яті, у Java це було довгий час; з Java 1.4 у вигляді Native Direct Byte Buffers. Біт-подвійність у Java може бути дещо прикрою через відсутність неподписаних цілих типів, але робочі раунди всі добре відомі і не дуже важкі.

Хоча справжня Java ніколи не мала Direct3D-прив'язки, це тому, що технології Java прагнуть до портативності. Він має ДВІ прив'язки OpenGL (JOGL та LWJGL) та прив'язку OpenAL (JOAL) та переносну вхідну прив'язку (JInput), що підключається під кришкою до DirectInput в Windows, HID Manager на OSX та прив’язку Linux (я забуваю, які).

Це правда, що жоден повний ігровий движок не демонстрував Java, так як, скажімо, Unity, був показаний C #, і це слабкість у незалежному просторі. З іншого боку, існували два хороших сценарії APIS на рівні сцени, які повністю переносилися на платформу для Windows, OSX та Linux. Обидва написані Джошем Слаком, перший називався двигуном JMonkey, а другий - Ardor3D.

У верхньому плакаті виправдано, що дві найбільші речі, що стримували Java в розробці ігор, - це забобони та портативність. Останнє було найбільшим питанням. Хоча ви могли написати гру Java та відправляти її в Windows, OSX та Linux, ніколи не було консолі VM. Це було пов'язано із сумарною невмілістю середнього менеджменту ВС. Мало хто з нас, що працювали над Java в іграх, насправді мав угоди з Sony не менше 3 разів, щоб отримати VM на Playstation, і всі 3 рази середнє управління Sun вбило його.

Хоча Sun фліртував із клієнтськими технологіями, справа в тому, що управління Sun ніколи не отримувало споживчих товарів. Ось чому Java як клієнтська мова від Sun ніколи не виходила в будь-якій формі, і чому Google і Dalvik (Android-java-подібний VM) потребували Google, щоб досягти успіху на платформі Java де завгодно.

І тому я сьогодні кодую ігри на C #. Тому що Mono поїхала туди, куди керівництво Sun відмовилося.

Java чудово підходить для ділової логіки, серверів та незалежних від платформи кодів, які повинні надійно працювати. Є кілька факторів, чому Java часто не використовується в іграх:

• перевірка меж та інші механізми безпеки (гранична різниця в роботі в ці дні)
• перетворення між структурами даних C ++ і структурами даних Java (не можна просто копіювати пам'ять між буферами)
• багато книг та навчальних посібників слідкують за натовпом, тому важко знайти інформацію про розробник ігор, що не стосуються C ++
• основні бібліотеки графіки (DirectX та OpenGL) та багато позаштатних двигунів базуються на C / C ++
• багато ігор намагаються запустити якомога швидше, щоб вони могли додати більше візуально привабливих функцій

Нелегко працювати з бібліотеками C ++ з мов байт-кодів, таких як Java (написання шару JNI) та .net (безліч атрибутів маршалінгу / демарширування, api / структура). Тож це додає зовсім небагато роботи за малу користь.

Побічна примітка: деякі ігрові сервери використовують Java.

Подібний пост тут : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java не досить швидкий для більшості ігор. Це набагато повільніше, ніж використання C ++ / Assembly, що є стандартом. Це та сама причина, що більше розробки ігор не робиться за допомогою C # або VB. Розробникам ігор потрібно і планувати кожен останній тактовий цикл, щоб вони могли взяти на роботу такі речі, як фізичні обчислення, логіка AI та взаємодія з оточенням.

Для більш простих ігор Java може бути використана досить ефективно. Якщо ви хочете створити клон Tetris або Bejeweled, або щось інше такого рівня деталізації, тоді Java буде добре працювати. Але Java не може створити ігри, такі як Halo, Medal of Honor, Command & Conquer тощо, і зробити її відтворюваною. Принаймні, як це існує сьогодні.

І причини, які ви перераховуєте у своєму запитанні, також дійсні. За винятком, на мою думку, відсутності розробників ігор з досвідом Java. Багато ігор на телефонах та інших портативних пристроях написано на Java (включаючи більшість ігор для Android), а деякі ігри є досить відмінними. Тож я думаю, що існує гідна і зростаюча база розробників ігор з знаннями Java.

Думка змінюється на здатності використовувати ці мови вищого рівня для деяких більш досконалих ігор. Наприклад, одна з моїх улюблених ігор, тренажер Auran's Train Simulator, написана великими порціями на C #, і вона працює досить добре. Тож база зростає і буде продовжувати розвиватися.

Сучасні ігри - це все, що стосується 3D графіки, яка відбувається в апараті спеціального призначення.

Ще в 2002 році Джейкоб Марнер у своєму звіті "Оцінка Java для розвитку ігор" виявив, що Java досить зручна для ігор, за винятком найбільш залежних від продуктивності частин, а завдяки надійності мови та основного JVM це дешевше зробити це так.

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

Моя особиста думка, що з тим прогресом, який відбувся з тих пір, особливо в 3D-графіці, і з відмінними прив’язками до OpenGL та ін., Цей недолік значно менше виражений в ці дні.

Звідси проблема повинна бути в іншому місці. Ймовірною причиною є розмір часу виконання Java (що набагато менше проблем в наші дні з мульти DVD-іграми) та інша інерційність існуючого коду. Сумно крихко починати працювати з власним кодом на Java. Третя причина - те, з чим знайомі розробники зірок, які займаються іграми. Четверте - чи взагалі доступна Java на платформі.

Одне, напевно, однозначно - більшість ігор перетворюються на сценарій замість того, щоб все було записано в C-коді з самого початку, і ви хочете найкращого виконання під мовою сценарію. У наші дні це по суті означає або CLR, або JVM.

Розробники ігор люблять бути близько до металу і часто записують свої щільні внутрішні петлі в зборі. Java не пропонує однакового рівня можливої ​​продуктивності, як з точки зору постійної швидкості, так і з використанням пам'яті (запуск JIT приймає своє значення).

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

Я би на хвилину дивився на це з іншого напрямку. Розробка ігрового двигуна (наприклад) - велика робота. Кому було б достатньо користі від розвитку одного, щоб вкласти час і сили для цього?

Більшість очевидних кандидатів на рамкову розробку в / для Java (наприклад, IBM, Oracle), схоже, не мають інтересу до ігор. Очевидні кандидати на розробку ігор (наприклад, Id, EA), схоже, не менш зацікавлені в Java.

Майже єдиним кандидатом, про який я можу подумати, це здається абсолютно розумним - Google. Основною мовою розробки для Android є Java, і заохочувальна розробка ігор для Android може забезпечити реальну перевагу для платформи.

Наскільки я знаю, вони цього ще не зробили (поки що?), Що залишає досить серйозні межі майже для будь-кого іншого. Без особливих труднощів у сучасних, високопродуктивних ігрових двигунах використовувати розробку на Java - це зовсім небагато додаткової роботи, з (як мені здається) невеликою перспективою для отримання великої користі в обмін на цю додаткову роботу.

Питання нарівні з тим, щоб задати щось у рядках:

Що краще для живлення вашого автомобіля, човнового двигуна або реактивного двигуна.

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

Java не була створена з урахуванням розробки ігор, Java стала мовою "для Інтернету".

Що стосується розробки ігор, Sun насправді не підтримує Java як мову розробки ігор, як підтримує Microsoft C #.

Я думаю, що відсутність переконливих рамок розвитку ігор - це те, що насправді вбило Java в цьому аспекті.

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

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

Для деяких людей причина не має нічого спільного зі швидкістю, бібліотеками чи доступністю. Це просто через саму мову. Деякі люди просто не люблять мову Java. Інші люди бажають використовувати свою улюблену мову програмування, а не використовувати Java для створення ігор.

Звичайно, це може бути щось інше. Чи може хтось, хто знає бізнес краще за мене, пояснити, чому Java не набирає обертів, коли справа стосується розвитку ігор?

Це мова інтерпретації, тобто повільна. Ви маєте справу з графічною та графічною карткою, яка є апаратною. Яка гарна мова для роботи з обладнанням? Ну, C ++, це досить низький рівень, і ви маєте справу з покажчиками та чим завгодно.

Якщо ви хочете викачати шалену графіку, як криза, і те, що ви не збираєтеся робити для цього Java.

Мало того, що Oracle володіє Java, думка про те, що компанія може подати в суд на вас, не дуже сміливо. Особливо, коли ви хочете створити власного інтерпретатора для JAVA для націлювання на ігри, не отримуючи позовів через роздробленість FUD.