Có đáng để thực hiện các cơ chế / quy tắc trò chơi tách biệt với mã chính không?

Không chắc chắn liệu nó có phù hợp với phạm vi của cộng đồng này hay không, hoặc nên truy cập Stackoverflow.

Giả sử rằng tôi muốn trò chơi của mình có thể dễ dàng mở rộng trong cốt lõi của nó, tức là tôi muốn rằng nhiều người, ngay cả khi không có kiến ​​thức lập trình đàng hoàng, sẽ không chỉ có thể điều chỉnh các quy tắc hiện có, mà thậm chí còn thêm cơ chế trò chơi hoàn toàn mới vào nó. Bản thân tôi không phải là lập trình viên giỏi, nhưng tôi đã sẵn sàng để học, tôi chỉ cần một số hướng và đảm bảo nó có thể được thực hiện.

Những gì tôi đã nghĩ là liệu có thể / khả thi để bằng cách nào đó thực hiện cơ chế trò chơi tách biệt với mã tiện ích chính không? Ý tôi là, đối với các trò chơi trên máy tính bảng, chúng tôi có những quy tắc không chứa thuật toán thực tế của tất cả các hành động, mà chỉ mô tả một số giao thức và giới hạn, tham chiếu bối cảnh của từng mục như vậy. Có thể làm một cái gì đó tương tự cho trò chơi trên PC, như, mô tả tất cả các quy tắc ở một mức độ rất cao, dễ đọc (và có thể thay đổi) bằng ngôn ngữ lập trình của con người, sau đó được "tiêu thụ" và phân tích bằng mã tiện ích thành một ví dụ làm việc của cơ học trò chơi?

Điều đó thực sự có vẻ như tôi cần phải viết ngôn ngữ của riêng mình và một trình biên dịch cho nó)) Tất nhiên tôi sẽ không thể làm được. Nhưng có thể có một cách tiếp cận dễ dàng hơn cho vấn đề?

FYI: ngôn ngữ tôi chọn cho mã tiện ích sẽ là Python 3.x

Nói chung, sự dễ dàng mà bất kỳ hệ thống nào có thể được mở rộng phụ thuộc vào mức độ mà các hệ thống con của nó được liên kết chặt chẽ hoặc lỏng lẻo . Thông thường, các hệ thống con càng được ghép lỏng lẻo thì càng dễ sửa đổi chúng khi chúng bị cô lập & không nhất thiết đòi hỏi phải có sự hiểu biết toàn diện về toàn bộ hệ thống.

Mặc dù không có gì là miễn phí - hệ thống như vậy thường đòi hỏi nhiều tài nguyên hơn (nhiều cách kết hợp thời gian, tiền bạc và kỹ năng) để xây dựng. Mức độ mở rộng mà bạn mô tả gây ấn tượng với tôi là trực tiếp mâu thuẫn với mức độ kỹ năng mà bạn gán cho chính mình. Nó có thể được thực hiện, nhưng chế tạo phần mềm như bạn đã mô tả nó là một công việc rất khó khăn.

Những thứ hiện có gần nhất mà tôi biết là Vassal (có tính lập trình cao hơn nhiều so với mô tả của bạn) hoặc tạo một bản mod cho Tabletop Simulator (chủ yếu phụ thuộc vào sự tương tác của con người để diễn giải và thực thi bất kỳ quy tắc trò chơi nào).

Những gì tôi đã nghĩ là liệu có thể / khả thi để bằng cách nào đó thực hiện cơ chế trò chơi tách biệt với mã tiện ích chính không?

Nó là hoàn toàn có thể. Một cách được sử dụng thường xuyên trong chơi game là kịch bản Lua .

Từ bài viết được liên kết:

Lua ban đầu được thiết kế vào năm 1993 như một ngôn ngữ để mở rộng các ứng dụng phần mềm để đáp ứng nhu cầu tùy biến ngày càng tăng vào thời điểm đó.

Nhiều game sử dụng Lua. (Tôi sẽ liên kết nhưng danh tiếng người dùng mới đang giới hạn số lượng liên kết của tôi.)

