Cạnh tranh với C ++ để lập trình trò chơi

Tôi tò mò về lý do tại sao C ++ rất phổ biến để phát triển trò chơi, chứ không phải các ngôn ngữ khác thay thế. Tôi biết bạn có thể tạo mã rất nhanh với nó, nhưng chính xác thì điều gì làm cho nó trở nên phổ biến?

Có phải chỉ vì nó nhanh? Đây có phải là một số tính năng khác trong ngôn ngữ, như mô hình OO hoặc tính di động? Có phải vì tất cả các thư viện đã được tạo ra theo thời gian? Hoặc một số kết hợp của tất cả những lý do này (và khác)?

Nếu ai đó có thể lấp đầy tôi về điều này, tôi sẽ rất hạnh phúc. :-)

Vô số lý do:

• Cái lớn bạn đã bỏ lỡ: Nó di động, đơn giản hóa các cổng công cụ trò chơi của bạn sang iOS, XBOX, PS3, bất cứ điều gì
• Nó nhanh
• Tất cả các SDK hỗ trợ nó nguyên bản
• Có rất nhiều thư viện
• Mọi người viết trò chơi đều biết điều đó, vì vậy thật dễ dàng để thuê các nhà phát triển trò chơi có kinh nghiệm cho nhóm của bạn
• Thật tầm thường khi nhúng một ngôn ngữ kịch bản công cụ trò chơi như Lua

Có một vài lý do mà tôi muốn đề cập đến ngoài những gì @Graham đưa ra.

