왜 게임 개발에 Java가 더 널리 사용되지 않습니까? [닫은]

저는 게임 개발자 나 다른 사람이 아니지만 Java가 게임 개발에 널리 사용되지 않는다는 것을 알고 있습니다. Java는 대부분의 게임에 충분히 빠르므로 어떻습니까? 몇 가지 이유를 생각할 수 있습니다.

• Java에 대한 전문 지식이없는 게임 개발자 부족
• 좋은 게임 개발 프레임 워크 부족
• 프로그래머는 Java를 게임 프로그래밍 언어로 받아들이고 싶지 않습니다. 대부분 C ++ 만 허용합니까?
• 게임 콘솔을 지원하지 않습니다 (PC 시장은 여전히 ​​존재하지만)

물론 다른 것일 수도 있습니다. 나보다 사업을 잘 아는 사람이 게임 개발에있어 왜 Java가 추진력을 얻지 못하는지 설명 할 수 있을까?

몇 가지 이유:

• 예전에는 성능과 UI를 위해 "직접 액세스"가 필요했습니다. 이것은 Java 및 C #과 같은 VM 언어보다 우선합니다.
• 대부분의 콘솔 (예 : 360, PS3)에는 JVM이 없으므로 PC 버전의 코드를 재사용 할 수 없습니다. 다양한 장치를 지원하기 위해 C ++ 코드를 컴파일하는 것이 훨씬 쉽습니다.
• 대부분의 주류 게임 엔진 (예 : Unreal)에는 C ++ 바인딩이 있습니다. Java 커넥터 (예 : OpenGL 용)가 있지만 그와 비슷한 것은 없습니다.
• PC 게임의 경우 DirectX는 실제로 강력한 Java 지원을 제공하지 않습니다.
• 웹 기반 게임은 JavaScript 또는 Flash에서 실행됩니다. GWT와 같은 것을 사용하여 Java로 작성할 수 있습니다.
• iPhone은 Objective-C 변형을 실행합니다.

Java는 요즘 Android 게임에서 주로 사용됩니다. 단순히 해당 플랫폼의 기본 언어이기 때문입니다.

기술적 이유 :

• 최고의 3D 게임 엔진 은 대부분 C / C ++로 작성되었습니다. 대부분의 게임 개발자는 3D 엔진을 손상시키지 않고 처음부터 새로 작성하기를 원하지 않기 때문에 이것은 큰 문제입니다. Java에는 jMonkeyEngine 이 있으며 오픈 소스이며 실제로 는 훌륭 하지만 여전히 Unreal Engine 과 경쟁 할 수는 없습니다 .
• 매우 드문 상황의 경우 , 특히 특수 하드웨어 기능에 액세스하기 위해 C 또는 어셈블리 언어로 "금속에 접근"하는 이점이 있습니다. 이것은 오늘날 중요하지 않지만, 전문 게임 개발자는 여전히 옵션을 갖고 싶어합니다 .....
• Java에는 가비지 수집 , 관리 런타임이 있습니다. 99 %의 시간이 큰 이점인데, 이는 코딩을보다 쉽고 오류가 덜 발생하게하며 Java가 그렇게 인기있는 큰 이유 중 하나입니다. 그러나 가비지 수집주기 가 눈에 띄게 일시 중지 될 수 있으므로 게임에 가끔 대기 시간 문제가 발생합니다 . 새로운 대기 시간이 짧은 최신 JVM에서는 문제가되지 않지만 여전히 높은 FPS를 유지하는 것이 중요한 그래픽 중심 게임에서는 여전히 문제입니다.

기술적이지 않은 이유 :

