Domain Driven Design có tốt cho game không?

Tôi mới đọc về các mô hình Miền và nó đã khai sáng cho tôi vì tôi đã phát triển một trò chơi có một lớp chỉ chứa dữ liệu (một vài hành vi / phương thức). Tôi đã giao công việc xử lý các lớp này cho các nhà quản lý ... và bây giờ người quản lý của tôi dường như trông giống như một đối tượng của Chúa. Đối tượng trò chơi của tôi được cho là xử lý logic chỉ là một mô hình miền thiếu máu.

Mẫu thiết kế hiện tại của tôi là ở Singleton và tôi muốn thực hiện một số mã hóa để đưa công cụ này ra ngoài. Tôi chưa bao giờ thấy DDD trên các trò chơi (tính đến thời điểm hiện tại) nhưng đây có phải là một cách tiếp cận tốt? Tôi chỉ là một lập trình viên mới làm quen (không thiên về trò chơi) nên tôi muốn tìm hiểu thêm về kiến ​​trúc tốt trước khi trò chơi trở nên quá phức tạp để thiết kế lại.

Tôi chưa bao giờ nghe nói về thiết kế hướng tên miền trước bài viết của bạn. Nhìn nhanh vào một vài tài liệu tham khảo - ở đây và ở đây - dường như gợi ý rằng đó chỉ là một cái tên lạ mắt cho phương pháp lập trình hướng đối tượng truyền thống của thập niên 90 mà tôi được dạy ở trường đại học, nơi bạn thử và viết các lớp cho mỗi danh từ xuất hiện trong tình huống bạn đang cố gắng mô hình hóa bằng phần mềm, để cấu trúc của phần mềm dường như tuân theo cấu trúc của khái niệm thế giới thực.

Như vậy, câu trả lời của tôi cho điều này là nó không "tốt". Đó thường là điểm khởi đầu hợp lý nhưng chứng tỏ là không đủ khi bạn đi cùng. Bạn hiếm khi có một tên miền duy nhất nhưng một số tên miền khác nhau trong một phần mềm - ví dụ: bạn có thể có miền của trò chơi (thế giới, nhân vật, vật phẩm), miền của trình kết xuất (trình tạo bóng, lưới, các tài liệu), miền đầu vào (hệ thống tập tin, mạng, bàn phím và chuột) và các vấn đề xảy ra trong đó các miền chồng chéo và ảnh hưởng lẫn nhau. Thông thường trong quá trình tham gia 2 tên miền với nhau, bạn nhận ra rằng thực sự có một sự phụ thuộc ở đó đòi hỏi phải thay đổi, nghĩa là một trong những đại diện của bạn trở thành gánh nặng hơn là sự giúp đỡ.

Một ví dụ mơ hồ có thể là một thư viện toán học trên bảng điều khiển và các nhân vật trong trò chơi của bạn. Thư viện toán học của bạn sẽ muốn có một danh sách dữ liệu lớn và sau đó 1 hướng dẫn để thực hiện trong danh sách đó, để chạy hiệu quả. Mỗi nhân vật trong trò chơi của bạn sẽ có một bộ dữ liệu đỉnh riêng để kết xuất và hoạt hình, v.v ... Bây giờ, làm thế nào để bạn có được một danh sách dài tất cả dữ liệu đỉnh từ mỗi nhân vật của bạn để có thể xử lý nó trong một lần? Bạn có thể thực hiện thao tác sao chép chậm hoặc thay vào đó bạn có thể cấu trúc lại các ký tự của mình để dữ liệu của chúng dễ dàng được xử lý hơn bởi thư viện toán học - nhưng sau đó, một trong các miền của bạn bị phá vỡ để ưu tiên cho một tên miền khác.

Cá nhân tôi rất cảnh giác với bất kỳ nhãn nào giống với "Dù được thiết kế theo hướng nào". Phần mềm vừa quá rộng vừa quá phức tạp để có cách tiếp cận một kích cỡ phù hợp với tất cả để tạo ra nó. Thay vào đó, khi cố gắng viết phần mềm tốt nhất có thể, tôi đã thử và dựa vào các nguyên tắc RẮN . Những điều này cung cấp cho bạn một ý tưởng tốt về việc mã của bạn tốt như thế nào, mà không hứa hẹn một liều thuốc cho phương pháp mà bạn có thể làm theo và kỳ diệu đạt được mã tốt. Thật không may, không có một phương pháp kèm theo như vậy, phải mất rất nhiều kinh nghiệm trước khi bạn học cách tuân thủ các nguyên tắc này, đó có lẽ là lý do tại sao rất nhiều người thích các phương pháp này.