• Legacy Code - nhiều studio có rất nhiều mã C ++, bạn sẽ đề cập đến các thư viện.
• C ++ thực sự là một trình biên dịch cấp cao và có quyền truy cập trực tiếp vào phần cứng (trực tiếp như bạn có thể chạy trên hệ điều hành ít nhất) và khá nhanh. Nếu bạn muốn, trong C ++, bạn có thể thả trực tiếp xuống ngôn ngữ hợp ngữ để kiểm soát mức hướng dẫn (không phải nó luôn luôn khôn ngoan, điều đó là không thể với Java, C #, Python, v.v.)
• DirectX và OpenGL vốn hỗ trợ C ++, hầu hết các ngôn ngữ khác có "liên kết" với các thư viện cơ bản thông qua các lớp trung gian, điều đó không có nghĩa là chúng không nhanh hoặc không thể thực hiện nhiều điều tương tự, nhưng nó thêm một lớp phần mềm vào giữa trò chơi của bạn và phần cứng.
• Như @Graham đề cập, rất nhiều lập trình viên biết điều đó, vì vậy rất dễ tìm thấy các nhà phát triển có kinh nghiệm và cũng khá dễ mang theo, so với C # bị mắc kẹt trên .NET Framework (có Mono, nhưng nói chung, nó chậm hơn một thế hệ đằng sau việc triển khai của Microsoft .)

Tốc độ thô là lý do chính, nhưng thực ra đó không phải là quyết định hoặc vì vậy rất nhiều công ty trò chơi đang bắt đầu sử dụng các ngôn ngữ khác cho các phần của trò chơi. Một số tác vụ nhất định yêu cầu máy tính hoạt động nhanh nhất có thể (ví dụ: thói quen kết xuất lõi) nhưng nhiều tác vụ trong mã trò chơi không phải chạy nhanh như vậy (ví dụ: mở cửa khi người chơi nhấp vào nó) có nghĩa là là thông minh để sử dụng ngôn ngữ đơn giản hơn (và do đó nhanh hơn để viết chương trình) cho các phần đó. Đó là lý do tại sao nhiều công cụ trò chơi được viết bằng C ++ nhưng nhúng ngôn ngữ kịch bản như Lua để viết mã trò chơi.

Điều khó hiểu là khi chọn ngôn ngữ lập trình, có một sự đánh đổi tổng thể giữa hiệu quả cho máy tính và hiệu quả cho lập trình viên. Đó là, điều quan trọng hơn với bạn, máy tính chạy mã nhanh như thế nào hoặc lập trình viên viết mã nhanh như thế nào?

Trong C ++, bạn có thể phân bổ các biến cục bộ biến mất sau khi hàm kết thúc. Thông thường, chúng được phân bổ trên một ngăn xếp.

Các biến ngăn xếp không đóng góp cho các vấn đề phân bổ bộ nhớ động của phân mảnh và chi phí chung. Phòng phân bổ trên ngăn xếp là nhanh chóng và dễ dàng (chỉ cần điều chỉnh một con trỏ). Phân bổ bộ nhớ động thường bao gồm tìm kiếm một bộ chứa cho một khối bộ nhớ đầy đủ, đánh dấu bộ nhớ, sau đó gắn thẻ nó là chiếm dụng. Giao dịch liên quan đến việc thêm khối bộ nhớ vào một thùng chứa và có thể hợp nhất nó với các khối hiện có. Nhiều chi phí hơn nhiều so với việc chỉ thay đổi một con trỏ.

Java và C # cấp phát bộ nhớ một cách linh hoạt, ngoại trừ các kiểu nguyên thủy. Các ngôn ngữ này phụ thuộc vào môi trường thời gian chạy sẽ đánh dấu một biến cần xóa, sau đó chạy trình thu gom rác theo các khoảng thời gian ngẫu nhiên (không được lên lịch) để lấy lại bộ nhớ. Nói chung, lập trình viên không có quyền kiểm soát khi nào biến sẽ được gắn thẻ để xóa cũng như khi nào nó sẽ được thu hồi (khai hoang bộ nhớ đã sử dụng là một chủ đề nâng cao mà hầu hết các lập trình viên C ++ và Java không gặp phải).

Tốc độ của C ++ chủ yếu là do dịch trực tiếp sang mã thực thi. Java và C # được biên dịch thành một mã trung gian, sau đó được giải thích bởi một máy ảo. Nói chung, ngôn ngữ diễn giải là người thực hiện chậm hơn so với ngôn ngữ dịch trực tiếp.

Các trò chơi đã từng được viết bằng ngôn ngữ máy, bởi vì chúng có phần cứng kỳ lạ mà không có trình biên dịch. Phần cứng cũng thiếu các tính năng mà các lập trình viên C coi là hiển nhiên, chẳng hạn như toán học số nguyên 16 bit hiệu quả.

Khi các trò chơi ổn định trên phần cứng quen thuộc, trình biên dịch C đã có sẵn và trong một thời gian ngắn, tất cả các trò chơi được viết bằng C.

C ++ có vẻ như là một ý tưởng tốt tại một thời điểm, và hầu hết các trò chơi là C ++ ngày nay, nhưng các kỹ sư hiện đang lầm bầm về việc quay trở lại C, và điều đó thực sự có thể xảy ra. Tôi rất thích làm việc trong một trò chơi ở C, và nhiều đồng nghiệp cũng vậy. Không có tính năng mới nào đối với C ++ mà tôi nghĩ là cải thiện trò chơi.

Bây giờ có vẻ như máy tính nhanh hơn 1000 lần so với vài năm trước, một ngôn ngữ cấp cao sẽ giảm thời gian phát triển ($) khiến C trở nên lỗi thời.

Điều này đã không xảy ra vì người mua trò chơi biết rằng phần cứng tốt hơn 1000 lần và muốn đổi đô la của họ cho một trò chơi có vẻ ngoài và âm thanh tốt hơn 1000 lần. Điều này loại bỏ sự chậm chạp khỏi hệ thống mà một ngôn ngữ cấp cao sẽ tiêu thụ.

Yêu cầu về hiệu suất trong các trò chơi là tàn bạo. Một khung đồ họa mới phải được hiển thị dưới 33ms (hoặc 16ms!) Mà không thất bại. Tất cả mọi thứ phần cứng phải được tính toán, để ngân sách này có thể được đáp ứng. Bất kỳ ngôn ngữ nào bị tắt và làm một cái gì đó với phần cứng mà lập trình viên không hiểu hoặc mong đợi sẽ khiến cho việc đáp ứng ngân sách này trở nên rất khó khăn. Đây là một điểm trừ tự động chống lại bất cứ điều gì cấp cao.

Các lập trình viên trò chơi không chỉ làm việc trong một ngôn ngữ cấp thấp, mà họ còn tránh xa các cấu trúc dữ liệu và thuật toán cấp cao. Các trò chơi thường không có danh sách liên kết và hiếm khi có cây. Có một phong trào hướng tới việc tránh con trỏ bất cứ khi nào có thể *. Bất kỳ thuật toán nào có nhiều thời gian hơn O (N) hoặc không gian O (1) có xu hướng không được sử dụng rộng rãi.

* Nếu một con trỏ không gây ra lỗi nhớ cache, thì tại sao lại tốn 32 bit để lưu trữ? Nếu một con trỏ gây ra lỗi bộ nhớ cache, tốt nhất hãy loại bỏ lỗi bộ nhớ cache đó.

Mỗi ngôn ngữ lập trình đều có điểm mạnh và điểm yếu trên một loạt các yếu tố. Ví dụ về các yếu tố này là:

• Tốc độ trên một nền tảng cụ thể
• Sử dụng bộ nhớ trên một nền tảng cụ thể
• Những chức năng nó tiếp xúc dễ dàng hơn
• Nó tồn tại trên nền tảng nào
• Những gì các lập trình viên phải có trên tàu

Một trong những yếu tố quan trọng nhất mà một lập trình viên trò chơi quan tâm là hiệu năng. Họ muốn tạo ra một trải nghiệm tương tác, có nghĩa là nó phải phản ứng và có thể xuất ra càng nhiều dữ liệu hữu ích (hoặc thú vị) càng tốt. Bạn muốn biết bạn có bao nhiêu sức khỏe bất cứ lúc nào và không muốn chờ đợi nó. Và nếu bạn nhấp vào một nút, bạn mong muốn một khẩu súng bắn hoặc nhân vật của bạn nhảy khi bạn nói như vậy. Một chút độ trễ có thể cản trở sự tương tác này vì vậy bạn cần hiệu suất.

Một yếu tố quan trọng khác là thích lập trình bằng ngôn ngữ của vấn đề, thay vì ngôn ngữ thực hiện. Một lập trình viên trò chơi muốn đối phó với con người, orc và xe đua, không phải đăng ký bộ nhớ ED0. Họ vẫn muốn tùy chọn đi sâu vào chi tiết triển khai nếu họ cần hiệu năng, nhưng thật tuyệt nếu phần lớn họ có thể đối phó với cấp độ của các thực thể trong thế giới trò chơi của họ. Họ có đủ lo lắng về việc mô phỏng thế giới trò chơi mà không phải luôn quan tâm đến cách danh sách liên kết hoạt động.

C ++ phù hợp với hai yếu tố chính này rất tốt. Bạn có thể có các lợi ích hiệu suất của lắp ráp hoặc mã C với tính biểu cảm của các đối tượng. Để xem lý do tại sao điều này phù hợp tự nhiên cho các trò chơi, hãy so sánh với một số tùy chọn ngôn ngữ khác:

• Hội: Đây là sức mạnh thô. Những gì bạn viết về cơ bản là những gì CPU làm. Nhưng ở mỗi giai đoạn bạn cần biết những gì đang xảy ra với các thanh ghi và tác dụng của việc này, và nó không bao giờ giống như các thực thể trong thế giới trò chơi của bạn. Lập trình viên phải tạo ra sự tương ứng về mặt tinh thần về những gì mã của họ làm so với những gì xảy ra trong trò chơi. Đây có thể là một chi phí khá cao.
• C: Ở đây chúng tôi có hiệu suất tốt, nhưng chúng tôi có thể tận dụng trải nghiệm của các bậc thầy để hoàn thành công việc tiêu chuẩn (như phân bổ bộ nhớ, hoạt động trên chuỗi và sử dụng các hàm toán học tiêu chuẩn). Chúng ta tiến gần hơn đến tính biểu cảm ở đây, nhưng ngôn ngữ ít nhiều buộc bạn phải tập trung vào việc thực hiện vì bạn thực sự chỉ có thể hoạt động trên các loại dữ liệu thông thường. Tất cả mọi thứ thực sự là một char, một int hoặc tương tự. cấu trúc, con trỏ và mảng có thể giữ mọi thứ lại với nhau, nhưng vẫn phải suy nghĩ về các phần bên trong.
• Java: Chúng tôi nhảy qua C ++ và đến Java. Java đẩy xa hơn từ các chi tiết thực hiện. Trên thực tế, phần lớn thời gian bạn không được tiếp cận với các cấp thấp hơn. Java tóm tắt nhiều chi tiết triển khai (ví dụ: CPU hoặc HĐH nào bạn đang sử dụng) với lý do nó muốn đa nền tảng. Bạn không thể truy cập các chi tiết vì chúng không có ở đó. Bạn không lập trình cho máy tính, bạn lập trình cho nền tảng (nền tảng Java, tồn tại trên hầu hết các máy tính). Hơn nữa, Java có một ngôn ngữ được cho là tốt hơn để xử lý ngôn ngữ của vấn đề so với C ++. Sự đánh đổi là bạn không thể tối ưu hóa cho một máy tính cụ thể. Cho dù điều này làm cho một sự khác biệt thực tế hay không đi vào chi tiết cụ thể của chương trình và máy tính.
• Ngôn ngữ kịch bản trò chơi: Bằng cách này, tôi có nghĩa là một cái gì đó như UnrealScript hoặc ngôn ngữ kịch bản tùy chỉnh gắn trên một công cụ trò chơi. Trong đó bạn không có quyền truy cập vào công cụ cơ bản. Bạn ủy thác các cân nhắc về hiệu suất cho động cơ, để bản thân không phải lo lắng về việc tạo ra một trò chơi. Viết trò chơi dễ hơn, tự tối ưu hóa hiệu suất của trò chơi.
• Haskell (hoặc ngôn ngữ tối nghĩa yêu thích của bạn): Bất kỳ ngôn ngữ lập trình hoàn chỉnh Turing nào cũng tương đương với bất kỳ ngôn ngữ nào khác. Vì vậy, trong khi bạn có thể viết bất kỳ chương trình nào bằng bất kỳ ngôn ngữ nào, bạn thực hiện đánh đổi, một số mục tiêu, một số chủ quan. Một ngôn ngữ như Haskell tập trung hơn vào làm việc theo tinh thần toán học. Các vấn đề mà nó hướng đến có phần khác biệt với các vấn đề gặp phải trong các trò chơi. Điều đó không có nghĩa là nó không thể hoặc không nên được sử dụng cho các trò chơi, nó chỉ không dễ dàng phù hợp với nó.

Điểm cuối cùng là một số trong số này là lịch sử và chính trị. Nhiều cuộc chiến ngọn lửa đã được chiến đấu giữa các ngôn ngữ lập trình khác nhau. Ví dụ, C # có thể phù hợp với việc phát triển trò chơi, nhưng nó xuất hiện sau C ++. Hoặc mọi người không thích điều đó từ Microsoft. Một số người đã chuyển sang C #, một số thì không. Một số người vẫn lập trình trò chơi trong BASIC, Pascal và C. Dù lập trình viên có thoải mái với điều gì, họ sẽ tuân theo. Các lập trình viên trò chơi hầu hết đều cảm thấy thoải mái với C ++, có thể vì họ lớn lên với C và C ++, và nó đáp ứng nhu cầu của họ. Nếu ngành công nghiệp máy tính ở trong tình trạng hiệu suất và sự hấp thụ của Java đáp ứng đủ số người, thì có lẽ Java sẽ là ngôn ngữ phát triển trò chơi tiêu chuẩn thực tế.

Di sản và động lực.

Ngày xửa ngày xưa, mã thời gian được viết bằng trình biên dịch chương trình để đạt hiệu suất cao nhất. Khi sức mạnh tính toán tăng lên, các ngôn ngữ được biên dịch trở nên khả thi hơn và C đưa ra sự thỏa hiệp tốt nhất giữa sức mạnh và năng suất, ở mức độ rất cơ bản là ít hơn một trình biên dịch vĩ mô.

C ++ chỉ là sự kế thừa tự nhiên cho C. Bạn không vứt bỏ mã hoặc kiến ​​thức trước đây, nhưng vẫn có tiềm năng mở rộng sang các phương pháp mới. C ++ cuối cùng rất linh hoạt và tôi chưa thấy một mô hình thiết kế nào ít nhất có thể được mô phỏng trong C ++, trong khi có thể duy trì gần như toàn quyền kiểm soát hiệu suất.

Nếu bạn đang phát triển cho bảng điều khiển, bạn không có lựa chọn nào: SDK chuyên nghiệp chỉ có các hương vị C ++. Thông thường họ cũng có quyền truy cập C vào hầu hết mọi thứ.

Bởi vì nhiều nhà phát triển là Consoles + PC, nên thực hiện tất cả các PC của họ hoạt động trong cùng một ngôn ngữ và trực tiếp chia sẻ công nghệ.

Bởi vì đó là nơi mà ngành công nghiệp chuyên nghiệp sống và hầu hết mọi người đều muốn trở thành một phần trong đó, hầu hết các lập trình viên trò chơi đều là lập trình viên C ++.

Bởi vì tất cả điều đó xảy ra, hầu hết các nhà phát triển động cơ cũng là nhà phát triển C ++, vì vậy khi đánh giá các công cụ cấp chuyên nghiệp, hầu hết các lựa chọn của bạn sẽ là C ++.

Đó là tất cả một động cơ tự duy trì lớn. Phá vỡ nó sẽ đòi hỏi nhiều hơn là chỉ tiến bộ kỹ thuật.

FWIW: C # đang trở nên phổ biến để phát triển trò chơi. Xem bài viết trên blog của Miguel de Icaza . Đọc rất thú vị, IMHO.

Mặc dù tôi khá chống C, C & C ++, nhưng điều duy nhất họ có mà ít ngôn ngữ khác có là kiểm soát hoàn toàn nền tảng mà nó đang chạy, bạn có thể chắc chắn chính xác những gì sẽ xảy ra mọi lúc, không GC, không có trục trặc.

Điều này không quan trọng trong những ngày này, nhưng nó có thể dành cho các nền tảng không đủ mạnh.

Trên PC / Mac / Linux, đây có thể là ngôn ngữ di động ít nhất bạn sẽ gặp trong những ngày này và phần thưởng tốc độ không còn quá khác biệt - Minecraft (Java) mượt mà và hoạt động trên các nền tảng khá tối thiểu (và bất kỳ HĐH nào) với một lần thực thi duy nhất - Tôi chưa thấy một ứng dụng indi C / C ++ nhân lực thấp với nhiều chức năng và ít lỗi, hãy để một mình làm việc trên ba nền tảng.

Vì vậy, tại thời điểm này tôi nói rằng hầu hết là quán tính và quan niệm rằng các trò chơi thực sự luôn được thực hiện trong C / C ++, mặc dù khả năng "port" sang iPhone và console là rất đáng kể (Mặc dù tôi khá chắc chắn trong số các giao diện người dùng của trò chơi tốn rất nhiều nỗ lực để chuyển ngoại trừ giữa Windows và XBox).