C # có khả thi cho một máy chủ trò chơi thời gian thực không? [đóng cửa]


22

Hầu hết các câu hỏi là trong tiêu đề.

Về cơ bản, tôi đang bắt đầu phát triển một game hành động nhiều người chơi 2D. Ứng dụng khách (có lẽ) sẽ ở trong XNA và tôi nghĩ tôi sẽ hỏi ở đây về việc liệu có nên sử dụng C # để phát triển phía máy chủ hay không.

Tôi đoán rằng ngôn ngữ được quản lý không phải là vấn đề vì Java đang được sử dụng trong các máy chủ trò chơi MMO (sửa tôi nếu tôi sai), vậy có lý do nào để tránh C # cho mục đích này không? Tôi cần nó phải nhanh và nhạy, để giao tiếp qua TCP, để trò chuyện với máy chủ SQL. Và nếu không có lý do để tránh C #, làm thế nào tôi triển khai một máy chủ web như vậy, đó có phải là .NET EXE chạy trên máy chủ không?


2
Bạn đã đúng về máy chủ Java MMO .
Ricket

Câu trả lời:


22

Không chỉ khả thi, nhưng thực sự tốt, theo kinh nghiệm của tôi. Tôi đã phát triển một số máy chủ MMO bằng C # và tôi phải nói rằng tôi chưa bao giờ hối hận về việc lựa chọn ngôn ngữ và nền tảng.

Có rất nhiều thư viện và công cụ tuyệt vời cho C # và .NET nói chung - mạng, ghi nhật ký, ánh xạ O / R, v.v. Và, so với Java C # thì biểu cảm hơn và ít dài dòng hơn (mặc dù một số người có thể tranh luận về điều này .. )

"Chi phí" của GC khiến một số người sợ hãi không thực sự là một vấn đề, trừ khi bạn tình cờ lạm dụng nó với hàng tỷ phân bổ mỗi giây. Ví dụ, máy chủ hiện tại của chúng tôi phân bổ tối đa 50 mb / giây dưới tải nặng và GC không đưa ra bất kỳ độ trễ đáng chú ý nào. Tuy nhiên, chúng tôi đã phải sử dụng nhóm đối tượng ở các vị trí chiến lược - quan trọng nhất là các đối tượng đại diện cho các gói mạng được gộp chung và không được thu gom rác. Tuy nhiên, ngay cả khi tắt pooling, GC không phải là vấn đề lớn nhất.

Như một ví dụ về mức độ tuyệt vời của C #, đây là những gì chúng tôi đã thực hiện gần đây. Máy chủ của chúng tôi chạy một số dịch vụ WCF, ứng dụng khách trò chơi sử dụng cho các nhiệm vụ không quan trọng về thời gian và chúng tôi cũng sử dụng chúng cho quản trị máy chủ. Hóa ra, thật dễ dàng để tạo một dịch vụ WCF chỉ đơn giản là trả lại các đối tượng trò chơi của chúng tôi cho người gọi. Vì vậy, chúng tôi đã làm điều đó, sau đó tạo một plugin nhỏ cho LINQPad kết nối với máy chủ của chúng tôi - và bây giờ chúng tôi có thể chạy các truy vấn như

from character in Service.GetOnlineCharacters()
where character.LocationManager.LocationId==5 && character.Attributes.Level<10
select new { character.Id, character.Nick }

Trên một máy chủ trực tiếp, không ít! Tôi không nghĩ bạn có thể làm điều này với bất kỳ nền tảng nào khác. Không phải trong công việc vài ngày, ít nhất.


Tôi đặc biệt thích việc sử dụng LINQ, điều này làm cho máy chủ trở nên đơn giản hơn và nhanh hơn để phát triển.
Thomas

26

Chắc chắn, bạn có thể sử dụng C #.

Một trong những vấn đề lớn hơn cần lưu ý về hiệu suất trong C # hoặc các hệ sinh thái .NET khác là GC - khung .NET cung cấp một số hương vị của GC , bao gồm cả "máy chủ", đáng để tìm hiểu. Quản lý bộ nhớ thông minh (ví dụ, bằng cách gộp) vẫn là một kỹ thuật tốt ngay cả trong môi trường được quản lý.

