Tạo dự án Unity riêng biệt cho máy chủ không đầu

Question

Tôi muốn tạo một máy chủ không có đầu để xử lý trò chơi nhiều người chơi của tôi. Đây sẽ là một dự án chứng minh-khái niệm, nhưng về cơ bản tôi chỉ muốn có nhiều người chơi (cho phép nói 3) để di chuyển một hộp xung quanh. Vì vậy, mỗi người chơi có thể di chuyển hộp cùng một lúc (tưởng tượng một quả bóng được di chuyển xung quanh bởi nhiều người chơi).

Bây giờ tôi tự hỏi làm thế nào tôi nên cấu trúc mã của tôi. Tôi đã suy nghĩ để có một dự án riêng biệt cho máy chủ, mà tôi có thể chạy không đầu trên một máy chủ Linux, và một dự án khác cho bản thân trò chơi. Tất cả các máy chủ không phải là thông qua các tin nhắn xung quanh nơi hộp hiện đang và những người di chuyển nó.

Tôi mới làm quen với Unity, do đó, không chắc chắn nếu điều này là khôn ngoan. Hoặc tôi nên đặt máy chủ như là một cảnh riêng biệt trong cùng một dự án? Hoặc một cách tiếp cận hoàn toàn khác?

Answer 1

Bạn đã đạt được một câu hỏi hay.

Dưới đây là ba khả năng:

(A) Một số người thích để có cả hai bên trong một kịch bản. (Rõ ràng trong một dự án tương tự.)

(B) Một số người thích để có hai kịch bản, nhưng trong dự ánmột. Vì vậy, ứng dụng sẽ khởi chạy và sau đó ứng dụng sẽ quyết định xem đó là máy chủ hay ứng dụng khách.

(C) Một số người thích có hai dự án hoàn toàn riêng biệt. Vì vậy, một dự án là khách hàng và một là máy chủ.

Một số thông tin quan trọng về ba:

Vì vậy, bạn phải quyết định giữa ba phương pháp tiếp cận.

Về "A":

1. Nhiều người trong số các mẫu mã treo xung quanh trên web từ những ngày đầu của Unity, xảy ra được hình thức "A". Khi những năm tháng trôi qua, điều này trở nên ít sự thật hơn, nhưng nói chung "mã Unity cũ nằm xung quanh trên www" là một mối nguy hiểm nói chung.

2. (Trên thực tế, chỉ đơn giản là vì lý do đó, nhiều lập trình viên người mới vào nghề đã học chương trình tổng thể sử dụng Unity và bằng cách tìm mảnh vỡ Unity trên web, suy nghĩ hoặc nghĩ rằng bạn "có sử dụng" phương pháp A.)

3. Hãy nhận biết rằng nổi tiếng nhất nhiều mã mẫu cho Unity đặt xung quanh trên web là hoàn toàn ngớ ngẩn. Thật vậy, các mẫu mạng bạn thấy thường là một ví dụ điển hình về điều này.

4. Cá nhân tôi tìm cách tiếp cận "A" đáng kể khó hiểu và vô nghĩa. Thật vậy trong nhiều năm tôi đã cố gắng để xem những gì lợi thế có thể được. Ưu điểm duy nhất tôi từng có thể tìm ra là: nó tiết kiệm không gian ổ đĩa. vì vậy, thay vì có hai tập lệnh, bạn sẽ có một tập lệnh - điều này có thể tiết kiệm trên một KB dung lượng trên các ổ đĩa của bạn. Tôi không thể, bản thân mình, thấy bất kỳ mục đích nào khác trong việc kết hợp hai khái niệm này với nhau.

Về "B":

1. Đây là có lẽ là con đường để đi cho các dự án quy mô vừa. Nhược điểm ở đây là ứng dụng phải về cơ bản biết chia tách chính nó thành hai ứng dụng riêng biệt. Nếu triển khai là quan trọng, nếu nó phải là "GI Proof", B dễ hơn C (cho những người triển khai nó - họ chỉ khởi chạy "một số ứng dụng" và nó hoạt động trên đó là cách cư xử của riêng mình, những người triển khai không phải tìm ra ứng dụng nào cần triển khai, tần suất, v.v.); nhưng sau đó sẽ khó hơn cho các nhà phát triển.

Về "C":

1. Nếu hệ thống là (nói) một cái gì đó để làm với an ninh hoặc giao dịch, bạn sẽ muốn làm điều này, vì vậy mà tất cả mọi thứ là KISS và có ít cơ hội thất bại hơn thông qua sự nhầm lẫn. Nếu hai phần của hệ thống là tự nhiên khác nhau hơn, nó làm cho tinh thần để làm điều này anyway. (Nếu hai mặt của hệ thống khá giống nhau, bạn sẽ nghiêng về phía B.)

2. Nếu dự án rất lớn (ví dụ, nhiều kỹ sư) tất nhiên C dễ dàng hơn vì nó bị hỏng nhiều hơn. Nó sẽ làm cho bạn tự nhiên hóa chính thức hơn các giao thức truyền thông giữa hai, v.v.

C là "luôn luôn đúng". B có thể hữu ích cho "triển khai tiện lợi". Và chắc chắn, nếu bạn chỉ làm một bài kiểm tra "hello world", A rất hữu ích (nếu khó hiểu).

---

Để có thêm ý kiến ​​về câu hỏi khó này, người ta phải trình bày rõ ràng trường hợp triển khai; nghĩa là nó là một trò chơi cửa hàng ứng dụng, là một cài đặt kiosk một lần, phần mềm toàn nhà máy hay bất kỳ trường hợp nào có thể xảy ra. Chúc mừng