Về vấn đề bạn có các lớp thiếu máu và các đối tượng người quản lý, đây thường là vấn đề được đề cập trong các bài học định hướng đối tượng giới thiệu và không thực sự yêu cầu bạn tuân thủ bất kỳ phương pháp đặc biệt nào để 'khắc phục' nó. (Bạn có thể muốn chọn một cuốn sách về lập trình hướng đối tượng nếu bạn mới bắt đầu.) Một lớp là sự kết hợp giữa trạng thái và hành vi, trong đó hành vi sửa đổi trạng thái đó và điều này được gọi là đóng gói. Nói chung, bạn cố gắng và đóng gói càng nhiều càng tốt, điều đó có nghĩa là trạng thái nên được thao tác bởi chính đối tượng (và chỉ đối tượng đó). Chỉ đối với hành vi không thể được mô hình hóa trong lớp, bạn mới ủy quyền cho một lớp bên ngoài, chẳng hạn như người quản lý, đó là lý do tại sao sự tồn tại của các lớp trình quản lý thường được coi là dấu hiệu của mã hướng đối tượng được viết kém.

Mẫu thiết kế hiện tại của tôi là ở Singleton và tôi muốn thực hiện một số mã hóa để đưa công cụ này ra ngoài.

Tôi không biết ý của bạn là gì bởi dòng đó. Một mẫu thiết kế là một cách nổi tiếng để viết một phần nhỏ trong chương trình của bạn. Bạn sẽ không có mẫu thiết kế 'hiện tại', cũng sẽ không định hình phần còn lại của chương trình. Đối với người mới bắt đầu, các mẫu này rất hữu ích để giúp bạn đi đúng hướng, trong khi đối với các chuyên gia, họ có nhiều cách để truyền đạt về các tình huống mã phổ biến. Tuy nhiên, có một điều quan trọng: singletons hầu như luôn là một ý tưởng tồi và bạn nên tránh chúng bất cứ khi nào có thể. Bạn có thể tìm thấy nhiều ý kiến ​​về singletons trên trang web này và trên Stack Overflow, nhưng đây là một câu hỏi thực tế với câu trả lời giúp bạn tránh cần chúng.

Mô hình

Tính đến thời điểm mà câu trả lời này được viết, các câu trả lời được đăng khác ở đây đều sai.

Thay vì hỏi liệu Thiết kế hướng tên miền có tốt cho trò chơi hay không. Bạn nên hỏi liệu "Mô hình miền" có tốt cho trò chơi hay không.

Mô hình miền có tốt cho trò chơi không?

Câu trả lời là: đôi khi nó hoàn toàn tuyệt vời. Tuy nhiên, nếu bạn đang tạo một trò chơi thời gian thực như platformer hoặc FPS hoặc bất cứ điều gì (NHIỀU NHIỀU loại trò chơi) thì không. Nó không nhất thiết phải phù hợp cho các hệ thống đó. Tuy nhiên, có thể có các hệ thống trong đó các trò chơi triển khai mẫu mô hình miền có hiệu quả.

Như những người khác đã đề cập ở đây, các khung thành phần thực thể có xu hướng rất phổ biến và vì lý do chính đáng. Tuy nhiên, trong văn hóa phát triển trò chơi dường như thiếu kiến ​​trúc phân lớp. Một lần nữa, đây là lý do chính đáng vì hầu hết các trò chơi mà mọi người sẽ phát triển chỉ biến đổi trạng thái trên các thực thể và để cho hậu quả nổi lên là trò chơi.

TẤT CẢ PHẦN MỀM KHÔNG PHẢI LÀ PHẦN MỀM MÀ BẠN ĐANG VIẾT. Một số khá khác với những người khác.

