Có bất kỳ động cơ / khuôn khổ tập trung tường thuật (hoặc ít nhất là không spatiotemporal)? [đóng cửa]

EDIT (2): Vì có hai câu trả lời và tôi chưa chấp nhận bất kỳ câu trả lời nào. Tôi cho rằng tôi thúc đẩy điều mà tôi xem là câu trả lời ở đây: Hoặc là một cái gì đó mạnh mẽ đề xuất bất kỳ cách tiếp cận nào như vậy đều không thể / không hữu ích hoặc , thay vào đó, một tài liệu tham khảo cho một nghiên cứu (lĩnh vực) hoặc ví dụ về một hệ thống ít nhất là chung chung như vậy ngoài các trò chơi phiêu lưu văn bản / tiểu thuyết tương tác.

Trong khi tôi sẽ không giả vờ rằng tôi đã thực hiện bất kỳ cuộc điều tra sâu hơn nào, tôi nhận thấy rằng tất cả các công cụ / khung trò chơi mà tôi đã xem xét dường như giống như một công cụ đồ họa được tôn vinh theo nghĩa là chúng nói về hình dạng / thực thể trong hai hoặc không gian euclide ba chiều với, có thể, một số dạng mô hình đồng thời "nhét vào" cho phép người ta chỉ định một số dạng logic gắn liền với các "thực thể" này.

Trò chơi "quy tắc" và tường thuật sau đó được viết theo cách hơi đặc biệt (liên quan đến động cơ) trên đầu trang của những người nguyên thủy này.

Rõ ràng mô tả ở trên khá đơn giản (sử dụng các công cụ chuyên dụng hơn như công cụ vô cực bao gồm một số dạng hệ thống nhiệm vụ / tường thuật), và tôi nhận ra rằng mô hình này có thể hoạt động khá tốt (rất nhiều người dường như đã sử dụng nó) .

Mặc dù vậy, tôi tự hỏi, những nỗ lực nào đã được thực hiện để tạo ra các công cụ / khung công tác lấy các khái niệm như mô tả (mức độ cao) về quy tắc trò chơi / logic hoặc tường thuật (hoặc ít nhất là khía cạnh phi không gian của trò chơi) làm chính nền tảng?

EDIT (4): Điều này không có nghĩa là trò chơi sẽ không bao gồm bất kỳ khía cạnh không gian / đồ họa nào, chỉ là thay vì có các thực thể không gian mà bạn liên kết logic, bạn có một khái niệm về cốt truyện (hoặc trò chơi hoặc "quy tắc trò chơi trên bảng" ) mà sau đó bạn mô tả một giao diện đồ họa để / hiện thực hóa.

Đặc biệt tôi sẽ quan tâm đến bất kỳ cách tiếp cận khai báo nào cố gắng nắm bắt một số loại ngữ nghĩa chính thức (bán) của một số loại trò chơi khá lớn, theo cách hữu ích để triển khai thực tế (ví dụ, trái với khung dành riêng cho phân tích định tính các trò chơi / tường thuật).

Những gì tôi đã thấy là một số nghiên cứu về mô hình hóa / phân tích tường thuật với một mô hình dựa trên mạng petri và một số cách tiếp cận thú vị trong langauges để viết tiểu thuyết tương tác .

EDIT (1): Tôi hình dung tôi sẽ thêm một ví dụ đồ chơi để minh họa.

Giả sử chúng tôi quan tâm đến việc tạo các cuộc phiêu lưu theo phong cách điểm và nhấp chuột (nghĩ các trò chơi SCUMM). Người ta có thể phân tích những điều này dựa trên một khái niệm về sự tiến triển tuyến tính và rời rạc từ tình huống bắt đầu đến kết thúc.

Tập trung vào khái niệm tiến trình rời rạc và cho phép một số phi tuyến tính, người ta có thể chọn lý thuyết về DAG (giới hạn) làm lý thuyết cơ bản. Do đó, chỉ định một trò chơi thuộc loại này, ở dạng trừu tượng nhất (liên quan đến lý thuyết này), tương ứng với việc thêm các tiên đề bổ sung cho lý thuyết này (để lý thuyết chỉ định một biểu đồ cụ thể hoặc đơn giản là đủ để nắm bắt bất cứ điều gì người ta nghĩ là cần thiết để nắm bắt "âm mưu").

Biến điều này thành một trò chơi thực tế bây giờ biến thành vấn đề thiết kế HCI / Giao diện khi nhúng lý thuyết này vào một thứ gì đó có thể chơi được (tức là xây dựng mô hình của lý thuyết / tìm một hình thái đồng nhất (iso?) Của đồ thị từ bộ sưu tập trạng thái giao diện người dùng với các chuyển đổi vào DAG "chỉ định trò chơi").

