Tại sao Java không được sử dụng rộng rãi hơn để phát triển trò chơi? [đóng cửa]

Tôi không phải là nhà phát triển trò chơi hay bất cứ điều gì, nhưng tôi biết rằng Java không được sử dụng rộng rãi để phát triển trò chơi. Java phải đủ nhanh cho hầu hết các trò chơi, vậy thì bắt ở đâu? Tôi có thể nghĩ ra một số lý do:

• Thiếu các nhà phát triển trò chơi có chuyên môn về Java
• Thiếu khung phát triển trò chơi tốt
• Các lập trình viên không muốn chấp nhận Java như một ngôn ngữ lập trình trò chơi. Hầu hết chỉ chấp nhận C ++ như vậy?
• Không hỗ trợ cho bảng điều khiển trò chơi (mặc dù thị trường PC vẫn tồn tại)

Nó tất nhiên có thể là một cái gì đó khác. Ai đó có thể hiểu rõ hơn về doanh nghiệp hơn tôi có thể giải thích tại sao Java không có được động lực khi phát triển trò chơi không?

Nhiều lý do:

• Ngày xưa, bạn cần "truy cập trực tiếp" cho hiệu suất và giao diện người dùng. Điều này có trước các ngôn ngữ VM như Java và C #.
• Hầu hết các bảng điều khiển (ví dụ: 360, PS3) không có JVM, vì vậy bạn không thể sử dụng lại mã từ phiên bản PC. Việc biên dịch mã C ++ để hỗ trợ các thiết bị khác nhau sẽ dễ dàng hơn nhiều.
• Hầu hết các công cụ trò chơi chính thống (ví dụ: Unreal) có các ràng buộc C ++. Có một số trình kết nối Java (ví dụ, đối với OpenGL) nhưng không có gì giống như vậy.
• Đối với chơi game trên PC, DirectX không thực sự có hỗ trợ Java mạnh (nếu có).
• Các trò chơi dựa trên web chạy bằng JavaScript hoặc Flash. Bạn có thể viết chúng bằng Java mặc dù sử dụng những thứ như GWT.
• IPhone chạy một biến thể Objective-C.

Ngày nay, Java chủ yếu được sử dụng trong các trò chơi Android, đơn giản vì đây là ngôn ngữ chính cho nền tảng đó.

Lý do kỹ thuật:

• Hầu hết các công cụ trò chơi 3D tốt nhất được viết bằng C / C ++. Đây là một vấn đề lớn, vì hầu hết các nhà phát triển trò chơi không muốn thỏa hiệp trên công cụ 3D của họ, nhưng họ cũng không muốn viết từ đầu. Java có jMonkeyEngine là mã nguồn mở và thực sự rất tốt nhưng nó vẫn chưa thể cạnh tranh với Unreal Engine .
• Đối với một số trường hợp rất hiếm gặp, có những lợi thế trong việc "gần với kim loại" bằng ngôn ngữ C hoặc ngôn ngữ lắp ráp, đặc biệt để truy cập vào các tính năng phần cứng đặc biệt. Điều này không quá quan trọng hiện nay, nhưng các nhà phát triển game chuyên nghiệp vẫn muốn có tùy chọn .....
• Java có một rác được thu thập , quản lý thời gian chạy. 99% thời gian này là một lợi thế rất lớn, nó chắc chắn làm cho việc mã hóa dễ dàng hơn và ít bị lỗi hơn và là một trong những lý do lớn khiến Java rất phổ biến. Tuy nhiên, điều này gây ra sự cố trễ thỉnh thoảng cho các trò chơi vì chu kỳ thu gom rác có thể gây ra tạm dừng đáng chú ý. Điều này đang trở thành một vấn đề với các JVM có độ trễ thấp mới hơn, nhưng vẫn là một vấn đề đối với các trò chơi chuyên sâu về đồ họa trong đó việc duy trì FPS cao là rất quan trọng.

Lý do phi kỹ thuật:

• Các nhà phát triển trò chơi chuyên nghiệp đang đầu tư vào các kỹ năng và công nghệ C / C ++. Điều này tạo ra một lượng quán tính rất lớn .
• Nhận thức phần lớn không hợp lý rằng Java là chậm. Có thể đúng vào những năm 90, chắc chắn không phải bây giờ - bạn chắc chắn có thể viết một trò chơi 3D thương mại có lợi nhuận bằng Java ( Runescape có ai không? Hay về Minecraft ?)
• Một nhận thức khá công bằng rằng Java tập trung nhiều hơn vào các ứng dụng kinh doanh và web hơn là chơi game. Điều này có thể thay đổi cùng với sự phát triển của Mobile và nhu cầu phát triển đa nền tảng hơn, nhưng hiện tại chắc chắn là đúng.

Điều thú vị là cũng có một số lý do chính đáng tại sao các nhà phát triển trò chơi nên xem xét Java:

• Tính di động - khi số lượng nền tảng đích tăng lên, Java ngày càng trở nên hấp dẫn hơn với khả năng tạo ra các nhị phân đa nền tảng thực sự.
• Hệ sinh thái thư viện - với ngoại lệ rất quan trọng của các công cụ trò chơi 3D, Java có phạm vi thư viện tốt nhất trong mọi nền tảng. Mạng, âm thanh, AI, xử lý hình ảnh, lưu trữ dữ liệu khóa / giá trị, bạn đặt tên cho chủ đề và có thể có một thư viện Java nguồn mở cho nó.
• Phát triển phía máy chủ - Java là một ngôn ngữ / nền tảng tuyệt vời cho máy chủ và khi nhiều trò chơi kết hợp nhiều yếu tố nhiều người chơi, phía máy chủ sẽ ngày càng trở nên quan trọng hơn. Java trên Linux trông khá hấp dẫn ở đây như là một nền tảng.
• JVM - có lẽ là môi trường thực thi VM được thiết kế tốt nhất trên Thế giới, với bộ sưu tập rác tuyệt vời, trình biên dịch JIT, hỗ trợ đồng thời, v.v. Nó sẽ trở nên tốt hơn và khi các nhà phát triển trò chơi bắt đầu sử dụng các ngôn ngữ động trong các trò chơi của họ môi trường thời gian chạy tốt nhất có thể.
• Các ngôn ngữ JVM khác - Java là một công việc khó khăn, nhưng sự đổi mới thực sự đang diễn ra với các ngôn ngữ JVM mới (đặc biệt là Scala, Clojure). Các ngôn ngữ này có được tất cả các lợi thế của nền tảng Java / JVM, cộng với chúng là các ngôn ngữ hiện đại cực kỳ mạnh mẽ.

Được rồi, có rất nhiều thông tin sai trong chủ đề này.

Tôi biết kinh doanh trò chơi cực kỳ tốt, đã ở trong đó 25 năm. Tôi cũng biết Java trong các trò chơi cực kỳ tốt là nhà truyền giáo kỹ thuật Java của Sun và giảng viên chuyên gia lập trình hiệu suất Java.

Về tốc độ tính toán, Java vượt qua C ++ trong nhiều tiêu chuẩn tính toán khoa học hiện nay. Bạn có thể viết mã bệnh lý bằng một trong hai ngôn ngữ hoạt động kém nếu bạn muốn, nhưng trên hết, chúng ngang bằng nhau và đã có từ lâu.

Về mặt sử dụng bộ nhớ, Java có một số chi phí vượt trội. HelloWorld là một chương trình 4K trong java. Nhưng chi phí đó khá vô nghĩa trong các hệ thống nhiều GB ngày nay. Cuối cùng, Java có nhiều thời gian khởi động hơn. Tôi không khuyến nghị sử dụng Java cho các tiện ích thời gian ngắn như các lệnh dòng lệnh Unix. Trong những trường hợp đó, startup sẽ chi phối hiệu suất của bạn. Tuy nhiên, trong một trò chơi, nó khá khó hiểu.

Mã trò chơi Java được viết đúng cách không bị tạm dừng GC. Giống như mã C / C ++, nó yêu cầu một số quản lý bộ nhớ hoạt động nhưng không đến mức C / C ++. Miễn là bạn giữ mức sử dụng bộ nhớ của mình cho các đối tượng tồn tại lâu dài (tồn tại trong toàn bộ cấp độ hoặc trò chơi) và các đối tượng tồn tại rất ngắn (vectơ và như vậy, được truyền xung quanh và nhanh chóng bị phá hủy sau khi tính toán) gc không phải là vấn đề có thể nhìn thấy.