Kịch bản Lua có thể được biên dịch vào thời gian chạy. Điều này có nghĩa là chúng có thể (ví dụ) là các tệp văn bản trong thư mục "script" của trò chơi của bạn, có thể dễ dàng chỉnh sửa bởi một người kiểm duyệt. Trò chơi của bạn tải chúng lên và chạy chúng.

Tôi đã thấy các tập lệnh Lua xác định các thuộc tính của các đơn vị trong trò chơi. Đây là một ví dụ ngẫu nhiên từ TA Spring.

Nhưng bạn muốn "mô tả tất cả các quy tắc". Về lý thuyết, điều đó có thể xảy ra, vì Lua là một ngôn ngữ đầy đủ, nhưng vấn đề là bạn phải có đủ khả năng để có mã trò chơi cốt lõi biết tìm kiếm các kịch bản để mở rộng hành vi của nó.

Chẳng hạn, bạn có thể phát triển một trò chơi bài biết tìm thẻ trong thư mục "tập lệnh / thẻ". Điều đó thật tuyệt vời khi thêm thẻ mới hoặc chỉnh sửa thẻ hiện có. Nhưng nếu sau này bạn muốn mở rộng trò chơi của mình để bao gồm các hình thu nhỏ trên lưới, bạn sẽ phải chỉnh sửa mã cốt lõi - không có số lượng Lua nào sẽ tự mình đưa bạn đến đó.

Xin lưu ý: Tôi mang lên Lua vì tôi biết nó thường được sử dụng cả trong chơi game và phần mềm để tùy chỉnh. Tôi không cho rằng đó là giải pháp duy nhất, cũng không phải là giải pháp tốt nhất cho nhu cầu của người hỏi.

Có một sự tiếp cận liên tục và liệu bất kỳ một trong số chúng có giá trị hay không, nó sẽ phụ thuộc vào chính xác những gì bạn đang cố gắng làm. Cụ thể, bạn muốn cung cấp bao nhiêu kiểm soát?

Trong phần cuối cùng của sự kiểm soát, bạn có thể chỉ cần để tweaker sửa đổi mã của toàn bộ trò chơi. Tại thời điểm đó, về cơ bản bạn sẽ xuất bản mã tiện ích và ít nhất một ví dụ về cách sử dụng nó. Một tweaker có thể sử dụng nhiều hoặc ít mã như họ muốn.

Một cách tiếp cận cung cấp ít kiểm soát hơn sẽ bằng cách nào đó "đóng băng" mã tiện ích của bạn (nói bằng cách biên dịch nó trước) và chỉ để các tweaker điền vào các chức năng cụ thể (gọi lại), hạn chế những gì chúng có thể làm. Tùy thuộc vào những gì bạn muốn làm, phương pháp này có thể có nhiều hình thức. Một phương pháp phổ biến sẽ là đặt tất cả các phần hiển thị trong mã tiện ích / mã chính và tất cả các cơ chế trong phần có thể điều chỉnh. Hoặc, bạn có thể muốn giữ một số cơ chế trong phần "đóng băng" vì người chơi không muốn thay đổi chúng, hoặc làm cho chúng thay đổi là quá phức tạp.

Ở đầu điều khiển thấp của tính liên tục chỉ cho phép các tweaker thay đổi giá trị trong một phạm vi cố định. Một tệp dữ liệu cho phép bạn chọn màu sắc của những thứ trong trò chơi sẽ là một ví dụ. Tuy nhiên, bạn có thể sử dụng phương pháp này và vẫn cung cấp rất nhiều tùy chỉnh. Có thể định nghĩa một lựa chọn các hàm và cho phép các tweaker kết hợp chúng để tạo ra các cuộc gọi lại từ cách tiếp cận trước đó, nhưng không cho phép chúng xác định các hàm mới. Hoặc có thể bạn bỏ qua phần sáng tác và chỉ đưa ra một lựa chọn hữu hạn.

