Một số mẫu thiết kế lập trình hữu ích trong phát triển trò chơi là gì? [đóng cửa]

Tôi có một vài cuốn sách về Mẫu thiết kế, và đã đọc một số bài viết, nhưng không thể tìm ra bằng trực giác những mẫu thiết kế lập trình nào sẽ hữu ích trong phát triển trò chơi.

Ví dụ: tôi có một cuốn sách có tên ActionScript 3 với các mẫu thiết kế mô tả chi tiết một số mẫu thiết kế như Model View Controller, Singleton, Factory, Command, v.v.

Là một người mới làm điều này, tôi không thể tìm ra cái nào trong số này sẽ hữu ích, hoặc trên thực tế nếu có bất kỳ mẫu nào trong số này là các mẫu thiết kế tôi nên học và cố gắng sử dụng. Có lẽ có những mẫu thiết kế dành riêng cho lập trình trò chơi khác mà tôi thậm chí không nhận ra?

Nếu bạn có kinh nghiệm sử dụng một mẫu thiết kế nhất định trong phát triển trò chơi, tôi rất muốn nghe nó. Lý do là tại sao nó được sử dụng, các mẫu mã hoặc tài nguyên trực tuyến đều rất hữu ích nếu bạn có chúng. Hiện tại tôi quan tâm nhất đến việc triển khai ActionScript 3 và C ++, nhưng chắc chắn có thể hưởng lợi từ kinh nghiệm và ví dụ từ bất kỳ ngôn ngữ nào.

Cảm ơn!

Bây giờ cho một phản ứng ít flippant, với một số gợi ý. Đừng coi đây là những khuyến nghị thực hiện, nhiều hơn là những ví dụ về việc sử dụng có thể.

• Trình tạo: thiết lập một thực thể dựa trên thành phần một thành phần tại một thời điểm, dựa trên dữ liệu
• Phương thức xuất xưởng: tạo NPC hoặc tiện ích GUI dựa trên chuỗi được đọc từ tệp
• Nguyên mẫu: lưu trữ một nhân vật 'Elf' chung chung với các thuộc tính ban đầu và tạo các thể hiện Elf bằng cách nhân bản nó.
• Singleton: không gian này cố tình để trống.
• Bộ điều hợp: kết hợp một thư viện bên thứ 3 tùy chọn bằng cách gói nó trong một lớp trông giống như mã hiện tại của bạn. Rất hữu ích với DLL.
• Kết hợp: tạo biểu đồ cảnh của các đối tượng có thể kết xuất hoặc tạo GUI từ cây Widgets
• Mặt tiền: đơn giản hóa các thư viện bên thứ 3 phức tạp bằng cách cung cấp giao diện đơn giản hơn để giúp cuộc sống của bạn dễ dàng hơn sau này.
• Fly weight: lưu trữ các khía cạnh được chia sẻ của một NPC (ví dụ: mô hình, kết cấu, hình động) tách biệt với các khía cạnh riêng lẻ (ví dụ: vị trí, sức khỏe) theo cách gần như minh bạch
• Proxy: Tạo các lớp nhỏ trên máy khách đại diện cho các lớp lớn hơn, phức tạp hơn trên máy chủ và chuyển tiếp yêu cầu qua mạng.
• Chuỗi trách nhiệm: xử lý đầu vào như một chuỗi xử lý, ví dụ. các phím toàn cầu (ví dụ: để chụp ảnh màn hình), sau đó GUI (ví dụ: trong trường hợp hộp văn bản được tập trung hoặc menu được bật lên), sau đó trò chơi (ví dụ: để di chuyển một ký tự)
• Lệnh: đóng gói chức năng trò chơi dưới dạng các lệnh có thể được nhập vào bảng điều khiển, được lưu trữ và phát lại hoặc thậm chí được viết kịch bản để giúp kiểm tra trò chơi
• Người hòa giải: triển khai các thực thể trò chơi như một lớp hòa giải nhỏ hoạt động trên các thành phần khác nhau (ví dụ: đọc từ thành phần sức khỏe để truyền dữ liệu đến thành phần AI)
• Người quan sát: có biểu diễn có thể hiển thị của một nhân vật lắng nghe các sự kiện từ biểu diễn logic, để thay đổi cách trình bày trực quan khi cần thiết mà không cần logic trò chơi cần biết bất cứ điều gì về kết xuất mã
• Trạng thái: lưu trữ NPC AI là một trong một số trạng thái, ví dụ: Tấn công, lang thang, chạy trốn. Mỗi người có thể có phương thức update () riêng và bất kỳ dữ liệu nào khác mà họ cần (ví dụ: lưu trữ nhân vật mà nó đang tấn công hoặc chạy trốn khỏi khu vực mà nó đang đi lang thang, v.v.)
• Chiến lược: chuyển đổi giữa các phương pháp phỏng đoán khác nhau cho tìm kiếm A * của bạn, tùy thuộc vào loại địa hình bạn đang ở hoặc thậm chí có thể sử dụng cùng một khung A * để thực hiện cả việc tìm đường và lập kế hoạch chung hơn
• Phương thức mẫu: thiết lập thói quen 'chiến đấu' chung chung, với các chức năng móc khác nhau để xử lý từng bước, ví dụ: giảm đạn, tính toán cơ hội trúng, giải quyết trúng hoặc bỏ lỡ, tính toán thiệt hại và mỗi loại kỹ năng tấn công sẽ thực hiện các phương pháp theo cách riêng của họ