Về mặt truy cập bộ nhớ trực tiếp, Java đã có điều đó trong một thời gian dài; kể từ Java 1.4 dưới dạng Bộ đệm Byte trực tiếp gốc. Việc xử lý bit trong Java có thể hơi khó chịu do thiếu các kiểu số nguyên không dấu nhưng các vòng công việc đều được biết đến và không quá tệ.

Mặc dù Java thực sự của nó chưa bao giờ có ràng buộc Direct3D, nhưng đó là vì các công nghệ Java cố gắng cho tính di động. Nó có các ràng buộc TWO OpenGL (JOGL và LWJGL) và liên kết OpenAL (JOAL) và liên kết đầu vào di động (JInput) liên kết dưới mui xe với DirectInput trên Windows, HID Manager trên OSX và ràng buộc Linux (tôi quên điều đó).

Đúng là không có công cụ trò chơi hoàn chỉnh nào có tính năng Java theo cách nói, Unity, đã giới thiệu C # và đó là một điểm yếu trong không gian độc lập. Mặt khác, có hai APIS cấp độ Kịch bản tốt, hoàn toàn có thể di động trên Windows, OSX và Linux. Cả hai được viết bởi Josh Slack, cái đầu tiên được gọi là động cơ JMonkey và Ardor3D thứ hai.

Áp phích trên cùng là chính xác rằng hai điều lớn nhất cản trở Java phát triển trò chơi là định kiến ​​và tính di động. Sau này là vấn đề lớn nhất. Mặc dù bạn có thể viết một trò chơi Java và gửi nó trên Windows, OSX và Linux, nhưng không bao giờ có máy ảo console. Điều này là do sự bất lực hoàn toàn trong quản lý cấp trung của Sun. Một vài người trong số chúng tôi làm việc trên Java trong các trò chơi thực sự đã thỏa thuận với Sony không dưới 3 lần để có được một máy ảo trên Playstation và cả 3 lần quản lý cấp trung của Sun đã giết chết nó.

Trong khi Sun tán tỉnh các công nghệ của khách hàng, thực tế của vấn đề là quản lý của Sun không bao giờ có sản phẩm tiêu dùng. Đó là lý do tại sao Java với tư cách là ngôn ngữ máy khách từ Sun không bao giờ thành công dưới bất kỳ hình thức nào và tại sao Google và Dalvik (máy ảo giống như java của Android) để biến Java thành một nền tảng thành công ở bất cứ đâu.

Và đó là lý do tại sao tôi viết mã trò chơi trong C # ngày hôm nay. Bởi vì Mono đã đi nơi quản lý của Sun từ chối.

Java rất tốt cho logic nghiệp vụ, máy chủ và mã độc lập nền tảng phải chạy đáng tin cậy. Có một số yếu tố khiến Java không thường được sử dụng trong các trò chơi:

• kiểm tra giới hạn và các cơ chế an toàn khác (chênh lệch hiệu suất cận biên ngày nay)
• phải chuyển đổi giữa cấu trúc dữ liệu C ++ và cấu trúc dữ liệu Java (không thể sao chép bộ nhớ giữa các bộ đệm)
• nhiều sách và hướng dẫn đi theo đám đông, vì vậy thật khó để tìm thấy thông tin nhà phát triển trò chơi không phải C ++
• các thư viện đồ họa cốt lõi (DirectX và OpenGL) và nhiều công cụ sẵn có dựa trên C / C ++
• nhiều trò chơi cố gắng chạy nhanh nhất có thể để chúng có thể thêm các tính năng hấp dẫn trực quan hơn

Thật không dễ dàng để làm việc với các thư viện C ++ từ các ngôn ngữ mã byte như Java (viết một lớp JNI) và .net (rất nhiều thuộc tính marshalling / unmarshalling, api / architecture). Vì vậy, nó thêm khá nhiều công việc cho lợi ích nhỏ.

Một lưu ý phụ: một số máy chủ trò chơi sử dụng Java.

Bài đăng tương tự ở đây : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java không đủ nhanh để phát triển trò chơi. Nó chậm hơn nhiều so với sử dụng C ++ / hội, đó là tiêu chuẩn. Đó là cùng một lý do phát triển trò chơi nhiều hơn không được thực hiện bằng C # hoặc VB. Các nhà phát triển trò chơi cần và lập kế hoạch cho mỗi chu kỳ đồng hồ cuối cùng mà họ có thể thực hiện cho những việc như tính toán vật lý, logic AI và tương tác môi trường.

