Чи хороший вибір Java для кросплатформних ігор? [зачинено]

Я хочу створити гру на Java і хотів би, щоб вона працювала в Windows, Linux та Mac. Я впевнений, що C # - це поганий вибір для цього, і я не маю достатнього досвіду роботи на C або C ++. Я хочу триматися подалі від Flash. Тому, чи хороший вибір для мене Java? Здебільшого я використовую C # і думаю, що Java схожа, тому я припускаю, що це буде не так складно навчитися. Але це досить швидко? Чи є мова, більш підходяща для моїх потреб, ніж Java?

Java надзвичайно підходить для написання кросплатформних ігор. Основні переваги:

• Переносимість - загалом ви можете написати гру на Java і очікувати, що вона працює без змін на більшості платформ. Це, мабуть, самий портативний варіант будь-якої мови - C / C ++ - це інший дуже портативний варіант, але його потрібно перекомпілювати для кожної платформи, і в багатьох випадках бібліотеки мають особливості платформи, що обмежують портативність.
• Продуктивність - Java-код, якщо він написаний добре, буде виконувати як і будь-яку іншу мову, включаючи C / C ++. Компілятор JVM JIT надзвичайно хороший. Ви можете написати якісну, вдалу гру на Java (наприклад, Minecraft).
• Бібліотеки - для Java існує величезний спектр бібліотек, які охоплюють практично всі функції, які ви можете захотіти в іграх, від мережевих мереж, графіки до звуку до AI. Більшість бібліотек Java є відкритим кодом.

Основне рішення, яке вам доведеться прийняти, - це те, які рамки GUI ви збираєтеся використовувати. Існує досить багато різних варіантів, але найбільш відомими є:

• jMonkeyEngine - повноцінний 3D-двигун. Якщо ви хочете зробити 3D-гру, це, мабуть, ваш найкращий вибір - містить безліч ігрових механізмів, таких як графіки сцен, генерація місцевості тощо.
• LWJGL - більш низька бібліотека з прямим доступом до OpenGL. Ймовірно, вам сподобається, якщо ви хочете отримати максимальну продуктивність і не проти написати багато свого двигуна з нуля.
• Swing - має перевагу в тому, що він є надзвичайно портативним і входить до виконання Java, тому не потребує додаткової залежності. Це добре для не графічно інтенсивних 2D-ігор (стратегічні ігри, карткові ігри тощо)
• Slick - 2D бібліотека ігор на базі LWJGL. Можливо, це добре, якщо ви хочете написати 2D гру, але все ж потрібні хороші графічні показники (зйомки, знімання платформних ігор тощо)
• JavaFX - призначений для багатих інтернет-додатків, приблизно як Flash. Має безліч акуратних функцій, які були б гарні для ігор, хоча я ще не бачив, щоб це багато використовувалося. Зокрема, JavaFX 2.0 виглядає досить перспективно.

Основні недоліки Java для ігор справді є навколо «крайових справ», які, ймовірно, не торкнуться вас, але стосуються деяких класів гри:

• Наявність 3D-двигунів - хоча перераховані вище інструменти та двигуни хороші, вони все ще не дуже дорівнюють до рівня C / C ++ двигунів, як Unreal Engine, який використовуються професійними ігровими компаніями. Тож Java, можливо, не стане вашим першим вибором, якщо ви намагаєтесь розробити великий FPS з багатомільйонним бюджетом - C / C ++ все одно виграє тут.
• Затримка збору GC у смітті Java - загальна користь, але це може спричинити невеликі паузи, коли трапляються цикли GC. Це стає набагато краще з новими JVM з низькою затримкою, але все ж може бути проблемою для ігор з дуже низькими вимогами до затримки (можливо, шутери від першої особи). Вирішення проблеми полягає у використанні бібліотек з низькою затримкою, таких як http://javolution.org/ , однак, схоже, ці орієнтовані більше на системи торгівлі на високих частотах або в режимі реального часу, а не на ігри.
• Відсутність можливості використовувати оптимізації низького рівня - хоча компілятор Java JIT неймовірно хороший, він все ще виконує деякі обмеження, яких ви не можете уникнути (наприклад, перевірка меж на масивах). Якщо вам дійсно потрібно отримати доступ до рідного машинного коду, щоб оптимізувати подібні речі, то, напевно, ви віддасте перевагу C / C ++ над Java.