Trong kịch bản giả thuyết ở trên, tôi có thể thấy ít nhất ba điều có thể nắm bắt được trong các thư viện. Trước hết, người ta cần các công cụ để chuyển đổi / lý luận về DAG hoặc đồ thị nói chung. Thứ hai, một thư viện giao diện người dùng đủ thông minh để giúp xác minh rằng việc thể hiện biểu đồ của chúng tôi dưới dạng trò chơi có thể thực sự mô hình hóa biểu đồ (ví dụ: ít nhất là một phần / không chính thức, chứng minh trò chơi không có trạng thái bị kẹt, do điều kiện bị ràng buộc) . Cuối cùng, một bộ sưu tập các thư viện cấp cao hơn để chỉ định biểu đồ có thể được cung cấp; chẳng hạn như một thư viện để thể hiện các ký tự và sự tương tác của chúng và tạo ra (các phần của) biểu đồ theo cách đó.

Tại sao phải giữ lý thuyết DAG "trung bình", thay vì chỉ triển khai ở mức độ thấp với một số thư viện trợ giúp? Câu trả lời là tất cả các lý do thông thường cho một ngữ nghĩa chính thức. Vì chúng tôi đã quyết định dựa trên nền tảng chính thức, chúng tôi có thể xác minh một số thuộc tính của trò chơi cho phép người ta suy luận về những thứ như tối ưu hóa trong thư viện giao diện cấp thấp (miễn là nó mô hình DAG chúng tôi có thể làm những gì chúng tôi muốn), mà không cần phải lo lắng về sự không phù hợp với mô tả cấp cao (của các nhân vật / đoạn hội thoại, v.v.), vì những mô tả đó phải tự mô tả các cấu trúc như vậy.

Tôi không có nghĩa là cách tiếp cận cụ thể ở trên sẽ có hiệu quả, và ý tưởng không phải là một DAG phải là thứ thực sự được lưu giữ trong bộ nhớ (thay vào đó nó tạo thành một thứ gì đó giống với một hình thức tính toán như phép tính lambda), nhưng tôi hy vọng rằng điều này minh họa cho cách tiếp cận mà tôi tò mò.

Nói tóm lại, tôi đoán một tiêu đề thay thế cho câu hỏi này có thể là: Dijkstra đã viết trò chơi máy tính như thế nào?

Một lưu ý nhanh về các quy tắc kể chuyện và trò chơi: trong tiểu thuyết tương tác, có thể lập luận rằng trò chơi này là việc đi qua một biểu đồ kể chuyện phân nhánh, nhưng cuối cùng là câu chuyện kể bên ngoài cơ chế trò chơi - bạn có thể thay thế tất cả các từ bằng một thứ không thể đọc được và Tuy nhiên, các bước để hoàn thành trò chơi (hoặc mất khi chơi) sẽ hoàn toàn giống nhau. Đến lượt nó, ngụ ý câu chuyện không liên quan đến lối chơi, ngoại trừ trường hợp nhà phát triển chọn thay đổi cái này cho phù hợp với cái khác. Trong các trò chơi, câu chuyện kể về cơ bản là một mặt tiền trên cơ chế có thể làm cho cơ chế hấp dẫn hơn đối với một người chơi thích câu chuyện đó, nhưng đó là tất cả. Có một số trò chơi (mặc dù một số người không gọi chúng là trò chơi) trong đó tường thuật là hình thức giải trí chính và cơ chế trò chơi chủ yếu là chiếu lệ,Esther thân mến , nhưng các nhà phát triển không cần một phương pháp chính thức để kể chuyện nhiều hơn các tác giả tiểu thuyết làm, vì vậy tôi sẽ không xem xét tường thuật thêm nữa. Nói chung, bất kỳ trò chơi nào giống như "tường thuật có thể chơi được" là một cây hoặc biểu đồ của các sự kiện trò chơi có thể tồn tại và được thảo luận một cách có ý nghĩa mà không cần tường thuật.

Tôi đã nhận thấy rằng tất cả các công cụ / khung công tác trò chơi mà tôi đã xem xét dường như giống như một công cụ đồ họa được tôn vinh theo nghĩa là chúng nói về các hình dạng / thực thể trong không gian euclid hai hoặc ba chiều [...]