Có một số API mạnh mẽ để tương tác với SQL, giao tiếp qua TCP, et cetera trong C #, là một phần của khung cơ sở hoặc thông qua bên thứ ba, do đó bạn không gặp khó khăn gì ở đó.

Bạn có thể sử dụng ASP.NET hoặc tương tự nếu bạn thực sự muốn máy chủ của mình dựa trên web; nếu bạn chỉ muốn chạy một quy trình và lắng nghe các kết nối TCP, bạn có thể triển khai một phần mềm .exe và các phụ thuộc thích hợp cho máy chủ, mở các cổng thích hợp và chạy .exe.


5

Tôi nghĩ đó là ý kiến ​​hay. Ngôn ngữ chắc chắn có khả năng của nó, và đặc biệt nếu đó là những gì bạn biết, đừng dành nhiều thời gian để học một ngôn ngữ mới chỉ vì nó "nhanh hơn". Nút thắt thực sự của máy chủ của bạn sẽ là độ trễ mạng; thêm một hoặc hai phần nghìn giây vì bạn đã sử dụng C # thay vì C ++ sẽ không tạo ra sự khác biệt.


5
Nguy cơ thực sự của phát triển trò chơi (hoặc bất kỳ sự phát triển theo thời gian thực nào) trong các ngôn ngữ được quản lý không phải là mọi thứ mất một hoặc một phần nghìn giây, mà các khung ngẫu nhiên đó sẽ mất hàng chục mili giây vì GC quyết định hoàn thiện mọi thứ. Việc khuyến khích các so sánh tập trung vào thông lượng với các thuật ngữ như "nút cổ chai" là sai lệch.

3

Nếu bạn triển khai trên Windows thì không sao, tôi thực sự khuyên bạn nên dùng nó, đặc biệt vì máy khách của bạn là C #.

Đừng đánh giá thấp sự phát triển máy chủ trò chơi mặc dù. Ngay cả việc tạo một máy chủ đồng thời chỉ trò chuyện đơn giản cũng không phải là một việc nhỏ và bạn sẽ sớm có rất nhiều câu hỏi liên quan đến đồng thời, khóa, hiệu suất, v.v.

Cũng như một điểm khởi đầu, tôi muốn bạn xem trang này giải thích rộng rãi về cách thực hiện lập trình ổ cắm đồng thời trong một số nền tảng:

http://geekswithbloss.net/quension/archive/2006/06/30/83760.aspx

Nếu bạn thực sự nghiêm túc về điều đó, tôi khuyên bạn nên nghiên cứu kỹ về lập trình mạng Unix của Stevens. Nó tập trung vào ổ cắm C trên Unix, nhưng các nguyên tắc là giống nhau cho mọi nền tảng khác, bao gồm cả .net.

Chỉnh sửa: Đây là một tài nguyên tuyệt vời khác, tập trung vào khả năng mở rộng và hiệu suất cho các máy chủ đồng thời trong .net. Nó không còn nữa, nhưng bạn bè của chúng tôi ở máy quay lại có một bản sao của nó.

http://replay.waybackmachine.org/20080405220143/http://www.coversant.net/dotnetnuke/Coversant/Blogs/tabid/88/EntryID/10/Default.aspx


1

Một "nhược điểm" sẽ là với C # nếu bạn muốn sử dụng nó trên nhiều nền tảng, bạn phải rất cẩn thận để đảm bảo rằng mã của bạn sẽ hoạt động với đơn âm. Nếu tất cả những gì bạn quan tâm là chạy nó trên một nền tảng duy nhất và các cửa sổ là nền tảng đó, thì bạn sẽ không gặp vấn đề như những người khác đã đề cập.


Đừng quên rằng MONO có thể được sử dụng để triển khai trên các nền tảng khác. Tôi tin rằng Cuộc sống thứ hai sử dụng phương pháp này - các kịch bản trò chơi nội bộ của họ thực sự được biên dịch sang .NET IL nhưng họ triển khai trên Linux AFAIK.
ShadowChaser
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.