Các chi tiết của tất cả các cách tiếp cận này và cách tiếp cận nào phù hợp với trường hợp sử dụng của bạn phụ thuộc vào loại trò chơi cơ bản bạn muốn thực hiện và mức độ kiểm soát mà bạn muốn từ bỏ. Lưu ý rằng các trò chơi thương mại thường chỉ sử dụng phương pháp thứ hai và thứ ba vì cách thứ nhất cho phép người chơi tạo các trò chơi hoàn toàn riêng biệt, điều này đưa ra các vấn đề cấp phép phức tạp. Lưu ý rằng khi các phương pháp này tạo thành một sự liên tục, cách tiếp cận thứ hai cũng có thể giới thiệu những vấn đề này.

Hoàn toàn có thể tách các quy tắc của hệ thống khỏi mã áp dụng các quy tắc đó. Tôi thích cấu trúc mã của mình theo cách đó cho các dự án phức tạp, vì nó giúp dễ dàng thêm các quy tắc mới hoặc thay đổi các quy tắc sau mà không đưa lỗi vào hệ thống cơ bản. Và các lỗi trong một công cụ quy tắc được tìm thấy nhanh hơn các lỗi trong một hệ thống trong đó các quy tắc và mã khác được trộn lẫn với nhau, bởi vì cùng một quy tắc được sử dụng lặp đi lặp lại bởi mọi quy tắc.

Cho dù nó có giá trị hay không phụ thuộc vào sự phức tạp của hệ thống. Giống như tôi sẽ không làm phiền Pac-Man, nhưng tôi không thể tưởng tượng việc viết Pháo đài Lùn bằng bất kỳ cách nào khác.

Nó chắc chắn khả thi. Nếu nó có giá trị, nó phụ thuộc vào mục tiêu của bạn.

Bạn không phải phát minh ngôn ngữ của riêng bạn hoặc viết trình biên dịch để thực hiện công việc này.

Nếu bạn muốn trò chơi của mình có thể dễ dàng mở rộng, có lẽ bạn nên dùng nó.

Có lẽ nhiều công việc hơn cho bạn, ít nhất là trong thời gian ngắn, để tạo ra các hệ thống dễ hiểu và làm cho mọi thứ dễ dàng sửa đổi.

Một trò chơi thực hiện điều này là Rimworld (tôi không có liên kết) và bạn có thể thấy và học hỏi từ cách họ đã làm, về cơ bản đưa rất nhiều dữ liệu và cơ chế trò chơi vào các tệp XML trong thư mục trò chơi cho bất kỳ ai xem và sửa đổi. Cốt lõi / công cụ của trò chơi được tạo ra bằng Unity.

Ngoài ra còn có khả năng mở rộng trò chơi xa hơn / sâu hơn bằng mã hóa thực tế, tôi biết ít hơn về điều đó nhưng bạn có thể tìm hiểu bằng cách xem diễn đàn mod.

Khả năng modding làm cho trò chơi thú vị hơn với nhiều người và tôi nghĩ nó đã đóng góp rất nhiều cho thành công của nó. Nó cũng cho phép các nhà phát triển đưa bất kỳ nội dung mod nào họ muốn vào trò chơi cốt lõi và theo cách nào đó, tăng tốc độ phát triển và cải thiện trò chơi vì họ nhận được sự trợ giúp từ nhiều người và họ có thể quyết định tham gia vào mọi thứ dựa trên những gì phổ biến, những gì dường như làm việc, vv

Và tất nhiên, đặc biệt là đối với một studio nhỏ độc lập, họ có hàng trăm người nảy ra ý tưởng và thử nghiệm chúng cho họ, đó là rất nhiều công việc họ không thể tự làm, cũng không phải thuê người làm.

Bạn có thể muốn xem xét Thiết kế hướng đối tượng . Python có hỗ trợ tốt cho điều đó.

Sách dày được viết về điều này có thể đáng sợ khi bạn là người mới, nhưng các nguyên tắc chính là khá dễ dàng.

Điểm chính chỉ là bạn xác định loại đối tượng bạn đang làm việc với. Bạn không nói bạn đang nghĩ về loại trò chơi nào, nhưng những thứ như Người chơi, Quái vật, Vật phẩm, Thiết bị, Vũ khí, Giáp v.v ... là những đối tượng điển hình.