• 전문 게임 개발 하우스는 C / C ++ 기술과 기술에 많은 투자를하고 있습니다. 이것은 엄청난 양의 관성을 만듭니다 .
• 크게 불합리한 인식 자바 그 속도가 느립니다. 당신은 확실히 자바와 수익성, 상업 3D 게임 쓸 수 있습니다 - 확실히 지금은 사실이 아니다, 90 년대 아마도 진정한 ( Runescape의의 ?에 대한 사람 또는 방법 마인 크래프트를 ?)
• Java가 게임보다는 비즈니스 응용 프로그램 및 웹에 더 중점을 둔다는 꽤 공정한 인식 . 이는 모바일의 성장과 더 많은 플랫폼 간 개발의 필요성에 따라 변경 될 수 있지만 현재는 확실합니다.

흥미롭게도 게임 개발자 가 Java 를 고려해야하는 몇 가지 이유가 있습니다 .

• 이식성 -대상 플랫폼의 수가 증가함에 따라 Java는 진정한 크로스 플랫폼 바이너리를 생성 할 수있는 최고의 기능으로 인해 점점 더 매력적입니다.
• 라이브러리 에코 시스템 – 3D 게임 엔진을 제외하고 Java는 모든 플랫폼에서 가장 다양한 라이브러리를 보유하고 있습니다. 네트워킹, 사운드, AI, 이미지 처리, 키 / 값 데이터 저장소 등을 주제로하며 오픈 소스 Java 라이브러리가있을 수 있습니다.
• 서버 측 개발 -Java는 서버를위한 훌륭한 언어 / 플랫폼이며, 더 많은 게임이 대규모 멀티 플레이어 요소를 통합함에 따라 서버 측이 점점 더 중요해질 것입니다. Linux의 Java는 여기에서 플랫폼으로 매우 매력적입니다.
• JVM- 아마도 가비지 수집, JIT 컴파일러, 동시성 지원 등 환상적인 가비지 수집 기능을 갖춘 세계 최고의 엔지니어링 VM 실행 환경 일 것입니다. 더 나아질 것입니다. 최상의 런타임 환경.
• 기타 JVM 언어 -Java는 탄탄한 작업량이지만 새로운 JVM 언어 (특히 Scala, Clojure)를 통해 실질적인 혁신이 이루어지고 있습니다. 이 언어는 Java / JVM 플랫폼의 모든 장점을 얻을, 플러스 그들은 매우 강력한 현대적인 언어입니다.

이 스레드에는 많은 잘못된 정보가 있습니다.

나는 게임 사업을 알 극도로 25 년 동안 거기에 있었던 것, 잘. 또한 게임에서 Java는 Sun의 Java Game 기술 전도사였으며 Java 성능 프로그래밍 전문가를 강하게 잘 알고 있습니다.

계산 속도 측면에서 Java는 오늘날 많은 과학 컴퓨팅 벤치 마크에서 C ++보다 뛰어납니다. 원하는 경우 성능이 좋지 않은 언어로 병리학 적 코드를 작성할 수 있지만, 전체적으로는 동등하며 오랫동안 사용되었습니다.

메모리 사용 측면에서 Java에는 오버 헤드가 있습니다. HelloWorld는 Java의 4K 프로그램입니다. 그러나 오늘날의 멀티 GB 시스템에서는 이러한 오버 헤드가 의미가 없습니다. 마지막으로 Java에는 더 많은 시작 시간이 있습니다. 유닉스 커맨드 라인 명령과 같은 짧은 런타임 유틸리티에는 Java를 사용하지 않는 것이 좋습니다. 이 경우 시동이 성능을 지배합니다. 그러나 게임에서는 상당히 초기 단계입니다.

올바르게 작성된 Java 게임 코드는 GC 일시 중지를 겪지 않습니다. C / C ++ 코드와 마찬가지로 활성 메모리 관리가 필요하지만 C / C ++ 수준에서는 그렇지 않습니다. 수명이 긴 오브젝트 (전체 레벨 또는 게임에 지속됨) 및 매우 짧은 수명이있는 오브젝트 (벡터 등의 계산 및 전달 후 빠르게 파괴됨)에 대한 메모리 사용량을 유지하는 한 gc는 눈에 띄는 문제가 아닙니다.