Đối với các trò chơi đơn giản hơn, Java có thể được sử dụng khá hiệu quả. Nếu bạn muốn tạo một bản sao Tetris hoặc Bejeweled hoặc một cái gì đó khác ở mức độ chi tiết đó, thì Java sẽ hoạt động tốt. Nhưng Java không thể tạo ra các trò chơi như Halo, Medal of Honor, Command & Conquer, v.v. và làm cho nó có thể chơi được. Ít nhất là nó tồn tại ngày nay.

Và những lý do bạn liệt kê trong câu hỏi của bạn là hợp lệ là tốt. Ngoại trừ, tôi nghĩ, vì thiếu các nhà phát triển trò chơi có chuyên môn về Java. Nhiều trò chơi trên điện thoại và các thiết bị cầm tay khác được viết bằng Java (bao gồm hầu hết các trò chơi Android) và một số trò chơi khá xuất sắc. Vì vậy, tôi nghĩ rằng có một cơ sở tốt của các nhà phát triển trò chơi có kiến ​​thức Java.

Ý nghĩ đang thay đổi về khả năng sử dụng các ngôn ngữ cấp cao hơn này cho một số trò chơi nâng cao hơn. Chẳng hạn, một trong những trò chơi yêu thích của tôi, Train Simulator của Auran, được viết với các phần lớn bằng C #, và nó hoạt động khá tốt. Vì vậy, cơ sở đang phát triển và sẽ tiếp tục phát triển.

Trò chơi hiện đại là tất cả về đồ họa 3D xảy ra trong phần cứng mục đích đặc biệt.

Ngay cả vào năm 2002, Jacob Marner đã phát hiện trong báo cáo "Đánh giá Java để phát triển trò chơi" rằng Java khá hữu dụng cho các trò chơi, ngoại trừ các phần phụ thuộc hiệu năng nhất và do sự mạnh mẽ của ngôn ngữ và JVM cơ bản mà nó rẻ hơn để làm theo cách này.

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

Theo ý kiến ​​cá nhân của tôi, với sự tiến bộ đã xảy ra kể từ đó, đặc biệt là trong đồ họa 3D và với các ràng buộc tuyệt vời với OpenGL et al, rằng nhược điểm này ngày nay ít được phát hiện hơn.

Do đó vấn đề phải ở nơi khác. Một lý do có khả năng là kích thước của thời gian chạy Java (ngày nay không còn là vấn đề với các trò chơi đa DVD) và một quán tính khác của mã hiện có. Nó nổi tiếng là dễ vỡ khi bắt đầu làm việc với mã gốc trong Java. Một lý do thứ ba là những gì các nhà phát triển ngôi sao làm các trò chơi quen thuộc. Thứ tư là liệu Java có sẵn trên nền tảng hay không.

Mặc dù vậy, có một điều chắc chắn - hầu hết các trò chơi đều chuyển sang dạng script thay vì ghi tất cả mã C ngay từ đầu và bạn muốn có thời gian chạy tốt nhất bên dưới ngôn ngữ kịch bản của mình. Ngày nay, điều này về cơ bản có nghĩa là CLR hoặc JVM.

Các nhà phát triển trò chơi thích gần gũi với kim loại và thường sẽ viết các vòng lặp chặt chẽ bên trong của họ trong quá trình lắp ráp. Java không cung cấp cùng một mức hiệu suất có thể, cả về tốc độ phù hợp hoặc sử dụng bộ nhớ (chạy JIT đều phải trả phí).

Tôi nghĩ rằng yếu tố hạn chế đối với hầu hết mọi người là (thiếu) sự sẵn có của các công cụ trò chơi tốt. Để đi rất xa, chúng ta cần xem xét tại sao những thứ đó không có sẵn.

Tôi sẽ nhìn nó từ hướng khác một lát. Phát triển một công cụ trò chơi (ví dụ) là rất nhiều công việc. Ai sẽ được hưởng lợi đủ từ việc phát triển một để đầu tư thời gian và công sức để làm như vậy?

Hầu hết các ứng cử viên rõ ràng cho phát triển giống như khung trong / cho Java (ví dụ: IBM, Oracle) dường như không có hứng thú với các trò chơi. Các ứng cử viên rõ ràng cho phát triển trò chơi (ví dụ: Id, EA) dường như ít quan tâm đến Java.