Nếu bạn muốn các loại trò chơi khác nhau, có thể bạn sẽ muốn một đối tượng Trò chơi chăm sóc điều kiện chiến thắng và như vậy. Có lẽ một đối tượng Map cũng vậy?

Đôi khi không rõ liệu một cái gì đó xứng đáng là một đối tượng hay không, ví dụ như thiệt hại. Nếu bạn không làm hỏng một đối tượng, mã sẽ đơn giản hơn, nhưng làm cho nó trở thành một đối tượng giúp dễ dàng tùy chỉnh hơn.

Phân lớp: Cả Vũ khí và Vũ khí đều là Thiết bị. Thiết bị là vật phẩm. Có lẽ có nhiều loại vật phẩm khác. Bạn có thể sẽ thấy hữu ích khi định nghĩa một Lớp chiến binh mà cả Người chơi và Quái vật đều là lớp con của.

Ý tưởng là ví dụ Vũ khí sẽ có nhiều điểm chung với tất cả các loại Vật phẩm khác, chúng có trọng lượng, kích thước và các thuộc tính khác như thế.

Vì vậy, phân lớp cung cấp cho bạn một cách để nói rằng "Vũ khí cũng giống như các Vật phẩm khác, nhưng ngoài ra bạn có thể sử dụng chúng, chúng ảnh hưởng đến thiệt hại bạn làm, v.v."

Phân lớp cũng cho phép các nhà xây dựng mod của bạn nói "Loại vũ khí mới của tôi giống như vũ khí tiêu chuẩn ngoại trừ ..."

Sau đó, bạn phải quyết định đối tượng nào chịu trách nhiệm cho những gì. Điều này không dễ dàng như nó có vẻ và bạn nên suy nghĩ về nó. Việc lựa chọn sai sẽ không ảnh hưởng nhiều đến trò chơi cơ bản, nhưng sẽ khiến việc tùy chỉnh khó khăn hơn.

Miễn là bạn chỉ tự mày mò, bạn có thể thay đổi mọi thứ xung quanh nhưng thời điểm bạn phát hành thứ gì đó ra công chúng, việc thay đổi trở nên khó khăn hơn nhiều! Mọi người sẽ tạo ra các mod phụ thuộc vào mọi thứ giống như bây giờ. Ngay cả lỗi. Mọi người sẽ viết các mod phụ thuộc vào lỗi tồn tại trong mã. Nếu bạn thay đổi mọi thứ, những mod đó sẽ bị phá vỡ và đám đông lynch sẽ xuất hiện tại nhà bạn.

Ví dụ:

Người chơi cầm Vũ khí tấn công Quái vật mặc nhiều Armours. Điều này diễn ra trong một chế độ Trò chơi cụ thể và trên một Bản đồ nhất định.

Cả Combatant có thể có các Kỹ năng như Critical Hit và Dodge.

Bây giờ, đối tượng nào chịu trách nhiệm cho những gì?

Không có một câu trả lời đúng cho điều này. Rất nhiều phụ thuộc vào loại tùy chỉnh bạn muốn cho phép.

Nếu bạn không bao giờ gọi một đối tượng (ví dụ: Bản đồ), đối tượng đó không thể thay đổi cuộc tấn công theo bất kỳ cách nào.

Sau khi thực hiện tất cả các quyết định, tài liệu chúng . Viết một "Hướng dẫn sử dụng" liệt kê chính xác các phương thức có thể sửa đổi mà mỗi đối tượng có, các tham số họ thực hiện, những gì họ nên trả về, v.v và trên và trên ...

Chúc may mắn!

Một cách đơn giản để có được một số hỗ trợ cơ bản cho việc này là tách hầu hết các giá trị số thành một hoặc nhiều tệp văn bản riêng biệt để cho phép các cá nhân quan tâm điều chỉnh chúng vào quên lãng.