Đúng, hầu hết các "công cụ trò chơi" rõ ràng là "công cụ trò chơi video" và trách nhiệm chính của họ theo thời gian là tạo điều kiện thuận lợi cho phía kỹ thuật phần mềm của trò chơi video chứ không phải bên trò chơi. Có thể cho rằng điều này có ý nghĩa bởi vì đây là công nghệ phần mềm là khía cạnh mới nhất và đắt nhất và do đó có nhiều rủi ro nhất. Để so sánh, thiết kế trò chơi theo nghĩa trừu tượng đã được thực hiện bằng tay trong hàng ngàn năm mà không cần sự trợ giúp của các công cụ, điều này có thể giải thích ở một mức độ nào đó tại sao điều đó tiếp tục là trường hợp.

Những nỗ lực nào đã được thực hiện để tạo ra các công cụ / khung công tác lấy các khái niệm như (mức độ cao) mô tả các quy tắc / logic hoặc tường thuật của trò chơi (hoặc ít nhất là một khía cạnh phi không gian của trò chơi) làm cơ sở chính của chúng?

Có vài nỗ lực nghiêm túc, không thành công, theo như tôi biết.

Storytron là một. "Không giống như tiểu thuyết tương tác truyền thống, Storyworld quan tâm nhiều hơn đến việc mô hình hóa hành động và phản ứng của các diễn viên cũng như cảm xúc và khuynh hướng của họ hơn là địa lý thế giới trò chơi hoặc các vật thể trần tục cư trú ở đó." Nó tuân theo một nỗ lực trước đó được gọi là Erasmatron, không thực sự thành công và Storytron cũng không thực sự giống như thành công. Bài viết sau đây là một bài đọc tốt về điều này: Đuổi rồng

Ở mức độ ít tham vọng hơn, có rất nhiều người đã nghĩ ra những cách đơn giản để đại diện cho những trò chơi đơn giản. Một trong số đó là: Multigame - Ngôn ngữ cấp độ cao để mô tả các trò chơi trên bảng (liên kết nằm sau thông tin đăng nhập, nhưng bạn có thể tìm kiếm nó) nhưng tất cả những gì bạn có ở cuối là một bộ máy tính có thể đọc được trạng thái, chuyển trạng thái và điều kiện chiến thắng hoặc chức năng giữ điểm - tốt cho các trò chơi cờ rời rạc như Cờ vua hoặc các trò chơi bài như Poker, nhưng chúng không khái quát cho các trò chơi có số lượng lớn trạng thái liên tục hoặc các trò chơi có ngữ nghĩa nhiều hơn như mô phỏng (ví dụ: game bắn súng) hoặc thể thao (ví dụ: game đua xe). Những trò chơi như vậy không thể được thể hiện đầy đủ thông qua một cây trạng thái trò chơi đơn giản.

Một cách để tiếp cận sự hiểu biết về các hệ thống phức tạp hơn này là thử và phân loại từng cơ chế hiện có thành một trong một số hình thức cơ bản, và sau đó tìm ra cách các hình thức cơ bản có thể được kết hợp để tạo thành trò chơi phức tạp hơn, theo giả định rằng tất cả các trò chơi có thể bao gồm các đơn vị cơ bản, hoặc kết hợp chúng. Dan Cook có một bài báo tên là " Cơ chế trò chơi là gì?" và phần tiếp theo " Hóa học của thiết kế trò chơi"cố gắng ghi lại cách tiếp cận thành phần này vào thiết kế trò chơi. Về lý thuyết có thể xây dựng một hệ thống khai báo trên đó, nhưng trong thực tế, cơ học chỉ tạo thành một phần nhỏ của trò chơi và do đó, kết quả đầu ra có lẽ sẽ bị hạn chế trong khuôn khổ thuyết trình sẽ không đủ linh hoạt để thu hút sự chú ý của hầu hết các game thủ.

Những nỗ lực khác trong việc chính thức hóa các khái niệm thiết kế trò chơi thường được gọi là "ngữ pháp trò chơi" - một bài viết như vậy được gọi là " Nguyên tử trò chơi nhiều người chơi " nhưng đề cập đến nhiều tác phẩm trước đó.

Giả sử chúng tôi quan tâm đến việc tạo các cuộc phiêu lưu theo phong cách điểm và nhấp chuột (nghĩ các trò chơi SCUMM). [...] người ta có thể chọn lý thuyết về DAG (giới hạn) làm lý thuyết cơ bản. [...] Trước tiên, người ta cần các công cụ để chuyển đổi / suy luận về DAG hoặc đồ thị nói chung. Thứ hai, một thư viện giao diện người dùng đủ thông minh để giúp xác minh rằng việc thể hiện biểu đồ của chúng tôi dưới dạng trò chơi có thể thực sự mô hình hóa biểu đồ (ví dụ: ít nhất là một phần / không chính thức, chứng minh trò chơi không có trạng thái bị kẹt, do điều kiện bị ràng buộc) . Cuối cùng, một bộ sưu tập các thư viện cấp cao hơn để chỉ định biểu đồ có thể được cung cấp; chẳng hạn như một thư viện để thể hiện các ký tự và sự tương tác của chúng và tạo ra (các phần của) biểu đồ theo cách đó.