Một số mẫu bỏ đi do thiếu cảm hứng.

Tôi đã viết một cuốn sách về chính xác chủ đề đó: Các mẫu lập trình trò chơi . Các chương có thể có ích cho bạn.

Một điều mà Brandon Eich có ý thức tốt trong việc đưa ra Coders tại nơi làm việc là các mẫu là hack và cách giải quyết: [Các mẫu] cho thấy một số khiếm khuyết trong ngôn ngữ. Những mẫu này không miễn phí. Không có bữa trưa miễn phí. Vì vậy, chúng ta nên tìm kiếm sự tiến hóa trong ngôn ngữ có thêm các bit đúng.

Là lập trình viên trò chơi thay vì thiết kế trình biên dịch, chúng tôi hiếm khi có tùy chọn phát triển ngôn ngữ chúng tôi sử dụng, nhưng chúng tôi có thể học cách phát triển phong cách của riêng mình để phù hợp hơn với ngôn ngữ và yêu cầu của chúng tôi. Các mẫu là một số trong số này, nhưng không sử dụng các mẫu là một phần khác, đặc biệt là như Brandon nói, các mẫu hiếm khi đi mà không có hiệu năng đáng chú ý hoặc chi phí bộ nhớ hoặc mã linh hoạt. MVC không phải là một mô hình tuyệt vời cho nhiều thứ trong các trò chơi. Singleton là một cách giải quyết cho các quy tắc khởi tạo tĩnh C ++ khập khiễng và có lẽ bạn không nên thực hiện chúng. Factory đơn giản hóa việc tạo đối tượng phức tạp - có thể các đối tượng của bạn nên đơn giản hơn để bắt đầu. Các mô hình phổ biến là công cụ để sử dụng khi chúng ta cần chúng để quản lý một cái gì đó phức tạp, không phải là công cụ chúng ta nên mong muốn sử dụng để xây dựng một cái gì đó phức tạp khi bắt đầu.

Mã (trò chơi) tốt có thể sử dụng các mẫu hoặc có thể không. Nếu nó sử dụng các mẫu, tốt thôi - chúng là một công cụ giao tiếp tuyệt vời để giải thích cấu trúc mã cho các lập trình viên khác ở mức độ cao, không phụ thuộc vào ngôn ngữ. Nếu bạn nghĩ rằng mã tốt hơn mà không cần sử dụng một mẫu, đừng tự đánh bại nó - có lẽ là vậy.

Tất nhiên, như những người khác đã nói, tất cả các mẫu đều hữu ích trong trường hợp phù hợp và một phần của việc học cách sử dụng chúng là học khi nào nên sử dụng chúng. Tuy nhiên, cuốn sách xuất sắc Kỹ thuật và thuật toán cốt lõi trong lập trình trò chơi của Daniel Sanchez-Crespo Dalmau, liệt kê sáu mẫu lập trình và sáu mẫu khả dụng đặc biệt hữu ích trong lập trình trò chơi.

Lập trình:

• Singleton: Tôi không ghét điều này giống như nhiều người làm; nó có thể được sử dụng cho những thứ như trình phát một người chơi hoặc đầu đọc bàn phím.
• Factory: Cho phép bạn tạo và phá hủy các đối tượng một cách hiệu quả.
• Chiến lược: Cho phép bạn thay đổi chiến lược AI một cách thanh lịch.
• Chỉ mục không gian: Giúp thực hiện các truy vấn trên các tập dữ liệu không gian.
• Hợp chất: Thiết lập một đối tượng thừa kế hữu ích.
• Fly weight: Giải phóng bộ nhớ bằng cách khái quát những thứ như kẻ thù giống hệt nhau.

Khả năng sử dụng:

• Shield: Bảo vệ khỏi sự kích hoạt tình cờ của các hành động kịch tính.
• Trạng thái: Dấu hiệu trực quan của trạng thái thế giới / UI.
• Tự động hủy chế độ: Làm cho trò chơi hoạt động tích cực hơn.
• Từ tính: Tự động và lựa chọn đơn vị dễ dàng.
• Tập trung: Loại bỏ các yếu tố UI gây mất tập trung.
• Tiến độ: Toàn cầu hữu ích.

Cuốn sách, tất nhiên, đi vào chi tiết hơn về mỗi trong số này.

Hệ thống thực thể là một loại mô hình tốt đẹp. Nó không chính xác là một mẫu thiết kế vì nó không khéo léo OOP. Tuy nhiên, bạn có thể trộn nó với OOP.

Một số liên kết tốt (bắt đầu từ đầu cho phần giới thiệu):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbasing_entity_systems

Tất cả bọn họ. Ngoại trừ Singleton. [/ flippancy]

Không thực sự về các mẫu, nhưng về các nguyên tắc cơ bản đằng sau chúng. Trong "Design Patterns: Elements of Reusable Software Object-Oriented" (1995) , các băng đảng của bốn (Gamma, Erich; Richard Helm, Ralph Johnson, và John Vlissides) khuyến cáo chỉ có hai nguyên tắc cho hướng đối tượng thiết kế: (1) chương trình để một giao diện và không triển khai và (2) ủng hộ thành phần đối tượng hơn kế thừa lớp.

Hai nguyên tắc này rất hữu ích trong nhiều nhiệm vụ phát triển trò chơi. Ví dụ, nhiều lập trình viên trò chơi đã sử dụng hệ thống phân cấp lớp sâu để thể hiện các thực thể trò chơi. Có một cách tiếp cận khác dựa trên thành phần - các đối tượng trò chơi dựa trên thành phần. Bài viết về phương pháp này. Thậm chí nhiều liên kết hơn . Đây là một ví dụ mẫu trang trí .

Các mẫu hoa văn một cách tò mò lặp đi lặp lại có thể được thực sự hữu ích để tránh các phương pháp ảo và hình phạt hiệu suất có thể đến từ các cuộc gọi chức năng ảo.

Đây có thể là mẫu thích hợp khi bạn thực sự không cần phải có một loại lớp cơ sở có giao diện mà bạn theo đuổi, nhưng bạn muốn có các hành vi và giao diện được đặt tên tương tự.

Ví dụ, bạn có thể sử dụng điều này khi biên dịch các lớp cho nhiều nền tảng hoặc công cụ (dx so với opengl) trong đó phương sai của kiểu được biết đến tại thời điểm biên dịch.

Một mẫu thiết kế mà tôi đã phát triển trong suốt nhiều năm, và nó rất hữu ích với tôi, là thứ mà tôi gọi là "bộ định nghĩa được môi giới"; Làm thế nào để tóm tắt nó theo thuật ngữ GOF có vẻ gây tranh cãi, nhưng câu hỏi này tôi đã viết về nó trên StackOverflow đi vào một số chi tiết về nó.

Khái niệm cốt lõi là một số thuộc tính của một mô hình, như loài của sinh vật, được thiết lập sao cho mỗi giá trị có thể có của thuộc tính có một đối tượng định nghĩa tương ứng - một đối tượng được chia sẻ cho mỗi giá trị - chỉ định hành vi của nó, và những thứ này được truy cập thông qua một nhà môi giới trung tâm (mà GOF-khôn ngoan, có thể là Cơ quan đăng ký, Nhà máy hoặc cả hai). Theo cách sử dụng của tôi, chúng cũng thường được truy cập thông qua các khóa vô hướng, để tạo điều kiện ràng buộc yếu cho các mục đích hình thái thời gian chạy.