Logic trò chơi giống nhau trên hai thư viện đồ họa riêng biệt

Triết lý / cấu trúc mã trừu tượng / thiết kế chương trình nào sẽ cho phép một trò chơi được sử dụng với cả đồ họa 2D và 3D (riêng biệt) mà KHÔNG phải mã hóa lại logic trò chơi?

Chúng ta đang nói về việc sử dụng cùng một mã, thay đổi tối thiểu mọi thứ (ví dụ: trao đổi tên tệp cho tài sản 2D bằng tên tệp cho tài sản 3D) và có thể cắm một vài chuyên ngành của lớp cơ sở cho mỗi mẫu chung / mẫu.

Để đặt nó trong một bối cảnh thực tế, có ý nghĩa: hãy tưởng tượng một trò chơi nhiều người chơi trong đó có một ứng dụng khách 3D nổi tiếng, hiệu năng cao cho người chơi với một số game thủ thực sự giỏi và một máy khách 2D khiêm tốn hơn cho người cũ hộp bụi mà ai đó tìm thấy trên gác mái của họ. Nhưng đây vẫn là cùng một trò chơi - các sự kiện tương tự đã được đăng ký (ai đó nhặt được một đồng xu), cùng một giao thức Mạng được sử dụng, các thế giới tỷ lệ thuận, v.v.

Để đặt nó trong ngữ cảnh MVC: Bộ điều khiển giống hệt nhau (nhấn phím "Lên" sẽ đặt tốc độ tăng tốc của người chơi ở mức 3,5 đơn vị / giây), Chế độ xem hoàn toàn khác nhau (2D so với 3D) và Mô hình giống nhau ngoại trừ mọi thứ liên quan trực tiếp đến đồ họa (kiểm tra va chạm cho môi trường được thực hiện cứ sau 5 giây và nó sử dụng cùng một thuật toán. Lưu ý rằng điều này có nghĩa là có tọa độ Z cho tất cả các Đối tượng trò chơi trong phiên bản 2D, nhưng nó chỉ bị bỏ qua hoặc hiển thị cho người dùng theo một cách khác, ví dụ như một bóng được hiển thị xa hơn khi người chơi ở trên không).

Điều làm cho chủ đề này trở nên hấp dẫn là nó sẽ khiến nhà phát triển có một ý tưởng rất rõ ràng về cách dữ liệu của anh ta được cấu trúc và cách điều khiển chảy. Lưu ý rằng điều này không ngụ ý sử dụng bất cứ thứ gì ngoài thư viện đồ họa như SDL, D3DX hoặc OpenGL. Không có công cụ trò chơi!

Vì đây là câu hỏi chủ yếu về mặt lý thuyết, tôi sẽ bỏ các ngôn ngữ lập trình ra khỏi nó, nhưng nếu bạn muốn đưa ra một ví dụ, bạn có thể sử dụng bất kỳ ngôn ngữ nào bạn thích, C ++ nếu bạn muốn sử dụng toàn bộ con lợn hoặc thậm chí là Brainfuck nếu bạn cảm thấy cho đến thử thách (Bất kỳ câu trả lời cụ thể nào cũng sẽ được đánh giá cao, cũng như bất kỳ câu trả lời trừu tượng nào!).

Tôi nghĩ rằng tất cả (?) Bạn sẽ cần là một lớp trừu tượng bao bọc thư viện đồ họa của bạn; bạn sẽ cần một cái mới cho mỗi thư viện bạn sẽ sử dụng và mỗi thư viện sẽ cần có cùng một API bên ngoài.

Hãy nghĩ đến việc bản địa hóa các chuỗi: thay vì mã hóa cứng chuỗi "Inventory" vào trò chơi của bạn, thay vào đó bạn sẽ gọi thư viện bản địa hóa (có thể được tùy chỉnh) của mình, sẽ thực hiện một số quy trình và trả về một chuỗi thích hợp, tùy thuộc vào ngữ cảnh của tro choi.

Theo cùng một cách, tất cả các cuộc gọi đến công cụ đồ họa của bạn sẽ được thực hiện thông qua trình bao bọc của bạn xung quanh nó.

Khi làm điều này, bạn giới hạn / hạn chế những lệnh bạn có thể cung cấp cho công cụ đồ họa của mình. Dưới đây là một số thứ thiết yếu:

1. Vẽ (đối tượng đồ họa) tại (vị trí)
2. Sửa đổi thuộc tính (alpha, xoay, v.v.) của (đối tượng đồ họa)
3. Di chuyển (đối tượng đồ họa) đến (vị trí)
4. Xây dựng bản đồ (tên cấp / cấu trúc dữ liệu)

Và một số người khác, mà bạn sẽ tìm thấy khi bạn làm việc trong dự án của bạn.

Nếu bạn đang sử dụng Ngôn ngữ hướng đối tượng được gõ nghiêm ngặt, bạn sẽ gọi các lệnh trên là giao diện mà trình bao bọc của bạn sẽ thực hiện. Tốt hơn là, đây sẽ là những phương pháp duy nhất không được bảo vệ / công khai.