Ví dụ, bạn đã đề cập đến các trò chơi trên bàn; nếu bạn có một trò chơi dựa trên D & D, bạn có thể có một weapon_damagetệp chứa các dòng như Battleaxe: 1d12. Mã tiện ích của bạn sẽ đọc tệp đó và bất cứ khi nào thiệt hại được xử lý bởi Battleaxemã của bạn sẽ generate a number from 1-12, 1 time(s)thêm chúng vào. Battleaxe: 4d6Thay vào đó generate a number from 1-6, 4 time(s), tinh chỉnh dòng để đọc và thêm chúng. Tương tự, bạn có thể có một thư mục Creaturesvà bên trong bạn có một tệp cho mỗi sinh vật, bao gồm các dòng như AC: 12; sau đó thêm các tệp mới vào thư mục đó sẽ tạo ra các sinh vật mới. Nó thậm chí có thể được thực hiện cho các lớp nhân vật, loại địa hình, rất nhiều thứ.

Phong cách tùy biến không mã này vẫn có thể rất mạnh mẽ và bao gồm rất nhiều phần của trò chơi của bạn. Tuy nhiên, điều này không thực sự cho phép người dùng thực hiện các thay đổi mà bạn không chỉ định rõ ràng. Ví dụ: bạn có thể cho phép Sneak Attack: [damage]được trao cho bất kỳ Sinh vật hoặc Lớp nào để thêm [damage]vào bất kỳ cuộc tấn công nào đáp ứng các điều kiện cho Cuộc tấn công lén lút. Bạn thậm chí có thể cung cấp các cách để thay đổi các điều kiện là gì, chẳng hạn như "bất cứ khi nào bạn tấn công từ tàng hình" hoặc "bất cứ khi nào bạn đang tấn công" hoặc "bất cứ khi nào bạn có lợi thế". Tuy nhiên, nếu người dùng quyết định rằng họ muốn các cuộc tấn công lén lút là "Khi bạn thực hiện cuộn tấn công, bạn cũng có thể tàng hình chống lại nhận thức của mục tiêu. Nếu cả hai cuộn thành công, hãy thêm sát thương Sneak Attack"

Nếu bạn muốn người dùng có thể thêm hành vi hoàn toàn mới vào trò chơi mà không cần kỹ năng mã hóa ở cùng cấp độ với nhà phát triển, thì như mọi người đã đề cập, bạn đang nhìn vào việc tạo ra một công cụ trò chơi hoặc ngôn ngữ lập trình riêng biệt. Đối với các sửa đổi không yêu cầu kiến ​​thức mã hóa, các tệp dữ liệu dựa trên văn bản và cấu trúc thư mục vẫn có thể cung cấp nhiều tùy chọn. Nếu bạn muốn người dùng sửa đổi nhiều hơn thế thì bạn sẽ cần yêu cầu họ học hoặc biết một ngôn ngữ lập trình.

[Tôi là một nhà phát triển phần mềm kéo dài hàng thập kỷ, nhưng không có kinh nghiệm phát triển trò chơi, vì vậy có lẽ ngành công nghiệp trò chơi có những cách tiếp cận khác nhau, có thể vì những lý do chính đáng ...]

Cách tiếp cận của bạn hoàn toàn có ý nghĩa với tôi. Cốt lõi cung cấp các chức năng cơ bản mà cơ học và quy tắc xây dựng, do đó, đó là một API được sử dụng bởi các thành phần cấp cao hơn.

Và khi thiết kế API, hướng dẫn yêu thích của tôi là tạo ngôn ngữ mà bạn muốn thể hiện mã cấp cao hơn của mình (tất nhiên, với các giới hạn cú pháp của ngôn ngữ lập trình của bạn).

Vì vậy, một cách tiếp cận tốt sẽ là viết một số quy tắc và cơ chế giả định theo cách bạn muốn thể hiện (dĩ nhiên là sử dụng cú pháp của Python), do đó tìm ra những gì bạn muốn API cốt lõi cung cấp cho các quy tắc và cơ học các lớp.

Và tất nhiên, tôi khuyên bạn nên xem xét các phương tiện kịch bản của các trò chơi hiện có để có ý tưởng về những gì họ làm.