Một số ví dụ về các miền mà mô hình miền hoạt động tốt là trò chơi bài, trò chơi trên bàn và các loại hệ thống khác được điều khiển theo sự kiện.

Các trò chơi chạy ở tốc độ khung hình X với chuyển động, vv được xác định bởi các vùng đồng bằng thời gian vì các khái niệm miền cốt lõi có lẽ không phù hợp lắm. Trong trường hợp này, "miền" của chúng tôi thường đơn giản đến mức không cần mô hình hóa miền. Phát hiện va chạm, sinh sản của các thực thể mới, ảnh hưởng của các lực lượng đối với các thực thể hiện có, vv có xu hướng bao trùm hầu hết các trò chơi.

Tuy nhiên, khi mọi thứ trở nên phức tạp, bạn bắt đầu thấy các nhà phát triển triển khai các mô hình miền trong các thực thể của họ để xử lý các loại hành vi và tính toán nhất định.

Mô hình mô hình miền trong kiến ​​trúc trò chơi

Công cụ trò chơi của bạn (ví dụ: Unity3D) thường được định hướng theo thành phần. Trong một platformer, bạn có thể có một thực thể cho nhân vật của mình và trạng thái của nó liên tục bị thay đổi để cập nhật vị trí, v.v.

Tuy nhiên, trong một trò chơi hướng sự kiện nhiều hơn, nhiều khả năng vai trò của khung thực thể thành phần không chỉ tồn tại dưới dạng Giao diện người dùng. Bạn kết thúc với một kiến ​​trúc lớp.

UI hiển thị trạng thái trò chơi cho người dùng. Người dùng tương tác với UI, kích hoạt các lệnh trong lớp dịch vụ. Lớp dịch vụ tương tác với các đối tượng miền. Các đối tượng miền nâng sự kiện miền. Người nghe sự kiện nghe các sự kiện và kích hoạt thay đổi trong UI.

UI> Lớp dịch vụ> Mô hình miền

Nói tóm lại, kết thúc với trình điều khiển mô hình-khung nhìn với việc triển khai lớp dịch vụ.

Sử dụng kiến ​​trúc này, bạn có một lõi trò chơi hoàn toàn có thể kiểm tra đơn vị (Rất hiếm trong văn hóa phát triển trò chơi và nó hiển thị) với giao diện hướng sự kiện.

Được rồi, DDD là gì?

Thiết kế hướng tên miền cụ thể là văn hóa / phong trào nhấn mạnh vào các mẫu phân tích được sử dụng để tìm hiểu về tên miền, để bạn thực sự xây dựng đúng, và sau đó triển khai các mẫu cho phép bạn triển khai lớp mô hình đại diện cho các khái niệm trong mô hình miền sử dụng thành ngữ ngôn ngữ của bạn. DDD ra khỏi một cộng đồng làm việc với các miền phức tạp và luôn tìm cách quản lý độ phức tạp cao trong các ứng dụng của họ bằng cách tập trung vào mô hình hóa miền.

DDD không làm tốt như vậy nếu mục tiêu của bạn là bắt đầu viết mã, chơi xung quanh với hệ thống và sau đó tìm ra những gì bạn muốn xây dựng sau này, v.v ... Nó giả định rằng có ít nhiều một miền tồn tại. Vì vậy, nếu bạn không biết trò chơi của bạn sẽ là gì .. Sau đó, nó sẽ không hoạt động.

Không, tôi không nghĩ DDD, hoặc bất kỳ kiến ​​trúc "từ thông dụng" nào khác thực sự tốt cho các trò chơi. Ngoại trừ có thể có "hệ thống thành phần", có vẻ như thực sự phổ biến ở đây.

Khi tôi nghe câu hỏi và thảo luận như thế này, tôi đã nhắc về trang web này . Suy ngẫm về các từ thông dụng kiến ​​trúc khác nhau thường sẽ làm bạn kém hơn so với việc thực sự thiết kế và mã hóa ứng dụng của riêng bạn.

Có, nhưng bạn nên thích nghi.

Khi sử dụng DDD, bạn sẽ nhận được tính mô đun và trách nhiệm duy nhất của mỗi miền. Nhưng bất cứ điều gì khác chỉ làm cho mọi thứ phức tạp.

Xem câu trả lời của tôi ở đây