Gần như ứng cử viên duy nhất tôi có thể nghĩ về điều đó dường như hoàn toàn hợp lý sẽ là Google. Ngôn ngữ phát triển chủ yếu cho Android là Java, và phát triển trò chơi đáng khích lệ dành cho Android có thể mang lại lợi thế thực sự cho nền tảng này.

Theo như tôi biết, họ chưa làm như vậy (chưa?), Điều này để lại một số giới hạn khá nghiêm trọng cho hầu hết mọi người khác. Không có chút gì để các công cụ trò chơi hiệu năng cao, hiện đại sử dụng phát triển trên Java có nghĩa là khá nhiều công việc phụ, với (rất giống với tôi) sẽ có rất ít lợi ích để tạo ra nhiều lợi ích cho việc làm thêm đó.

Câu hỏi ngang tầm với việc hỏi điều gì đó trong các dòng:

Điều gì là tốt hơn để cung cấp năng lượng cho xe của bạn, động cơ thuyền hoặc động cơ phản lực.

Nó liên quan đến khả năng mở rộng, tránh lỗi, tốc độ, chữ ký bộ nhớ, mô-đun và một loạt các thứ. Câu hỏi không nên là về những gì tốt hơn theo tiêu chuẩn ngành, câu hỏi nên là "điều gì tốt hơn cho tôi" như trong những gì bạn biết hoặc bạn hiểu rõ về nó như thế nào. Nếu nó thực hiện công việc thì nó thực hiện công việc, nếu bạn thực sự có thể bán ý tưởng thì nó hoạt động và ai biết bạn thậm chí có thể uốn cong một vài thìa.

Java không được tạo ra với mục đích phát triển trò chơi, Java được tạo ra để trở thành một ngôn ngữ "cho web".

Về phát triển trò chơi, Sun không thực sự hỗ trợ Java như một ngôn ngữ phát triển trò chơi khi Microsoft hỗ trợ C #.

Tôi nghĩ rằng việc thiếu các khung phát triển trò chơi hấp dẫn là điều thực sự giết chết Java ở khía cạnh này.

Dễ dàng hơn để dán C trực tiếp hơn vào các trình điều khiển và phần cứng độc đáo mới. Một lập trình viên trò chơi càng sớm và càng gần với phần cứng, họ càng có thể vượt qua các trò chơi cạnh tranh tốt hơn. Các lập trình viên trò chơi sau này chỉ gắn bó với phương pháp và công cụ tương tự như những trò chơi đã được chứng minh trước đó.

Đối với các trò chơi mà việc tối ưu hóa phần cứng mới nhất ít quan trọng hơn, chẳng hạn như các trò chơi trên điện thoại di động thông thường, sử dụng C theo cách này ít quan trọng hơn là tính di động cao hơn của Java.

Đối với một số người, lý do không liên quan gì đến tốc độ, thư viện hoặc tính khả dụng. Nó chỉ đơn giản là vì ngôn ngữ chính nó. Một số người đơn giản là không thích ngôn ngữ Java. Những người khác thà sử dụng ngôn ngữ lập trình yêu thích của họ thay vì sử dụng Java để tạo trò chơi.

Nó tất nhiên có thể là một cái gì đó khác. Ai đó có thể hiểu rõ hơn về doanh nghiệp hơn tôi có thể giải thích tại sao Java không có được động lực khi phát triển trò chơi không?

Đó là một ngôn ngữ diễn giải, tức là chậm. Bạn đang làm việc với card đồ họa và đồ họa là phần cứng. Một ngôn ngữ tốt để đối phó với phần cứng là gì? Chà, C ++, nó khá thấp, và bạn đối phó với con trỏ và bất cứ điều gì.

Nếu bạn muốn đưa ra đồ họa điên rồ như crysis và bất cứ điều gì bạn sẽ không làm Java cho nó.

Không chỉ vậy, Oracle còn sở hữu Java, ý nghĩ rằng một công ty có thể kiện bạn không táo bạo lắm. Đặc biệt là khi bạn muốn xây dựng trình thông dịch của riêng mình cho JAVA để nhắm mục tiêu chơi trò chơi mà không bị kiện do phân đoạn FUD.