Làm thế nào để tích hợp trình chỉnh sửa trò chơi với công cụ?


7

Những gì tôi đang cố gắng tìm ra là cách tốt nhất để tích hợp trình soạn thảo (mức độ, hiệu ứng, mô hình, v.v ...) theo cách hiệu quả nhất là gì?

Bây giờ điều đầu tiên tôi nghĩ sẽ là tạo ra công cụ trò chơi (*) cực kỳ mô-đun. Ví dụ tôi lấy ví dụ về trạng thái trò chơi. Bạn có thể có nhiều trạng thái trò chơi mà tất cả đều có phương thức update () và draw () của riêng mình trong số các trạng thái khác. Mỗi lớp trạng thái trò chơi sẽ kế thừa từ một lớp GameState cơ sở. Điều này cho phép một cách tiếp cận mô-đun hơn và một cách hữu ích ở đó.

Bây giờ cách tiếp cận hiệu quả nhất là triển khai trình chỉnh sửa cùng với công cụ mô-đun, hoặc tạo hai thiết kế khác nhau cho cả trò chơi và trình chỉnh sửa? Tôi nghĩ lấy ví dụ về trạng thái trò chơi và mở rộng nó sang trạng thái cửa sổ, và cũng có thể được sử dụng cho nhiều hệ thống hơn. Có thực hiện tốt hơn thiết kế này (trạng thái trò chơi) để sử dụng trong các hệ thống khác được sử dụng trong động cơ không?

*: Bây giờ tôi biết thuật ngữ công cụ trò chơi là không liên quan và sử dụng sai trong nhiều tình huống. Cái mà tôi gọi là "công cụ trò chơi" là sự kết hợp của các hệ thống mà trò chơi phải tương tác với nhau.

Ngoài ra đây là một câu hỏi lý thuyết / thiết kế hơn là một thực hiện. Mặc dù cả hai kết hợp, tôi muốn có một ý tưởng tổng quát hơn về cách trình soạn thảo được xây dựng một cách hiệu quả và vẫn sử dụng cùng một mã công cụ như những gì trò chơi sử dụng.

PS Nếu bạn cần làm rõ hơn hoặc thêm bit, chỉ cần để lại nhận xét.

Câu trả lời:


5

Tôi nghĩ rằng câu hỏi của bạn liên quan nhiều hơn đến thiết kế, nhưng thông thường bạn không muốn thiết kế một cái gì đó không thể thực hiện được, vì vậy việc triển khai xuất hiện mọi lúc mọi nơi.

Đối với trình chỉnh sửa, tôi nghĩ nó phụ thuộc vào những gì thư viện công cụ trò chơi thời gian chạy có thể hỗ trợ. Nó có hỗ trợ một số loại kiến ​​trúc ứng dụng chung (ví dụ: hệ thống sự kiện, xử lý ngoại lệ, GUI, v.v.) hay nó tập trung hơn vào việc chạy một loại trò chơi cụ thể mà nó được tạo ra? Nếu nó hỗ trợ một kiến ​​trúc như vậy, tôi nghĩ người ta sẽ thực hiện trình chỉnh sửa tương tự như một trò chơi. Nếu không, trình soạn thảo có thể là một chương trình độc lập sử dụng một số khung được thiết lập.

Bạn có thể muốn kiểm tra Game Engine Architecture, của Jason Gregory. Trong cuốn sách này, tác giả chỉ ra rằng UnrealEd là một ví dụ về trình soạn thảo được xây dựng bằng công cụ mà nó hỗ trợ và thiết kế như vậy có những ưu và nhược điểm. (pro: mọi thứ đều là bản địa, vì vậy thật dễ dàng để nhấn 'play' và nhảy ngay vào trò chơi từ trình chỉnh sửa. Con: nếu công cụ của bạn không ổn định / đang phát triển, việc sử dụng trình chỉnh sửa có thể bị ảnh hưởng.)

Dưới đây là hình ảnh kiến ​​trúc của một động cơ từ cùng một cuốn sách, ví dụ. Để tích hợp trình chỉnh sửa, có lẽ bạn sẽ muốn thêm GUI chung vào Frontend. Bạn cũng có thể muốn một hệ thống Sự kiện ứng dụng (có thể tắt / bật) nằm ở đâu đó giữa HID và Frontend. Bạn có thể có được một số lượng lớn chức năng từ đó, nhưng có thể có một bong bóng Trình biên tập / Ứng dụng chung - Bong bóng Hệ thống con cụ thể bên cạnh trò chơi và các bong bóng có sẵn khác có thể được mở rộng, nếu cần.

http://www.bennychen.cn/wp-content/uploads/2011/03/R.78GameEngineArch architecture.png


Cảm ơn bạn cho một cái nhìn sâu sắc tốt. Tôi chắc chắn sẽ chọn cuốn sách đó vì nó đã được đề xuất nhiều lần.
Daniel

1
Game Engine Architecture là một cuốn sách tuyệt vời, nhưng bản thân nó quá mỏng. Nó nói về các hệ thống con, nhưng không bao giờ chi tiết. Tuy nhiên, tôi muốn giới thiệu nó cho bất cứ ai muốn xây dựng động cơ của riêng họ.
hiệp sĩ666

Cảm ơn. Hiểu về cách xây dựng một công cụ, và đại khái là quá trình thực hiện sẽ là nhiệm vụ đầu tiên của tôi vì tôi muốn có thêm một số trò chơi trong vành đai của mình để thực sự hiểu về những gì tôi cần và không cần.
Daniel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.