Làm thế nào để thiết kế một công cụ trò chơi bằng ngôn ngữ hướng đối tượng? [đóng cửa]

Bất cứ khi nào tôi thử và viết một trò chơi bằng bất kỳ ngôn ngữ hướng đối tượng nào, vấn đề đầu tiên tôi luôn gặp phải (sau khi nghĩ về loại trò chơi nào để viết) là cách thiết kế động cơ. Ngay cả khi tôi đang sử dụng các thư viện hoặc khung công tác hiện có như SDL, tôi vẫn thấy mình phải đưa ra một số quyết định nhất định cho mọi trò chơi, như có nên sử dụng máy trạng thái để quản lý các menu, loại lớp nào để sử dụng để tải tài nguyên, v.v.

Một thiết kế tốt là gì và nó sẽ được thực hiện như thế nào? Một số sự đánh đổi phải được thực hiện và ưu / nhược điểm của họ là gì?

Tôi nghi ngờ ai đó sẽ có thể nói 'Bạn phải làm cái này và cái kia và cái này với cái khe đó bằng cách sử dụng mẫu X'.

Tuy nhiên, một số tài nguyên hữu ích:
Enginuity - một loạt các bài viết xây dựng động cơ trên Gamedev.net.
Hoàn thành mã hóa trò chơi - Tôi sở hữu cuốn sách này, và nó đi qua mọi khía cạnh (tốt, gần như) của lập trình trò chơi. Nó cũng có một động cơ được xây dựng trong suốt cuốn sách.
Game Engine Architecture - Đây là một cuốn sách tuyệt vời khác cho thiết kế động cơ.
Bố cục động cơ C4 - Lấy từ nhận xét của tôi, nhưng điều này cho thấy một cách thức cao cấp để lắp từng bộ phận của động cơ lại với nhau.

Đây có thể là một chút quá nhiều cho những gì bạn cần, nhưng bạn không thể biết quá nhiều về một cái gì đó, và tôi chắc chắn bạn sẽ có được một kế hoạch tốt từ họ.

EDIT: Tôi quên các bài viết Gamedev đã được lưu trữ kể từ khi trang web mới, được sửa :)

Ví dụ, đây là cách dự án roguelike hiện tại của tôi được cấu trúc (bằng Java). Nó đang sử dụng một công cụ đồ họa 2D nên rất nhiều mã kết xuất đã được tôi chăm sóc. Phê bình được hoan nghênh.

class Game
Lớp này thiết lập bộ máy trạng thái quản lý trạng thái hiện tại của trò chơi. (trong menu so với bắt đầu trò chơi mới so với chơi trò chơi đã lưu)

interface State
Mỗi lớp Trạng thái chứa hai vòng: vòng lặp để cập nhật logic và vòng lặp để kết xuất. Chúng cũng chứa mã để gọi Gamelớp và yêu cầu thay đổi sang trạng thái khác.

class ResourceManager
Một singleton được khởi tạo bởi Gamelớp tải tất cả các tài nguyên cần thiết và cho phép truy cập vào chúng. Tôi không thích thiết kế này vì nó làm cho việc tải / dỡ tài nguyên ở các cấp độ khác nhau chẳng hạn. Tôi có thể sẽ thiết kế nó khác đi nếu tôi bắt đầu lại.

class Map
Một bản đồ chứa một mảng gạch và một danh sách tất cả các sinh vật và vật phẩm trên bản đồ. Đó là một lớp học khá cơ bản.

class Creature
Các sinh vật chứa thông tin về bản thân bao gồm các tính toán chuyển động (yêu cầu chúng biết Bản đồ chúng đang ở và có thể truy vấn nó để tìm hiểu về các chướng ngại vật). Quyết định có nên làm điều này hay không, hoặc có một loại lớp quản lý nào đó chăm sóc nó cho tất cả các sinh vật là điều tôi đấu tranh.

interface AITask
Sinh vật có thể có một danh sách các AIT Nhiệm vụ, được thực thi mỗi khi vòng logic của sinh vật được chạy. AITask có vòng logic riêng phát ra các lệnh cho sinh vật và điều kiện kết thúc xác định xem nhiệm vụ đã hoàn thành thành công hay chưa.

interface UIElement
Tôi đã triển khai UI của riêng mình cho công cụ này. Mỗi UIE bổ sung có một vòng lặp kết xuất và một vòng logic. Họ cũng có một vòng lặp để xử lý đầu vào bàn phím / chuột. Tất cả các yếu tố có thể có một số yếu tố con, được hiển thị sau cha mẹ của chúng và tiếp quản đầu vào bàn phím / chuột. Điều này cho phép bạn có các menu với các menu con, ví dụ.