Vấn đề ở đây là máy tính không thêm nhiều vào quy trình. Những người thiết kế các trò chơi như thế này thường sẽ vẽ chính xác điều này, một biểu đồ ở dạng kỹ thuật số hoặc vật lý, cho thấy dòng chảy trong trò chơi. Thật tầm thường để xem liệu trò chơi có thể hoàn thành về mặt lý thuyết hay không. Ngay cả việc mã hóa các quy tắc khác nhau để tiến bộ thông qua một cuộc phiêu lưu điểm và nhấp chuột là chuyện nhỏ. Phần khó là làm cho nó theo một câu chuyện thú vị, đặt nó trong một thế giới hấp dẫn, tạo ra các tài sản nghệ thuật và âm thanh để mô tả đúng trò chơi và giao diện, và các nhiệm vụ kỹ thuật phần mềm khác nhau kết hợp tất cả lại với nhau. Biểu đồ định hướng của các trạng thái quan trọng thông qua trò chơi thường tương đối tầm thường; đó là tất cả những thứ xung quanh nó là vấn đề. Và đây là lý do tại sao không có nhiều quan tâm đến nó,

Cá nhân tôi hiện đang làm việc với một nhóm về một sản phẩm có tên Storybrickscố gắng cho phép xây dựng lối chơi thú vị thông qua việc chỉ định các quy tắc khác nhau và các quy tắc này có thể nêu trạng thái ban đầu của một người, nhu cầu của họ, v.v. Thật dễ dàng để thực hiện các quy tắc này và xác minh xem liệu nhu cầu của một người có thể được đáp ứng hay không, và nếu vậy thì bằng cách nào, và do đó, để tạo ra các nhiệm vụ cần hoàn thành trong trò chơi. Tuy nhiên, chính điều này vốn không tạo ra lối chơi thú vị, bởi vì một khi bạn trừu tượng hóa đến mức "X cần Y - lấy nó cho họ", người chơi bắt đầu phát hiện ra mô hình và ngừng thưởng thức nó. (Ví dụ: mọi người mệt mỏi nhanh chóng với các nhiệm vụ được tạo tự động trong Skyrim, bởi vì họ có thể thấy rằng không có ý nghĩa vốn có đối với một nhiệm vụ được tạo theo thủ tục, so với các nhiệm vụ được thiết kế thủ công. ) Vì vậy, công việc của chúng tôi sẽ là sử dụng các phương pháp AI để làm cho những tình huống này trở nên thú vị hơn, và đó là điều chúng tôi vẫn đang làm việc. (Storybricks vẫn còn trong giai đoạn alpha rất sớm). Nhưng nghiên cứu của chúng tôi chỉ ra rằng rất ít người đang cố gắng làm bất cứ điều gì như thế này và đó là một vấn đề rất khó khăn.

Một vấn đề khác với cách tiếp cận khai báo là nó không sử dụng được. Các nhà khoa học thích nó bởi vì nó dễ xử lý, ví dụ để chứng minh rằng một tình huống có thể giải quyết được hoặc một tập hợp các quy tắc logic là nhất quán. Nhưng trong thế giới thực, cả người lập trình trò chơi máy tính và người dùng cuối đều không thoải mái với một đại diện khai báo tập trung vào kết quả như họ với một đại diện bắt buộc cho họ biết cách hành động để kết quả xảy ra. 10 ngôn ngữ lập trình hàng đầu hiện nay đều là bắt buộc và các hướng dẫn trong thế giới thực cũng thường ở dạng bắt buộc, cho dù đó là cách nướng bánh hay cách xây dựng đồ nội thất. Sự thiếu nhiệt tình từ một trong hai đầu của quang phổ có nghĩa là không có động cơ thương mại để sản xuất các thông số kỹ thuật chính thức cho các trò chơi hiện đại và điều này dường như không thể thay đổi trong tương lai gần.

Tôi đã xem xét làm thế nào để trả lời một lúc, và tôi không chắc chắn làm thế nào để đặt điều này.

