C ++ có được thay thế bằng C # trong các trò chơi công nghiệp không?

Trong các trò chơi công nghiệp, ý tôi là như Quake, CoD, v.v.

Theo một nghĩa nào đó, C ++ thực sự đang được thay thế - không chỉ bởi C #, mà còn bởi một loạt các ngôn ngữ khác. Nhưng nếu bạn hỏi, nó sẽ được thay thế hoàn toàn - thì câu trả lời chắc chắn là không .

Đó là bởi vì C ++ thường được sử dụng theo hai khả năng. Đầu tiên, để tạo ra công cụ trò chơi : các thành phần cấp thấp tải tài nguyên, đẩy đa giác lên màn hình và số giòn trong mô phỏng vật lý. Thứ hai, để mã hóa logic trò chơi : các quy tắc thực tế tạo ra trò chơi.

Dung lượng thứ hai này không yêu cầu các điểm mạnh của C ++ (như kiểm soát hoàn toàn các chi tiết cấp thấp), nhưng bị các điểm yếu của nó (chẳng hạn như quản lý bộ nhớ mã hóa dễ bị lỗi). Và trong khả năng thứ hai này, C ++ đang được thay thế bằng các ngôn ngữ script khác nhau. Rất nhiều nhà phát triển sử dụng Lua; một số sử dụng Python. Nhưng nếu một nền tảng CLI có sẵn, dưới dạng .NET hoặc Mono, thì nó thể hiện một ứng cử viên lưu trữ kịch bản tuyệt vời. Các nền tảng này khá nhanh, đáng tin cậy, cung cấp một ngôn ngữ được biết đến rộng rãi (C #) và một thư viện lớp cơ sở toàn diện. Chúng ta đừng quên các công cụ: MS Visual studio và SharpDevelop / MonoDevelop có thể không phải là những IDE tốt nhất trên thế giới, nhưng chúng khá tốt.

Điều đó nói rằng, công cụ trò chơi sẽ không được viết bằng C # (hoặc Lua hoặc Python cho vấn đề đó). Tại sao? Bởi vì họ không đủ nhanh.

Trái với nhiều niềm tin phổ biến, hiệu suất lớn nhất hiện nay là do độ trễ bộ nhớ . Điều này có nghĩa là truy cập bộ nhớ là công việc nghiêm túc. Và các ngôn ngữ được quản lý không cho phép người dùng kiểm soát truy cập bộ nhớ - đó chính xác là lý do tại sao họ "được quản lý" ngay từ đầu. Vì vậy, không có ngôn ngữ được quản lý sẽ cho phép viết một công cụ trò chơi thực sự nhanh. Trên thực tế, tất cả các công cụ "C #" lớn mà tôi có thể nghĩ ra - XNA, MOGRE, Unity - đều dựa trên mã C ++ bản địa ; nhưng cho phép viết logic trò chơi bằng C #.

Tóm lại : C # sẽ được sử dụng thay cho C ++ hoặc các ngôn ngữ khác. Nhưng nó sẽ không bao giờ thay thế C ++, ít nhất là cho đến khi ai đó phát minh ra bộ nhớ truy cập tức thời, không có độ trễ.

Lựa chọn ngôn ngữ phụ thuộc nhiều vào nền tảng. Ngay bây giờ có vẻ như thực sự không có gì ngoài nền tảng Microsoft thực sự sẽ yêu cầu .NET như một triển khai.

Sự khôn ngoan thông thường sẽ nói rằng một nền tảng nhỏ sẽ cần phải gần với kim loại để hoạt động, nhưng mặt khác, các nền tảng được quản lý sẽ an toàn hơn . Đó có lẽ là lý do Windows Phone 7 buộc bạn phải sử dụng .NET.

Chắc chắn sẽ rất thú vị nếu Xbox mới yêu cầu nền tảng được quản lý. Nếu một phần cứng của điện thoại có thể xử lý nó (và nó cũng vậy), tôi chắc chắn có thể thấy họ sử dụng nó trên bàn điều khiển có kích thước đầy đủ. Nó sẽ khuấy động hệ sinh thái console khá nhiều vì việc viết các trò chơi đa nền tảng sẽ khó hơn nếu không viết tất cả mã trò chơi của bạn bằng ngôn ngữ kịch bản. Nếu đó là trường hợp, thì C # sẽ không thay thế C ++, nhưng nó sẽ song hành với nhau.

Ngay bây giờ bạn có thể sử dụng Mono làm phần cuối kịch bản (tương tự như Unity làm), nhưng tôi sẽ tưởng tượng rằng hầu hết các nhà sản xuất động cơ đều muốn tự lăn hoặc sử dụng thứ gì đó nhỏ gọn hơn như Lua hoặc Python hơn C #.

Dù bằng cách nào, đó là tất cả về công cụ phù hợp cho công việc phù hợp. Dù sao thì bạn cũng nên học cả hai ngôn ngữ, vì C # giúp bạn dễ dàng thực hiện một số việc nhất định (phát triển công cụ, có thể phát triển máy chủ, v.v.) và bạn không thể sử dụng bất cứ thứ gì ngoài C ++ trong một số trường hợp.

Nó không có khả năng. C ++ có lợi ích là mức độ thấp để các nhà phát triển thực sự có thể điều chỉnh chi tiết nhỏ nhất để đạt được hiệu suất tốt nhất có thể.

Với C # và .NET, bạn có bộ sưu tập rác rất hữu ích, nhưng khi làm việc với các nền tảng có bộ nhớ và khả năng hạn chế (bảng điều khiển di động và ở một mức độ nào đó bảng điều khiển gia đình), bạn cần kiểm soát bộ nhớ nhiều nhất có thể để sử dụng tốt nhất của các tài nguyên. Cho phép các ngôn ngữ được quản lý phân bổ và giải phóng bộ nhớ cho bạn rất có thể sẽ gây ra cho bạn rất nhiều vấn đề.

Tốc độ cũng là một vấn đề (mặc dù có lẽ ít hơn như vậy). Theo thời gian, tôi chắc chắn rằng các ngôn ngữ được quản lý có thể được thực hiện để thực hiện tương đương với trình biên dịch C ++.

Nhìn chung, theo kinh nghiệm của tôi, dù sao đi nữa, các nhà phát triển trò chơi có xu hướng kiểm soát sự quái đản khi nói đến bộ nhớ, thời gian CPU và tài nguyên (để giảm hiệu năng hết mức có thể), đó là lý do tại sao C / C ++ là ngôn ngữ được sử dụng chủ yếu.

AFAIK .NET GC vẫn bị dừng thuật toán kiểu thế giới . Mặc dù điều này có thể phù hợp với nhiều ứng dụng khác nhau - nhưng không thể chấp nhận được đối với các ứng dụng thời gian thực như trò chơi.

Trên thực tế, rất khó sử dụng các ngôn ngữ được quản lý một cách hiệu quả cho các chương trình thời gian thực cho đến khi chúng tôi có một số bước đột phá trong GC.

Không. Tùy thuộc vào .NET sẽ ngụ ý việc viết lại lớn cho các nền tảng không có Framework, như PS3 và các nhược điểm về hiệu năng có thể được chấp nhận hoàn toàn trên PC hoặc cho các trò chơi Live Arcade, nhưng các trò chơi lớn hơn sẽ cần mọi thứ hiệu suất từ ​​bảng điều khiển của họ để chạy đủ nhanh. Hơn thế nữa, có rất nhiều cơ sở mã hiện có trong C ++ mà không ai có thể nâng cấp, ngay cả khi họ muốn. C ++ hoạt động trong ngành công nghiệp game và nó sẽ tồn tại ở đó trong một thời gian dài.

Vào thời điểm mà sức mạnh máy tính khan hiếm, mọi thứ cần được lập trình trong C hoặc C ++, đơn giản là vì các ngôn ngữ được thu gom rác sẽ lấy đi bộ nhớ của lập trình viên, và do đó, hiệu suất có thể giảm.

Ngày nay, máy tính nhanh hơn, nhưng như Knuth nói và nói ngắn gọn, tối ưu hóa có thể là xấu xa:

• Rõ ràng là các chức năng lõi cấp thấp cần phải được tối ưu hóa, bởi vì tính toán hình học 3D, vật lý, va chạm, ánh sáng, có thể nhanh chóng làm hỏng bộ xử lý tốt nhất hiện có. Bạn có thể dễ dàng biết rằng chất lượng hình ảnh tăng lên trên máy hầu như luôn giết chết hiệu suất đáng kể.

• Bây giờ, có các chức năng khác, chẳng hạn như trạng thái trò chơi, AI, âm thanh, đầu vào, mạng, vẫn còn quan trọng trong một trò chơi, nhưng hầu như sẽ không bao giờ chiếm nhiều tài nguyên máy tính. Những chức năng đó, hầu hết thời gian, không được tối ưu hóa. Đó là mục tiêu của ngôn ngữ kịch bản và ngôn ngữ được thu gom rác: bạn không phải suy nghĩ về sự gắn kết bộ nhớ và tổ chức ứng dụng của mình, bởi vì mã bạn sẽ viết bằng các ngôn ngữ này, nếu bạn không mã hóa nội dung cấp thấp, sẽ không bao giờ là nút cổ chai.

Ví dụ với 2 trường hợp

• Vận chuyển 500kg đồ đạc bằng xe tải.
• Vận chuyển 30 tấn vật liệu bằng thuyền.

Cả hai đều ở khoảng cách 500 km.

Trong cả hai trường hợp, có làm cho quá trình tải / dỡ hàng nhanh hơn để làm cho toàn bộ thời gian vận chuyển nhỏ hơn, biết bạn CANT làm cho thuyền cũng như xe tải di chuyển nhanh hơn?

Trả lời là: nó quan trọng với chiếc xe tải, nhưng không phải với chiếc thuyền nữa, bởi vì bạn đã làm rất nhiều bằng cách di chuyển cổ phiếu với chiếc thuyền.

Tôi không biết bạn có hiểu ẩn dụ này không, nhưng theo một cách nào đó, nó có thể khiến bạn tưởng tượng ra vấn đề toán học, điều quan trọng hơn là hiểu câu trả lời.

Ngôn ngữ kịch bản cho phép tạo trò chơi nhanh hơn nếu bạn đã có một công cụ được lập trình trong C / C ++: công cụ 3D giải quyết các vấn đề cấp thấp, bây giờ bạn phải tạo trò chơi bằng các tập lệnh của mình.

Nhưng hãy nhớ rằng: bạn hoàn toàn sẽ không bao giờ có thể thay thế ngôn ngữ được biên dịch ở mức độ thấp, EVER. Các ngôn ngữ được biên dịch, được nhập tĩnh là cốt lõi của hiệu suất và bạn không thể loại trừ chúng, đó sẽ là kernel, công cụ 3D hoặc trình điều khiển card đồ họa.

Nhưng tất nhiên, nếu trò chơi của bạn đơn giản về mặt đồ họa và không đòi hỏi nhiều tính toán véc tơ, bạn có thể tập trung vào trò chơi và quên tối ưu hóa, vì trong trường hợp này, bạn sẽ không bao giờ phải xử lý tối ưu hóa vì máy của bạn rất nhanh cho rằng

Ngoại trừ nếu bạn có kế hoạch chuyển ir trên DS. Nhưng tôi sẽ dừng ở đó.

Hãy nhìn xem, tôi biết đây là một cơn thịnh nộ nhưng tôi không chỉ chia tóc. Tôi cảm thấy hầu hết các lập trình viên không thực sự kết hợp điều này với nhau. Một ngôn ngữ tự nó không có gì để làm với tốc độ / hiệu suất chạy. Đó là trình biên dịch / khung. Bạn có thể tranh luận tốt hơn gcc với cl (trình biên dịch microsoft trước 2010) hoặc msbuild (trình biên dịch c ++ hiện tại cho năm 2010). Mỗi bản phát hành các trình biên dịch này trở nên tốt hơn, do đó bạn cũng phải so sánh chúng với các phiên bản trước đó của chính chúng. Tôi rất ấn tượng với .net và nó hoạt động tốt nhưng ngay cả khi nó hoạt động tốt hơn một chút tôi cũng không thấy nó chiếm lĩnh, một lý do: tính di động.

Trò chơi AAA muốn có trên Windows, Linux, Mac, XBox, PS3, Nintendo, v.v.