Điểm quan trọng đầu tiên cần thực hiện là không có câu trả lời 'tốt' cho câu hỏi này.

Điều gần nhất với một câu trả lời đúng sẽ là một cái gì đó như: Nó phụ thuộc rất nhiều vào loại trò chơi, nền tảng mục tiêu, các ràng buộc (thời gian), v.v.

Điều đó nói rằng có một số bài viết thực sự tốt trên mạng sẽ cho bạn thấy những người khác đã cố gắng trả lời vấn đề này như thế nào (vì tôi đã cố gắng tìm thông tin về vấn đề này trong quá khứ).
Như con vịt cộng sản đã đề cập đến bài viết hăng hái về nhà phát triển trò chơi đã giúp tôi hiểu một số phần của kiến ​​trúc trò chơi.

Thiết kế hiện tại của tôi là sự kết hợp của Quake3 / Doom3 và một chút của thư viện lớp .NET :)

Tôi có hai thư viện (tĩnh hoặc động tùy thuộc vào cách bạn muốn xây dựng / phân phối) Frameworkvà Library.

Thư viện chứa tất cả các lớp trợ giúp có mặt để hỗ trợ sản xuất phần mềm trò chơi nhưng không giới hạn ở loại sản phẩm này. tức là nó có triển khai danh sách liên kết được tối ưu hóa cho mã trò chơi nhưng có thể được sử dụng bởi bất kỳ thứ gì cần dịch vụ của danh sách được liên kết.

Khung là can đảm của 'công cụ' nếu bạn muốn gọi nó là. Rất nhiều điều này tuân theo các triết lý thiết kế của Quake3 (chỉ theo một cách hướng đối tượng hơn). Nó chứa CLI , quản lý thời gian, mã cụ thể của hệ điều hành và cuối cùng là các lớp kết nối mạng, v.v.

Hai cái này sau đó được liên kết với ứng dụng thực tế đang được sản xuất. Các Gamenếu bạn thích, trong đó có chứa mã trò chơi cụ thể. Theo cách tương tự, Quake3 tải DLL tùy thuộc vào 'mod' nào đang được phát.

Để cung cấp cho bạn một ý tưởng về cấu trúc ở đây là phân tích nhanh các thư mục và nội dung cho mỗi lib:

• Khung
  • IO (Các lớp quản lý tệp chuyên gia, các lớp In văn bản (ví dụ: CLI) và ghi nhật ký, v.v.)
  • Mạng
    • Máy khách (các lớp đại diện cho những gì Khung công tác coi là 'người chơi / kết nối với trò chơi')
    • Máy chủ (các lớp để quản lý kết nối vào khung và quản lý (các) trình phát)
  • Nền tảng (Các lớp xử lý bàn phím / chuột / bộ điều khiển, các thói quen cụ thể của hệ điều hành như getTime ())
  • Hệ thống (các lớp mức rất thấp như một lớp lỗi để hỗ trợ in các thông báo lỗi, các lớp thời gian và chính CLI.)
  • Trình kết xuất (tự giải thích)
  • v.v.

• Thư viện
  
  • Bộ sưu tập (các lớp đại diện cho bộ sưu tập dữ liệu, danh sách / hashtables được liên kết, v.v.)
  • Toán học (các lớp trợ giúp toán học cơ bản như vectơ và ma trận)
  • v.v.

HTH! Sẽ cung cấp cho bạn một số gợi ý ...

Những điều cần cân nhắc

• Các ngôn ngữ hướng đối tượng có vấn đề vì chúng thường không có các hàm hạng nhất hoặc không phải tất cả dữ liệu là đối tượng (như số nguyên hoặc dấu phẩy trong Java). Các mẫu thiết kế xử lý các vấn đề này với một số mẫu. Nói chung là mã nhanh hơn và dễ dàng hơn để sử dụng ngôn ngữ có thể thực hiện chúng (các đối tượng hạng nhất); ví dụ Python (cũng cho phép thiết kế hướng đối tượng), Bạn sẽ có tốc độ chậm hơn.
• Tính toán sự kiện, ít nhất là AI
• Hoare logic, sử dụng các điều kiện tiên quyết và hậu điều kiện để ít nhất kiểm tra mã của bạn
• Đại lý, nhìn vào thực thể Quake
• Cơ sở dữ liệu quan hệ, cách mạnh mẽ để lưu trữ dữ liệu

Thiết kế tốt

• lập sơ đồ ER
• làm cho nó đúng
• tạo cơ sở dữ liệu, đối tượng hoặc cấu trúc dữ liệu từ nó

Dữ liệu là chìa khóa để lập trình. Nếu bạn mong muốn dữ liệu của bạn tốt, thuật toán thường xuất hiện từ chúng (nếu bạn không đếm một số thuật toán số, như tính toán xác định).