Bây giờ, hãy tạo một trình bao bọc mới cho mỗi thư viện đồ họa của bạn và triển khai API . Khi một lệnh để vẽ __ tại __ được trao cho bạn, bạn phải sử dụng mã để tạo sprite hoặc mô hình và vẽ nó vào môi trường của bạn. Điều này có thể yêu cầu một số mánh khóe, chẳng hạn như lưu trữ mỗi sprite trong hàm băm để có thể truy cập lại vào một thời điểm khác bằng một biểu tượng nhất định.

Đối với việc xây dựng bản đồ, cách hiệu quả nhất sẽ là xây dựng trước từng bản đồ cho từng công cụ đồ họa và thực hiện tra cứu. Ngoài ra, bạn có thể lưu trữ bản đồ trong cấu trúc dữ liệu tùy chỉnh của riêng bạn và sau đó sử dụng trình bao bọc của bạn để xây dựng bản đồ từ cấu trúc dữ liệu đó.

Hy vọng điều này sẽ giúp bạn bắt đầu =]

Xây dựng kiến ​​trúc trò chơi của bạn với mô hình đủ gần với MVC để cho phép trừu tượng hóa hoàn toàn mã hiển thị có thể sẽ khá khó khăn đối với bất kỳ dự án lớn nào. Tuy nhiên, có vẻ như trở ngại lớn nhất để tạo ra một trò chơi hỗ trợ cả máy khách 2D và 3D sẽ là thiết kế một trò chơi trong đó cả hai máy khách đều có khả năng như nhau.

Cần phải bắt đầu thiết kế trò chơi của bạn với toàn bộ ý định tạo và hỗ trợ hai khách hàng, và có lẽ sẽ an toàn nhất khi hạn chế tất cả chức năng trò chơi theo ý nghĩa của máy khách 2D.

Như một cạm bẫy ví dụ, nếu bạn không thiết kế một bộ chức năng bị hạn chế, bạn có thể tạo các mức trong đó thông tin hoặc đối tượng quan trọng chỉ có thể nhìn thấy từ các góc cụ thể. Mặc dù điều đó sẽ tốt cho các máy khách 3D có quyền tự do xem 360 độ trừ khi máy khách 2D của bạn hỗ trợ rõ ràng góc nhìn có thể nhìn thấy trên từng đối tượng quan trọng đó, bạn sẽ làm suy yếu người dùng của máy khách.

Tốt nhất là đặt ra một số góc nhìn cụ thể cho máy khách 2D (8 hoặc 16 hoặc hơn) và phát triển tất cả nội dung để phù hợp với những hạn chế đó. Thật không may nếu bạn có các cấp độ và đối tượng được thiết kế để chỉ có thể xem được từ một bộ góc cụ thể, nó có thể trông khá kỳ lạ từ bên trong máy khách 3D.

Theo tôi, đó sẽ là một lựa chọn tồi khi thử thiết kế trò chơi cho phép các máy khách 2D và 3D được dự định có khả năng như nhau. Tôi nghĩ rằng nó sẽ là một cách sử dụng tài nguyên tốt hơn để thiết kế các tùy chọn chơi trò chơi không đối xứng và cho phép mỗi khách hàng chơi theo sở trường của mình. Ví dụ: nếu máy khách 2D chủ yếu tập trung vào viễn cảnh cấp chiến lược trong thế giới trò chơi, thì máy khách 3D được sử dụng để chơi trò chơi cấp chiến thuật.

Tôi nghĩ rằng bạn đã trả lời khá nhiều câu hỏi của riêng bạn:

Để đặt nó trong ngữ cảnh MVC: Bộ điều khiển hoàn toàn giống nhau (nhấn phím "Lên" sẽ đặt mức bồi thường cho người chơi ở mức 3,5 đơn vị / giây), Chế độ xem hoàn toàn khác nhau (2D so với 3D) và Mô hình giống nhau ngoại trừ bất cứ điều gì liên quan trực tiếp đến đồ họa.

Vì vậy, bằng cách cung cấp một sự trừu tượng đầy đủ giữa đầu vào, logic trò chơi, v.v. và đồ họa, bạn sẽ giải quyết được vấn đề.

Về cơ bản, đây là điểm của mô hình MVC, đặc biệt là liên quan đến các ứng dụng web và máy tính để bàn: có thể có nhiều máy khách truy cập và thao tác cùng một dữ liệu (ví dụ: giao diện web, máy khách di động và máy khách để bàn cho email).

Giữ cho nó đơn giản nếu bạn muốn nó đơn giản: - Viết logic trò chơi để di chuyển các đối tượng. Không lưu trữ bất kỳ dữ liệu nào trên chúng có liên quan đến kết xuất. - Viết các trình kết xuất được tạo cơ hội để xem trạng thái của dữ liệu trò chơi và vẽ nó.

Bạn có thể sử dụng các kỹ thuật lập trình phức tạp hơn hoặc ít hơn cho việc này. Điều duy nhất bạn cần là một cách để có được dữ liệu "thêm" mà bạn cần để kết xuất cho từng đối tượng trò chơi. Cách đơn giản nhất là không cần thêm dữ liệu! Nếu đối tượng trò chơi là "Wizard", hãy vẽ Wizard.

Nếu bạn cần các phương thức phức tạp hơn, hãy xem xét tính đa hình, mẫu memento, bảng băm, void * con trỏ, v.v. Đừng quá kỹ sư (hầu hết các phương pháp này đều được thiết kế quá mức).