Nhiệm vụ của trò chơi (ví dụ: Oblivion) ​​được mô phỏng như thế nào?

Question

Tôi vừa mới bắt đầu chơi Elder Scrolls IV: Oblivion cách đây vài ngày và một điều tôi không thể không tự hỏi là làm thế nào hệ thống nhiệm vụ được xử lý theo chương trình?

Cụ thể, có hàng chục (hàng trăm) nhiệm vụ và thậm chí là nhiệm vụ phụ trong trò chơi, tất cả đều được phản ánh trong môi trường của trò chơi theo nhiều cách: từ các sự kiện kịch bản xảy ra trong trò chơi vào những thời điểm cụ thể/nơi giữa những người cụ thể (giả sử họ vẫn còn sống), với các mục nhiệm vụ liên quan (một số liên quan đến NPC và trạng thái nhiệm vụ cụ thể), để thay đổi hộp thoại với các NPC khác nhau (một lần nữa, với một cây phức tạp có thể thay đổi bằng hộp thoại với các NPC khác & trạng thái chung của nhiệm vụ). Ngoài ra, bạn có thể hoán đổi giữa các nhiệm vụ đang hoạt động/không hoạt động tại bất kỳ thời điểm nào, vì vậy những hành vi phức tạp này ảnh hưởng triệt để môi trường xung quanh bạn được thực hiện thêm một bước bằng cách hoán đổi hoàn toàn.

Nó có vẻ như một cơn ác mộng hợp lý, và tôi đang gặp khó khăn trong việc nắm bắt một cái gì đó sâu sắc và phong phú có thể được định nghĩa theo chương trình, vì vậy dường như hoàn hảo.

Có ai có kinh nghiệm trong loại điều này có thể giải thích (rộng rãi) những gì đi vào các loại hệ thống?

Answer 1

Tôi chỉ đoán ở đây. Đã không thực hiện loại lập trình này nhưng tôi đã suy nghĩ rất nhiều về cách họ đã làm nó trong khi chơi RuneScape.

Có thể có một loạt cờ và biến được liên kết với tài khoản của bạn và khi bạn tiến hành thông qua nhiệm vụ, giá trị của chúng thay đổi. Lúc đầu, ký tự X được đánh dấu là còn sống và ở vị trí Y. Sau đó, ký tự được đánh dấu là Vị trí Z. Sau đó, cô ấy đã chết. Vì vậy, khi bạn nhập Vị trí Y, nó sẽ kiểm tra biến để xem liệu cô ấy có ở đó không và đặt đối tượng của cô ấy ở đó hay không. Trong khi đó, một người chơi khác đã không bắt đầu nhiệm vụ có thể ở trong cùng một khu vực và nhìn thấy một cái gì đó hoàn toàn khác.

Answer 2

Tôi không phải nhà thiết kế trò chơi nhưng tôi có thể nhìn thấy một cái gì đó mà bạn có thể tại nơi làm việc ở đây ...

Object Oriented Programming phép cho các loại hình phức tạp và sự năng động bằng cách đóng gói dữ liệu và logic gọn gàng trong nhiều đối tượng. Các đối tượng này có thể tương tác 'bằng lời', sử dụng thông điệp liên đối tượng để phân công nhiệm vụ cho nhau. Người gửi thư không cần biết người nhận sẽ diễn giải thông báo như thế nào, để lại phương thức hành động hoàn toàn cho người nhận. Cũng giống như trong thế giới thực, phái đoàn cho phép mọi thứ chạy trơn tru hơn.

Ví dụ: khi bạn đặt hàng risotto nấm từ Del Posto ở thành phố New York, bạn có đặt hàng bằng cách quay lại bếp và trò chuyện trực tiếp với đầu bếp không? Bạn có đặt trên một chiếc tạp dề và chuẩn bị risotto cho mình? Bạn lái xe đến trang trại nấm gần nhất và chọn nấm của riêng bạn? Không, bạn không. Bạn chỉ cần ủy nhiệm các nhiệm vụ này cho người phục vụ, đội ngũ đầu bếp và nhà cung cấp sản phẩm tương ứng. Để có được risotto nấm của bạn, tất cả các bạn cần làm là nói với người phục vụ mà bạn muốn nó. Phần còn lại được thực hiện tự động, thông qua một chuỗi các đoàn đại biểu. Cùng một loại đoàn có thể tồn tại trong trò chơi của bạn.

Bây giờ, quay lại đối tượng. Một số đối tượng kế thừa dữ liệu và logic từ các đối tượng cha, và theo cách này, có thể có rất nhiều dữ liệu/logic chung; chúng ta hãy gọi những anh chị em này. Trong ví dụ về nhiệm vụ trò chơi, mỗi nhiệm vụ có thể là 'đối tượng nhiệm vụ' của riêng mình, với dữ liệu cơ sở và logic được thừa kế từ cha mẹ nhiệm vụ của cha mẹ. Quest anh chị em có thể được phân biệt với nhau bằng cách tacking-on thêm dữ liệu/logic liên quan đến các nhiệm vụ cụ thể.

Tùy thuộc vào hành động của bạn trong trò chơi (và lựa chọn của bạn trong menu của trò chơi, có lẽ), đối tượng trò chơi có thể hoán đổi một đối tượng nhiệm vụ đang hoạt động cho một trong các anh chị em của nó. Thông thường, điều này có thể được thực hiện với một lệnh thực sự đơn giản (trong pseudo-code, không theo mô hình sau khi bất kỳ ngôn ngữ lập trình cụ thể):

gameObject.activeQuest -> getCurrentObject(); 
//returns the object containing all of the data/logic of the current active quest: 
Gibbons_GoldenArtifacts 
//Let's say the quest description is "Scour the Catacombs of Gibbon for a 
mysterious treasure" 

gameObject.activeQuest -> setCurrentObject(Gibbon_DefeatGhost) 
//sets the activeQuest object (note that QUEST OBJECT contains baseline data/logic) 
//assuming, say, Gibbon_DefeatGhost is an object like so: 

Gibbon_DefeatGhost={QUEST OBJECT}; 
Gibbon_DefeatGhost.extend(
    description="Defeat Gibbon's ghost to retrieve his golden artifacts"; 
    objective="Defeat Gibbon's ghost"; 
    questNPC="Gibbon's ghost"; 
    questLocation="Gibbon's Inner Sanctum" 
    questTriggers[1]="When PLAYER enters Gibbon's Inner Sanction: Release Gibbon's ghost"; 
    questTriggers[2]="When Gibbon is slain: Drop Gibbon's golden artifacts" 
) 

Từ thời điểm đó trở đi, các đối tượng trò chơi riêng của mình có thể sẽ tương tác với các nhiệm vụ hoạt động đối tượng giống như nó luôn có, nhưng đối tượng nhiệm vụ đang hoạt động có thể cảm nhận những tương tác đó theo những cách khác với cách tìm kiếm đối tượng nhiệm vụ, dẫn đến trải nghiệm trò chơi khác.

Hope Tôi không hoàn toàn fudging chú hề trên này ...

Answer 3

A finite-state machine (FSM) or finite-state automaton (plural: automata), or simply a state machine, is a behavioral model used to design computer programs. It is composed of a finite number of states associated to transitions. A transition is a set of actions that starts from one state and ends in another (or the same) state. A transition is started by a trigger, and a trigger can be an event or a condition.