직접적인 메모리 액세스의 관점에서 자바는 오랜 기간 동안 그것을 가지고 있었다. Native Direct Byte Buffers 형태의 Java 1.4부터. Java에서 비트 twiddling은 부호없는 정수 유형이 없기 때문에 약간 성가신 일이 될 수 있지만 작업 라운드는 모두 잘 알려져 있으며 끔찍하지 않습니다.

진정한 Java에는 Direct3D 바인딩이 없었지만 Java 기술은 이식성을 위해 노력하기 때문입니다. 그것은 두 개의 OpenGL 바인딩 (JOGL 및 LWJGL) 및 OpenAL 바인딩 (JOAL)과 Windows의 DirectInput, OSX의 HID 관리자 및 Linux 바인딩 (나는 어느 것을 잊어 버린다)에 후드 아래에 바인딩하는 휴대용 입력 바인딩 (JInput)을 가지고 있습니다.

Unity가 C #을 특징으로하는 완전한 게임 엔진이 Java를 특징으로하지 않았으며 이는 독립된 공간의 약점입니다. 다른 한편으로, Windows, OSX 및 Linux에서 완전히 플랫폼 이식성이 뛰어난 2 개의 우수한 Scenegraph 레벨 API가있었습니다. Josh Slack이 작성한 첫 번째는 JMonkey 엔진과 두 번째 Ardor3D입니다.

최고의 포스터는 게임 개발에서 Java를 유지했던 가장 큰 두 가지 요소가 편견과 이식성 이었다는 것입니다. 후자가 가장 큰 문제였습니다. Java 게임을 작성하여 Windows, OSX 및 Linux에 제공 할 수는 있지만 콘솔 VM은 없었습니다. 이것은 Sun 중간 관리에서 전체가 부적절했기 때문입니다. 게임에서 Java를 사용하는 소수의 사람들은 실제로 Sony와 3 번 이상 플레이 스테이션에서 VM을 얻기 위해 3 번의 거래를했으며 Sun의 중간 관리자가 3 번의 죽임을당했습니다.

썬은 클라이언트 기술을 사용했지만 썬 관리는 소비자 제품을 얻지 못했다는 사실이 중요합니다. 그렇기 때문에 Sun의 클라이언트 언어 인 Java가 어떤 형태로도 성공하지 못한 이유는 무엇이며, Java와 플랫폼을 Java로 만드는 데 Google과 Dalvik (Android Java와 같은 VM)이 필요한 이유입니다.

이것이 바로 오늘 C #으로 게임을 코딩하는 이유입니다. 모노가 썬 경영진이 거부 한 곳으로 갔기 때문입니다.

Java는 안정적으로 실행되어야하는 비즈니스 로직, 서버 및 플랫폼 독립적 인 코드에 적합합니다. 게임에서 Java가 자주 사용되지 않는 몇 가지 요인이 있습니다.

• 경계 점검 및 기타 안전 메커니즘 (요즘 한계 성능 차이)
• C ++ 데이터 구조와 Java 데이터 구조간에 변환해야 함 (버퍼간에 메모리를 복사 할 수 없음)
• 많은 책과 튜토리얼이 군중을 따르므로 C ++ 이외의 게임 개발자 정보를 찾기가 어렵습니다.
• 핵심 그래픽 라이브러리 (DirectX 및 OpenGL)와 많은 상용 엔진은 C / C ++ 기반
• 많은 게임이 가능한 한 빨리 실행되어 시각적으로 매력적인 기능을 추가 할 수 있습니다.

Java (JNI 계층 작성) 및 .net (많은 마샬링 / 비 정렬 화, api / 구조 속성)과 같은 바이트 코드 언어의 C ++ 라이브러리로는 작업하기가 쉽지 않습니다. 따라서 약간의 이익을 위해 약간의 작업이 추가됩니다.

참고 : 일부 게임 서버는 Java를 사용합니다.