Đó là một câu hỏi hay. Thật không may, loại câu trả lời sôi nổi đến mức không có ý nghĩa gì khi lập trình bất cứ thứ gì chứ đừng nói đến một công cụ trò chơi theo cách này, hoặc đây đã là cách mọi thứ diễn ra.

Dường như có sự nhấn mạnh này vào đồ họa, bởi vì cần phải có một cách để xác định sự tồn tại vật lý của các đối tượng. Đây là loại nơi mọi thứ bắt đầu trở nên tồn tại bởi vì những gì chúng ta thực sự đang nói đến là một đại diện cho kích thước, nhưng bây giờ chúng ta hãy bỏ qua điều này. Điểm chính là, đây là một cái gì đó thực sự có liên quan. Cho phép đại diện cho không gian sẽ là một cái gì đó vốn đã chiếm rất nhiều lập trình của một công cụ trò chơi. Và nếu các nhà thiết kế muốn tạo ra những cảnh đẹp, họ sẽ cần nhiều quyền kiểm soát đối với cách mọi thứ được đặt. Vì vậy, bạn sẽ thấy rất nhiều thứ về đồ họa.

Vì vậy, đó là mặt thấp của mọi thứ. Ai đó cần phải suy nghĩ sâu sắc về tất cả các vấn đề kỹ thuật nhỏ này.

Theo như tường thuật và quy tắc trò chơi đi? Đó là ngoài phạm vi của những gì một công cụ trò chơi phải làm. Đây là phần mà nhóm phát triển đi vào.

Hơn nữa, nó không giống như nhiều suy nghĩ đã không được đưa vào để thể hiện ý tưởng thông qua lập trình. Đó là thực sự những gì lịch sử của khoa học máy tính là . Và, đây là lý do tại sao các công cụ trò chơi thường xuyên có giao diện với các ngôn ngữ cấp cao. Dễ dàng hơn để thể hiện suy nghĩ thông qua chúng.

Vì vậy, với ý nghĩ đó, một ngôn ngữ có thể được tạo ra đặc biệt cho các trò chơi với trọng tâm tường thuật không? Tôi có thể nói có lẽ là không. Một lần nữa tất cả điều này đi xuống đại diện. Ngôn ngữ cần có khả năng mô tả chi tiết theo cách mà máy tính biết phải làm gì với nó. Nếu mục đích là tạo ra một ngôn ngữ dành riêng cho việc tạo trò chơi, thì mọi quyết định thiết kế nên tập trung vào đó.

Và một lần nữa, có rất nhiều sự lựa chọn về ngôn ngữ. Và nhiều người hơn chỉ những người trong ngành công nghiệp trò chơi đã phát triển chúng. Nó thường có ý nghĩa để sử dụng một trong những.

Tóm lại bạn đã hỏi một câu hỏi thú vị, nhưng rất khó. Và tôi không hoàn toàn chắc chắn nó là gì, hoặc nếu tôi thực sự trả lời nó.

* chỉnh sửa: Nhìn lại, tôi nhận ra rằng tôi chỉ đang xem xét Công cụ trò chơi 3D, như thể chúng là những người duy nhất tồn tại. Một số trò chơi không có một người nào hành động trong một không gian vật lý cả. Mặc dù trong những trường hợp như vậy tôi không chắc chắn rằng một công cụ trò chơi sẽ đóng góp nhiều.

Đầu tiên trong lịch sử điện toán sở thích (ví dụ như thập niên 80), có một số bộ công cụ phát triển Trò chơi thương mại có sẵn cho cả trò chơi dựa trên văn bản và sprite. Những cái dựa trên sprite rất giống với "công cụ đồ họa" hiện tại.

Các loại khác bao gồm những thứ như trình phân tích ngôn ngữ tự nhiên. Loại này dường như sống trong "trình chỉnh sửa cấp" hiện đại. Hầu hết những thứ đó dường như bao gồm hỗ trợ cho một cái gì đó như kịch bản Lua hoặc Python. Tôi cũng sẽ lưu ý rằng tôi không thấy nhiều hoạt động trong chỉnh sửa mức nguồn mở, nhưng đó là bởi vì những điều này thường được kết hợp rất chặt chẽ với các chi tiết cụ thể của trò chơi được đề cập. Tôi đang suy nghĩ ở đây về một cái gì đó giống như các bộ xây dựng Elder Scrolls.

Kinect có thể mang trình phân tích cú pháp trở lại. Là một fan hâm mộ của trò chơi phiêu lưu dựa trên văn bản cũ, tôi cũng rất hào hứng về hướng đi của Bethesda ở đây. Nó chắc chắn là độc quyền, nhưng có lẽ một số thiên tài trẻ ...