Зауважте, що є також кілька варіантів розгортання, які слід врахувати:

• Applet - працює в браузері, що дуже зручно для користувачів, однак аплети досить обмежені в тому, що вони можуть робити з міркувань безпеки. Зауважте, що ви можете підписати аплети, щоб отримати додаткові привілеї безпеки, хоча це спричинить дещо страхітливий запит для більшості користувачів.
• Java Web Start - краще для більш складних ігор, які потребують повного локального завантаження, а також для доступу до локальних системних ресурсів. Це також працює досить незалежно від платформи. Мабуть, найкращий маршрут для гри середнього розміру або щось, що потребує уникнення обмежень безпеки аплетів.
• Завантаження інсталятора - Ви можете написати інсталятор для гри на Java так само, як і для будь-якої іншої мови. Налаштувати трохи більше роботи над налаштуванням і тестуванням, оскільки інсталятори, як правило, мають деякі особливості платформи.
• Веб - ви можете написати веб-додаток HTML5 і використовувати силу Java виключно на стороні сервера. Варто врахувати багатокористувацьку веб-гру.

Нарешті, також варто розглянути деякі інші мови JVM - у них є всі переваги платформи Java, перелічені вище, але деякі вважають їх кращими мовами, ніж сама Java. Scala, Clojure та Groovy були б найвидатнішими, і всі вони можуть використовувати перераховані вище інструменти та бібліотеки Java.

Майнкрафт і блоки, які мають важливе значення, вбудовані в Java, так що так, це дуже добре для ігор. Основна проблема, з якою ви збираєтеся зіткнутися під час використання Java, - це перенесення на мобільні платформи, якщо ви вирішите піти цим маршрутом і написати нативну програму. Android - це свого роду франкенстейн Java SE з окремою бібліотекою. RIM's Blackberry використовує Java ME. iOS теоретично може бути запрограмований на Java, хоча об'єктив-C, ймовірно, буде кращим вибором для цієї платформи.

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

Найбільш очевидний і найменш стійкий спосіб - використовувати комбінацію HTML5 + javascript. Будь-яка програма чи гра, створена за допомогою цього, працюватиме майже на кожному пристрої та веб-переглядачі.

Перевага : - Вам потрібна нульова конфігурація для того, щоб ваша гра працювала на різних платформах і пристроях.

ПРИМІТКА: - Я бачив кілька ігор, які будуються за допомогою вищезазначених технологій, але вони були меншими за ростом. Але, я думаю, якщо з молока можна зробити масло, то сир не є неможливим

Ви можете використовувати Scala та схему Bigloo на Eclipse, щоб використовувати JVM для напруженого коду або паралельних дій всередині вашої гри Java.

Завдяки дизайну шаблонів та UML2 ви також можете захистити код за допомогою OCL, все це на Topcased.org.

Оволодіння цими інструментами потребує часу, але вони є основою Java, база, яка підштовхне вас до вершини.

Коротка відповідь: ні.

Java не генерує двійковий виконуваний файл, а лише байт-код, як це робить C # (CLI), і це не дуже добре для серйозного бізнесу у "відкритих середовищах" з двох основних причин:

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

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

Можливо, на професійному рівні ви можете знайти щось, що може порушити таке правило, як dev-Kit, який може перетворити всі C # заяви в збірний код для реальної машини світу, але якщо такий підхід не в картках, до яких ви змушені практично враховуйте лише C і C ++ для своєї розробки, коли ви прагнете продавати свій товар у відкритому середовищі.

У мобільних пристроях речі дещо відрізняються, оскільки вони є "закритим середовищем", навіть Android суттєво закритий, враховуючи той факт, що джерела ПЗУ в реальному світі зазвичай не доступні для публіки, Android може вважатися відкритим кодом, але 99 % ROM на фактичних пристроях не є. У цьому випадку ви не можете занадто сперечатися, все вже встановлено для вас, і кожна платформа має свою мову, як всі знають.

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