Máy trạng thái hữu hạn trong C ++


16

Vì vậy, tôi đã đọc rất nhiều về việc sử dụng các FSM để thực hiện quản lý trạng thái trò chơi, những thứ như FSM là gì và sử dụng một ngăn xếp hoặc tập hợp các trạng thái để xây dựng một trạng thái. Tôi đã trải qua tất cả điều đó. Nhưng tôi bị mắc kẹt trong việc viết một triển khai FSM thực tế, được thiết kế tốt cho mục đích đó. Cụ thể, làm thế nào để giải quyết một cách sạch sẽ vấn đề chuyển đổi giữa các trạng thái, (trạng thái) như thế nào để một trạng thái có thể sử dụng dữ liệu từ các trạng thái khác, v.v. Có ai có bất cứ lời khuyên nào về thiết kế và viết một triển khai trong C ++ hay tốt hơn là các ví dụ về mã không?


các thẻ được chỉnh sửa dựa trên cuộc thảo luận này trong meta: meta.gamedev.stackexchange.com/questions/103/ mẹo
lathomas64

Câu trả lời:


12

Tôi đã viết một FSM dựa trên một chương trong "Phát triển trò chơi nhiều người chơi" do Thor Alexander biên soạn. Bên trong là một chương có nhãn "Máy song song cho các nhân vật đáng tin cậy". Điều này được viết bằng python, nhưng các khái niệm có thể dễ dàng dịch sang C ++. Tôi đặc biệt khuyên bạn nên kiểm tra điều này, mặc dù đây là về trạng thái nhân vật, không phải trạng thái trò chơi.

Những gì tôi đã tạo là ở đây: https://github.com/swganh/mmoserver/tree/master/src/ZoneServer/GameSystemManager/State%20Manager xem trong StateManager để biết chi tiết triển khai, nhưng về cơ bản bạn có các 'trạng thái cơ bản' khác nhau mà bạn có thể sử dụng. Sau đó, từ đó bạn có các trạng thái cụ thể mà bạn chuyển sang làm nhân vật, vì vậy mỗi trạng thái là một lớp. Sau đó, bạn kiểm tra xem có thể chuyển từ trạng thái này sang trạng thái khác không và sau đó 'nhập' bạn thực hiện chuyển đổi, bạn cũng có thể dễ dàng thực hiện những việc như đưa vào các sự kiện sau khi chuyển sang trạng thái. Tôi thấy điều này làm việc thực sự tốt cho trò chơi cho đến nay.

Những gì tôi đã thực hiện là những gì cuốn sách gọi là một máy trạng thái song song, rất cần thiết cho nhiều fsm hoạt động cùng nhau, trong trường hợp này bạn có thể chuyển sang một trạng thái, chặn tất cả các trạng thái khác (ví dụ: CreatureState_Dead). Tôi sẽ không đi sâu vào chi tiết vì tôi không nghĩ nó sẽ thực sự giúp bạn, nhưng nếu bạn muốn tôi có thể giải thích.


1
Có vẻ như mã được chuyển đến: github.com/swganh/mmoserver/tree/master/src/ZoneServer/ chủ
DK_

8

Trò chơi lập trình AI theo ví dụ (http://www.ai-junkie.com/books/toc_pgaibe.html) có một ví dụ triển khai khá đơn giản và chỉ xử lý các vấn đề cơ bản. Các chuyển đổi được xử lý trong một cuộc gọi phương thức duy nhất (đầu tiên là Enter (), sau đó Thực thi () mỗi lần cập nhật, Thoát () khi chuyển đổi)> Tôi không biết bạn cần gì ngoài điều đó. Tôi sẽ thực hiện các chuyển đổi phức tạp hơn khi các trạng thái của riêng chúng chỉ được thiết kế để thực thi một lần và chuyển sang trạng thái tiếp theo theo trình tự.

Tôi sẽ cố gắng và cho rằng bạn đang xem các FSM cho AI, nếu vậy tôi khuyên bạn nên xem qua các cây hành vi. AIGameDev có một số bài viết tuyệt vời về nó.


1
Ví dụ đó cũng có sẵn trên trang web của anh ấy: ai-junkie.com/arch architecture / state_driven / trut_state1.html
Zolomon

5

Nếu ma thuật mẫu C ++ và thời gian biên dịch dài tiềm năng không phải là vấn đề đối với bạn và bạn đã cài đặt Boost để hoạt động với :

Boost bây giờ có một thư viện máy trạng thái meta hiệu quả ( về tốc độ và kích thước ) có lợi thế là cho phép bạn đặt bảng chuyển đổi tách biệt với các cấu trúc trạng thái : bạn có một bảng mô tả khi nào chuyển từ trạng thái wich sang trạng thái khác . Bạn chỉ cần đọc nó để hiểu những gì đang diễn ra trong máy trạng thái.

Ưu điểm khác là nó đã được một số doanh nghiệp thử nghiệm ngay cả trong các phần mềm nhúng với phần mềm hiệu năng cao (xem danh sách gửi thư nâng cao để biết chi tiết). Vì việc triển khai đã có sẵn, nó có thể là một lựa chọn tốt nếu bạn cần một triển khai máy trạng thái chung mà Just Works (tm).

Nó cũng hỗ trợ các trạng thái trực giao (trạng thái song song) và các tính năng hữu ích dựa trên UML khác.

Nó cũng cung cấp một số cách để thể hiện bảng chuyển đổi, một trong số đó là thử nghiệm nhưng thú vị ở khía cạnh biểu cảm (mặc dù bị giới hạn bởi hiệu suất trình biên dịch hiện tại - quá tệ!)

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.