비슷한 게시물 여기에 : https : //.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 년에도 Jacob Marner는 "게임 개발을위한 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에 거의 관심이 거의없는 것 같습니다.

내가 생각할 수 있는 거의 유일한 후보는 구글 일 것이다. Android의 기본 개발 언어는 Java이며 Android 용 게임 개발을 장려 하면 플랫폼에 실질적인 이점을 제공 할 수 있습니다.

내가 아는 한, 그들은 그렇게하지 않았지만 (아직?), 거의 모든 다른 사람에게 꽤 심각한 한계를 남깁니다. 현대의 고성능 게임 엔진이 Java에서 개발을 사용하는 방법이 거의 없다면, 추가 작업에 대한 대가로 많은 이점을 얻을 수있는 전망이 거의없는 상당히 많은 추가 작업이 필요합니다.

문제는 다음 줄에 무언가를 묻는 것과 같습니다.

자동차, 보트 엔진 또는 제트 엔진에 전원을 공급하는 것이 더 좋습니다.

확장 성, 버그 방지, 속도, 메모리 서명, 모듈성 및 모든 것들이 있습니다. 문제는 산업 표준으로서 무엇이 더 나은지에 관한 것이 아니고, 당신이 알고있는 것과 잘 알고있는 것과 같이 "나에게 더 좋은 것이"라는 것이어야합니다. 그것이 일을하면 그 일을합니다. 실제로 아이디어를 팔 수 있다면 아이디어가 작동하며 누가 숟가락을 구부릴 수도 있습니다.

자바는 게임 개발을 염두에두고 제작 된 것이 아니라 "웹용 언어"가되도록 만들어졌다.

게임 개발과 관련하여 Sun은 Microsoft가 C #을 지원하는 게임 개발 언어로 Java를 실제로 지원하지 않았습니다.

필자는 매력적인 게임 개발 프레임 워크의 부족이이 측면에서 Java를 실제로 죽인 것이라고 생각합니다.

새로운 비 전통적인 하드웨어 및 드라이버에 C를 더 직접 접착하는 것이 더 쉽습니다. 게임 프로그래머가 하드웨어에 더 빨리 접근할수록 경쟁 게임보다 더 나은 사양을 지정할 수 있습니다. 나중에 게임 프로그래머는 이전에 입증 된 게임과 동일한 방법론과 도구를 사용합니다.

일반 휴대 전화 게임과 같이 최신 하드웨어에 대한 최적화가 중요하지 않은 게임의 경우 이러한 방식으로 C를 사용하는 것이 Java의 뛰어난 이식성보다 덜 중요합니다.

어떤 사람들에게는 이유가 속도, 라이브러리 또는 가용성과 관련이 없습니다. 그것은 언어 자체 때문입니다. 어떤 사람들은 단순히 Java 언어를 좋아하지 않습니다. 다른 사람들은 자바를 사용하여 게임을 만드는 대신 자신이 좋아하는 프로그래밍 언어를 사용합니다.

물론 다른 것일 수도 있습니다. 나보다 사업을 잘 아는 사람이 게임 개발에있어 왜 Java가 추진력을 얻지 못하는지 설명 할 수 있을까?

해석 언어, 즉 느립니다. 하드웨어 인 그래픽 및 그래픽 카드를 다루고 있습니다. 하드웨어를 다루기에 좋은 언어는 무엇입니까? 글쎄, C ++, 그것은 꽤 낮으며, 당신은 포인터 등을 다룬다.

크라이시스와 같은 미친 그래픽과 그것을 위해 자바를하지 않을 모든 것을 펌핑하고 싶다면.

뿐만 아니라 오라클은 Java를 소유하고 있으며, 회사가 귀하를 고소 할 수 있다고 생각하는 것은 대담하지 않습니다. 특히 조각화 FUD로 인해 소송을 제기하지 않고 게임을 목표로하기 위해 JAVA에 대한 자체 통역사를 구축하려는 경우.