Tại sao chỉ có một vài trò chơi video được viết bằng Java? [đóng cửa]

Tại sao không có nhiều trò chơi video 3D thương mại (không phải là trò chơi 2D nguồn mở ngẫu nhiên) được viết bằng Java? Về lý thuyết, điều này rất có ý nghĩa: bạn có được tăng năng suất và ứng dụng đa nền tảng gần như miễn phí, trong số những thứ khác, chẳng hạn như số lượng lớn các thư viện Java và bộ sưu tập rác tích hợp (mặc dù tôi thừa nhận tôi ' m không chắc chắn sau này là một điều tốt). Vậy tại sao nó hiếm khi được sử dụng? Tôi chỉ có thể nghĩ về một vài trò chơi thương mại phổ biến được viết cho nền tảng Java.

Có phải vì hiệu suất? Nếu vậy, hầu hết các công việc nặng nhọc sẽ được GPU thực hiện?

Thế giới phát triển trò chơi là một thế giới vui nhộn: Một mặt, họ thường nhanh chóng chấp nhận những ý tưởng mới, mặt khác, họ vẫn đang ở thời kỳ đồ đá.

Sự thật là, hiếm khi có nhiều động lực khi chuyển sang .NET / Java / bất cứ thứ gì khác ngoài C / C ++.

Hầu hết các công ty trò chơi cấp phép các bộ phận của công cụ trò chơi từ các công ty khác. Các phần này được viết bằng C ++ và mặc dù bạn có thể có quyền truy cập vào nguồn để bạn có thể chuyển nó, điều đó cần rất nhiều nỗ lực (và tất nhiên, giấy phép cần phải cho phép nó).

Ngoài ra, rất nhiều mã kế thừa đã tồn tại trong C ++. Nếu mã từ các dự án trước có thể được sử dụng lại (giả sử, nếu bạn đang viết phần tiếp theo), điều đó thậm chí còn được ưu tiên hơn khi gắn bó với cùng một ngôn ngữ, thay vì viết lại bằng ngôn ngữ mới (vì vậy nhiều khả năng bạn sẽ giới thiệu lại một tấn lỗi mà bạn sẽ cần dành thời gian ủi ra.

Cuối cùng, dù sao thì cũng hiếm khi các trò chơi được viết bằng 100% C ++ - rất nhiều việc được thực hiện bằng các ngôn ngữ kịch bản, cho dù chúng là tùy chỉnh hay chỉ tích hợp một ngôn ngữ hiện có (Lua là một trong những ngôn ngữ phổ biến hơn hiện nay).

Theo như thu thập rác, đó có thể là một vấn đề. Vấn đề không phải là nó tồn tại nhiều, nó hoạt động nhiều hơn - công cụ thu gom rác PHẢI không bị chặn (hoặc ít nhất được đảm bảo chỉ chặn rất nhanh), vì đơn giản là không thể chấp nhận trò chơi bị đóng băng trong 10 giây trong khi nó quét tất cả bộ nhớ được phân bổ để xem những gì có thể được giải phóng. Tôi biết Java có xu hướng bị nghẹt thở khá nhiều trong GC'ing khi sắp hết bộ nhớ (và đối với một số trò chơi ngoài đó, nó sẽ như vậy).

Bạn cũng bị hạn chế hơn một chút trong những gì bạn có thể làm: bạn không thể khai thác triệt để phần cứng do chi phí hoạt động. Hãy tưởng tượng Crysis được viết bằng Java ... ngay cả khi đó là điểm khác biệt duy nhất có thể nhìn thấy, nó sẽ không giống nhau (tôi cũng khá chắc chắn rằng bạn cần Core i7 để chạy nó.).

Điều này không có nghĩa là những ngôn ngữ này không có vị trí trong phát triển trò chơi - và không, tôi không chỉ nói đến lập trình công cụ. Đối với hầu hết các trò chơi, bạn không cần thêm một chút hiệu suất mà bạn có được từ C ++, bao gồm các trò chơi 3D và nếu bạn viết tất cả từ đầu, thì có thể sử dụng một thứ gì đó giống như XNA - thực tế, có một cơ hội tốt nó sẽ.

Theo như các trò chơi thương mại - RuneScape có tính không? Đó cũng có thể là trò chơi Java thành công nhất hiện có.

Tôi nghĩ John Carmack đã nói điều đó tốt nhất với:

Vấn đề lớn nhất là Java rất chậm. Ở cấp độ cpu / bộ nhớ / hiển thị / liên lạc thuần túy, hầu hết các điện thoại di động hiện đại nên là nền tảng chơi game tốt hơn đáng kể so với Game Boy Advanced. Với Java, trên hầu hết các điện thoại, bạn chỉ còn lại sức mạnh CPU của máy tính IBM 4,77 mhz ban đầu và khả năng kiểm soát tệ hại đối với mọi thứ. [... snip ...] Viết-một lần-chạy-bất cứ nơi nào. Hà. Hahahahaha. Chúng tôi chỉ đang thử nghiệm trên bốn nền tảng ngay bây giờ và không một cặp nào có cùng một yêu cầu chính xác. Tất cả các trò chơi thương mại được tinh chỉnh và biên dịch riêng cho từng nền tảng (thường là hơn 100). Tính di động không phải là một biện minh cho hiệu suất khủng khiếp.

( nguồn )

Được cho phép, anh ta đã nói về các nền tảng di động, nhưng tôi đã tìm thấy các vấn đề tương tự với Java nói chung đến từ nền tảng C ++. Tôi nhớ việc có thể phân bổ bộ nhớ trên Stack / Heap theo cách riêng của mình.

Đối với một điều, việc thiếu quá tải toán tử của Java làm cho tất cả các phép toán mà bạn phải xử lý để có được một đường ống đồ họa hoạt động rất, rất khó chịu và khó đọc.

Tất cả các phép nhân ma trận và vectơ affine mà bạn cần xử lý sẽ dễ thực hiện hơn rất nhiều nếu chúng ở trong các biểu thức toán học được định dạng tốt thay vì các biểu thức hướng đối tượng như

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

Điều đó thật tồi tệ. Toán học không nên như thế.

Tôi nghĩ .NET đã có (có) rất nhiều vấn đề tương tự mà Java gặp phải. Microsoft vừa hoàn thành công việc tiếp thị tốt hơn cho các nhà phát triển với XNA :-)

Điểm nhỏ đầu tiên:

• bất kỳ tăng năng suất từ ​​Java là giả thuyết. Cú pháp gần giống với C ++, vì vậy bạn thực sự chỉ cần tiết kiệm tiền từ quản lý bộ nhớ và thư viện chuẩn. Các thư viện có rất ít để cung cấp cho các nhà phát triển trò chơi và quản lý bộ nhớ là một vấn đề gây tranh cãi do bộ sưu tập rác.

• đa nền tảng "miễn phí" không tốt như bạn nghĩ vì ít nhà phát triển muốn sử dụng OpenGL và một số nền tảng chính có thể thiếu triển khai Java hoặc trình bao bọc tốt cho thư viện gốc của họ, cho dù là đồ họa, âm thanh, mạng, v.v.

Nhưng chủ yếu, vấn đề là tương thích ngược. Các nhà phát triển trò chơi đã chuyển sang C ++ từ C và sang C từ lắp ráp hoàn toàn vì tuyến di chuyển trơn tru. Mỗi mã tương tác chặt chẽ với trước đó và tất cả các mã trước đó của chúng đều có thể sử dụng được bằng ngôn ngữ mới, thường thông qua một trình biên dịch duy nhất. Do đó, di chuyển chậm hoặc nhanh như bạn muốn. Ví dụ: một số tiêu đề cũ của chúng tôi đang sử dụng ngày nay vẫn có #ifdef WATCOMCvà tôi không nghĩ có ai đã sử dụng trình biên dịch Watcom ở đây trong một thập kỷ trở lên. Có một sự đầu tư lớn vào mã cũ và mỗi bit chỉ được thay thế khi cần thiết. Quá trình thay thế và nâng cấp các bit và miếng từ trò chơi này sang trò chơi tiếp theo gần như không thực tế nếu bạn đổi sang ngôn ngữ không thực sự tương tác với mã hiện tại của bạn. Có, khả năng tương tác C ++ / Java là có thể, nhưng rất không thực tế khi so sánh với việc chỉ viết "C với một chút C ++" hoặc nhúng các khối asm trong C.

Để thay thế chính xác C ++ như ngôn ngữ lựa chọn của nhà phát triển trò chơi, nó phải thực hiện một trong hai điều sau:

1. Dễ dàng tương tác với mã kế thừa hiện có, do đó bảo toàn đầu tư và duy trì quyền truy cập vào các thư viện và công cụ hiện có, HOẶC
2. Hiển thị rõ ràng phía trước đủ để tăng năng suất rằng chi phí viết lại tất cả mã của riêng bạn (hoặc làm lại các giao diện thành các thành phần có thể sử dụng lại từ ngôn ngữ đó) sẽ được chi trả nhiều hơn.

Theo chủ quan, tôi không nghĩ Java gặp một trong hai. Một ngôn ngữ cấp cao hơn có thể đáp ứng thứ 2, nếu ai đó đủ can đảm để trở thành người tiên phong. (EVE Online có lẽ là ví dụ tốt nhất mà Python có thể sử dụng được, nhưng nó sử dụng một nhánh của ngôn ngữ Python chính, nhiều thành phần C ++ để thực hiện và thậm chí đó là một trò chơi khá đơn giản trong điều kiện hiện đại.)

Tôi đang chơi Sims 3 và tôi đã chọc ngoáy. Công cụ đồ họa là C ++, trong khi công cụ kịch bản và hành vi là C # / Mono. Vì vậy, trong khi C ++ dành cho các bit quan trọng về thời gian, các thứ khác như .interaction, logic game, AI nằm trong ngôn ngữ được quản lý theo hướng đối tượng.

• Có bất kỳ cổng tốt của công cụ / thư viện chơi game?
• Nhiều nhà phát triển C / C ++, đặc biệt là các nhà phát triển trên Windows (nơi hầu hết các trò chơi thương mại được viết) đều quen thuộc với Visual Studio. Không có so sánh trong IDE.
• Nói chung, Java đã được bán cho các doanh nghiệp vì nó đánh máy vững chắc và nó có nhận thức về việc không gặp vấn đề về quản lý bộ nhớ.
• Và đúng vậy, Java vẫn phải chịu một nhận thức rằng nó chậm và quản lý bộ nhớ kém, và đối với các trò chơi, nó có lẽ không phù hợp với nhiệm vụ. Như đã nêu trong một số câu trả lời khác, bộ sưu tập rác sẽ không cắt giảm khi bạn xử lý các yêu cầu hiệu suất cao theo thời gian thực. Trò chơi video đẩy CPU và GPU đến giới hạn của chúng.

Một trong những lý do lớn nhất khiến Java và các ngôn ngữ Máy ảo khác không được sử dụng cho các trò chơi là do Bộ sưu tập rác. Điều tương tự cũng xảy ra với .NET. Bộ sưu tập rác đã đi một chặng đường dài và hoạt động tuyệt vời trong hầu hết các loại ứng dụng. Để thực hiện thu gom rác, bạn cần tạm dừng và ngắt ứng dụng để thu gom rác. Điều này có thể gây ra độ trễ định kỳ khi thu thập xảy ra.

Java có cùng một vấn đề cho các ứng dụng thời gian thực. Khi các tác vụ phải chạy tại một thời điểm cụ thể, thật khó để có một tác vụ tự động như bộ sưu tập rác tôn trọng điều đó.

Không phải là Java chậm. Đó là Java không giỏi xử lý các tác vụ thời gian thực.

Một lý do lớn là các trò chơi video đòi hỏi kiến ​​thức trực tiếp về phần cứng bên dưới, thường xuyên và thực sự không có triển khai tuyệt vời cho nhiều kiến ​​trúc. Đó là kiến ​​thức về kiến ​​trúc phần cứng cơ bản cho phép các nhà phát triển vắt kiệt từng ounce hiệu năng ra khỏi hệ thống chơi game. Tại sao bạn lại dành thời gian để chuyển Java sang nền tảng chơi trò chơi và sau đó viết một trò chơi lên trên cổng đó khi bạn chỉ có thể viết trò chơi?

chỉnh sửa: điều này có nghĩa là nó không chỉ là vấn đề "tốc độ" hay "không có thư viện phù hợp". Hai thứ đó song hành với nhau, nhưng vấn đề là "làm cách nào để tạo một hệ thống như tế bào chạy mã java của tôi? Thực sự không có trình biên dịch java tốt nào có thể quản lý các đường ống và vectơ như tôi cần .. "

Vấn đề hiệu suất là lý do đầu tiên. Khi bạn thấy loại mã C ++ được tối ưu hóa siêu cao trong các công cụ Quake ( http://www.codemaestro.com/reviews/9 ), bạn biết rằng họ sẽ không lãng phí thời gian của mình với một máy ảo.

Chắc chắn có thể có một số trò chơi .NET (trò chơi nào? Tôi quan tâm. Có một số trò chơi thực sự sử dụng nhiều CPU / GPU không?), Nhưng tôi đoán nó nhiều hơn bởi vì nhiều người là chuyên gia về công nghệ MS và đã theo dõi Microsoft khi họ tung ra công nghệ mới của họ.

Oh và đa nền tảng không phải là trong suy nghĩ của các công ty trò chơi video. Linux chỉ chiếm khoảng 1% thị trường, Mac OS thêm vài%. Họ chắc chắn nghĩ rằng không đáng để từ bỏ các công nghệ và những lời nói dối chỉ dành cho Windows như DirectX.

Bạn cũng có thể hỏi tại sao các ứng dụng web không được viết bằng C hoặc C ++. Sức mạnh của Java nằm ở ngăn xếp mạng và thiết kế hướng đối tượng. Tất nhiên C và C ++ cũng có điều đó. Nhưng trên một sự trừu tượng thấp hơn. Điều đó không có gì tiêu cực, nhưng bạn không muốn phát minh lại bánh xe mỗi lần, phải không?

Java cũng không có quyền truy cập phần cứng trực tiếp, điều đó có nghĩa là bạn bị mắc kẹt với API của bất kỳ khung công tác nào.

Những quan niệm sai lầm về hiệu năng và tối ưu hóa JVM kém sẽ là phỏng đoán của tôi. Tôi nói những quan niệm sai lầm về hiệu năng bởi vì có một số cổng Java của trò chơi C ++ hoạt động nhanh hơn so với các đối tác C ++ của họ (xem Jake 2). Vấn đề thực sự, IMHO, là nhiều lập trình viên Java không tập trung quá nhiều vào hiệu năng vượt trội vì chúng dễ sử dụng và dễ hiểu / khả năng duy trì mã. Về phía C / C ++, về cơ bản, bạn đang mã hóa bằng ngôn ngữ lắp ráp cấp độ cao hơn một chút và nó gần với phần cứng như bạn có thể nhận được mà không cần viết mã lắp ráp hoặc mã máy thẳng.

Danh sách các công cụ trò chơi trên Wikipedia liệt kê nhiều công cụ trò chơi cùng với ngôn ngữ lập trình mà chúng được viết.

Có một số công cụ trò chơi Java được liệt kê.

Nhấp vào một số liên kết sẽ dẫn bạn đến các ví dụ về trò chơi và bản demo được viết bằng Java. Đây là một cặp vợ chồng:

• Ardor3D
• Phần mềm Bytonic

Đối với một số trò chơi và tình huống nhất định, sự đánh đổi của Java có thể được chấp nhận.

.NET chắc chắn có một số vấn đề tương tự như Java khi nói đến hiệu năng 3D mãnh liệt. Microsoft cũng đã đầu tư nhiều thời gian và tiền bạc hơn cho việc phát triển các thư viện khi làm việc với các hoạt động nặng 3D.

(... Cá nhân, tôi cũng nghĩ rằng họ đã hợp tác khi nói đến phép màu giữa DirectX và .NET)

1. Java chậm, hầu hết các công việc nặng không được xử lý bởi GPU. Vẫn còn hoạt hình, vật lý và AI tấn công CPU, tất cả đều rất tốn thời gian.

2. Java không tồn tại trên các bảng điều khiển và bảng điều khiển là mục tiêu chính cho các trò chơi thương mại. Nếu bạn sử dụng Java trên PC, bạn sẽ loại bỏ khả năng chuyển sang bảng điều khiển trong thời gian và ngân sách hợp lý.

3. Nhiều lập trình viên có kinh nghiệm hơn trong ngành công nghiệp trò chơi đã sử dụng C và C ++ từ lâu trước khi Java trở nên phổ biến. Hai điểm trên có thể góp phần vào điều này, nhưng tôi hy vọng rằng nhiều lập trình viên trò chơi chuyên nghiệp chỉ không thực sự hiểu rõ về Java.

4. Quan điểm của người khác về phần mềm trung gian ở trên là một điểm tốt, vì vậy tôi đang thêm nó vào câu trả lời của mình. Có rất nhiều mã kế thừa và phần mềm trung gian được viết riêng để liên kết với C / C ++ và cuối cùng tôi đã kiểm tra Java không có khả năng tương tác tốt. Sử dụng Java cho hầu hết các công ty sẽ liên quan đến việc đưa ra rất nhiều mã, phần lớn trong số đó đã được trả bằng cách này hay cách khác.

Trên thực tế, rất có thể mã được quản lý để làm trò chơi 3d, vấn đề là các công cụ trở lại. Với .Net, trong một khoảng thời gian ngắn, đã có một trình bao bọc DirectX được quản lý cho DirectX 9 của Microsoft. Điều này là trước khi trừu tượng mà bây giờ là XNA.

Được cấp toàn quyền truy cập vào DirectX api's, các trò chơi .Net hoạt động tốt. Ví dụ tốt nhất mà tôi biết là www.entombed.co.uk, được viết bằng VB.Net.

Thật không may, về phía Java, nó thiếu trầm trọng - chủ yếu là vì lý do DirectX không có sẵn cho Java và các lập trình viên trò chơi biết và hiểu api DirectX - tại sao lại tìm hiểu một api khác khi bạn sẽ quay trở lại DirectX?

Tiếp thị trò chơi là một quá trình thương mại; các nhà xuất bản muốn lợi nhuận rủi ro thấp có thể định lượng cho khoản đầu tư của họ. Do đó, trọng tâm thường tập trung vào các mánh lới công nghệ (ngoại trừ) mà người tiêu dùng sẽ mua để tạo ra lợi nhuận đáng tin cậy - những xu hướng này là hiệu ứng hình ảnh bề ngoài như lóa ống kính hoặc độ phân giải cao hơn. Những hiệu ứng này đáng tin cậy vì đơn giản là chúng sử dụng tăng sức mạnh xử lý - chúng khai thác phần cứng / định luật Moore tăng. điều này ngụ ý sử dụng C / C ++ - java thường quá trừu tượng từ phần cứng để khai thác những lợi ích này.

Tôi đoán rằng tốc độ vẫn là vấn đề. Nền tảng chéo sẽ là một vấn đề phải không vì bạn không biết thẻ 3d nào có sẵn khi bạn viết mã? Java có gì để hỗ trợ tự động phát hiện các khả năng 3d không? Và tôi đoán rằng có những công cụ để dễ dàng chuyển một trò chơi giữa wii, xbox và ps3, nhưng tôi sẽ đặt cược đắt tiền.

Các ps3 có java, thông qua hỗ trợ tia xanh. Kiểm tra trang web bd-j.

Ngay cả các trò chơi được viết trên nền tảng .Net thường được tối ưu hóa cao về tốc độ như truy cập trực tiếp vào bộ nhớ và xe buýt. .Net cho phép sử dụng C / C ++ và trộn nó với các ngôn ngữ cấp cao hơn như C #.

Các studio phát triển trò chơi thường làm việc gần gũi với các nhà cung cấp phần cứng, cung cấp quyền truy cập vào các giao diện cấp thấp của các sản phẩm của họ. Đây là một thế giới, nơi bạn phải sử dụng ASM và C để liên lạc với thiết bị. Một môi trường ảo sẽ làm chậm các phần chương trình này.

Dù sao, các trò chơi 3D hiện đại trên thực tế sử dụng các ngôn ngữ cấp cao hơn. Thông thường, bạn sẽ tìm thấy logic trò chơi được viết bằng các ngôn ngữ như Lua hoặc Python. Nhưng cốt lõi (I / O, chủ đề, lập lịch tác vụ) của trò chơi 3D thông thường sẽ được viết bằng ngôn ngữ cấp thấp trong 25 năm tới hoặc vì các thiết bị dài không cho phép trừu tượng hóa và ảo hóa bởi chính chúng (sẽ xuất hiện).

Tôi đồng ý với các bài viết khác về việc tận dụng các yếu tố của một cơ sở mã có sẵn / được cấp phép, hiệu suất, v.v.

Một điều tôi muốn nói thêm là thật khó để thực hiện các thủ thuật DRM khó chịu thông qua một máy ảo.

Ngoài ra tôi nghĩ có một thành phần trung tâm trong đó các nhà quản lý dự án nghĩ rằng họ có thể tạo mã ổn định / đáng tin cậy bằng C ++ với tất cả các đặc quyền như có quyền kiểm soát tuyệt đối đối với các công cụ và tài nguyên của họ, NHƯNG không có tất cả các tiêu cực làm phức tạp và làm giảm sự cạnh tranh của họ vì "chúng tôi" lại thông minh hơn họ ".

Runescape của Jagex được viết bằng Java, thẻ "trò chơi video" có thể không áp dụng cụ thể nó là một trò chơi trực tuyến, nhưng nó có một số lượng khá.

Nó đã được nói về nó rất nhiều rồi, bạn có thể tìm thấy ngay cả trên Wiki những lý do ...

• C / C ++ cho công cụ trò chơi và tất cả những thứ chuyên sâu.
• Lua hoặc Python để viết kịch bản trong trò chơi.
• Java - hiệu năng rất rất tệ, sử dụng bộ nhớ lớn + không có trên Game console (Nó được sử dụng cho một số trò chơi rất đơn giản (Có, Runescape tính ở đây, không phải Battlefield hay Crysis hay những gì khác ở đó) chỉ vì có rất nhiều lập trình viên biết ngôn ngữ lập trình này).
• C # - sử dụng bộ nhớ lớn (Nó được sử dụng cho một số trò chơi rất đơn giản chỉ vì có khá nhiều lập trình viên biết ngôn ngữ lập trình này).

Và tôi nghe ngày càng nhiều lập trình viên Java cố gắng thuyết phục mọi người rằng Java không chậm, không chậm để vẽ một widget trên màn hình và vẽ một số ký tự ASCII trên widget, để nhận và gửi dữ liệu qua mạng (Và đó là nên sử dụng nó trong trường hợp này (thao tác dữ liệu mạng) thay vì C / C ++) ... Nhưng thật chậm khi nói đến những thứ nghiêm trọng như tính toán, phân bổ / xử lý bộ nhớ và rất nhiều thứ hay ho này.

Tôi nhớ một bài viết trên trang MIT, nơi họ chỉ ra C / C ++ có thể làm gì nếu bạn sử dụng các tính năng của ngôn ngữ và trình biên dịch: Một hệ số nhân ma trận (2 ma trận), 1 triển khai trong Java và 1 triển khai trong C / C ++, với các tính năng C / C ++ và tối ưu hóa trình biên dịch phù hợp được kích hoạt, việc triển khai C / C ++ nhanh hơn ~ 296 260 lần so với triển khai Java.

Tôi hy vọng bạn đã hiểu tại sao mọi người sử dụng C / C ++ thay vì Java trong các trò chơi, hãy tưởng tượng Crysis trong Java, sẽ không có máy tính nào trên thế giới này có thể xử lý ... + Bộ sưu tập rác hoạt động tốt với Widgets vừa phá hủy hình ảnh nhưng nó vẫn được lưu trong bộ nhớ cache và cần được dọn dẹp nhưng không phải cho các trò chơi, chắc chắn, bạn sẽ có nhiều độ trễ hơn trên mỗi lần kích hoạt bộ sưu tập rác.

Chỉnh sửa : Bởi vì ai đó đã yêu cầu bài viết, ở đây, tôi đã tìm kiếm trong kho lưu trữ web để có được điều đó, tôi hy vọng bạn hài lòng ... Nghiên cứu trường hợp MIT

Và để thêm, không, Java để chơi game vẫn là một ý tưởng tồi tệ. Chỉ vài ngày trước, một công ty lớn mà tôi đã không nêu tên đã bắt đầu viết lại ứng dụng khách trò chơi của họ từ Java sang C ++ vì một trò chơi rất đơn giản (về mặt Đồ họa) đã bị lag và làm nóng Máy tính xách tay i7 với thẻ video thế hệ nVidia GT 5xx và 6xx mạnh mẽ ( Không chỉ nVidia, vấn đề ở đây là các thẻ mạnh mẽ này có thể xử lý trên các cài đặt Max hầu hết các trò chơi mới và không thể xử lý trò chơi này) và mức tiêu thụ bộ nhớ là ~ 2,5 - 2,6 GB Ram. Đối với đồ họa đơn giản như vậy, nó cần một con thú của một cỗ máy.