Tại sao nó là xấu cho nội dung mã cứng?

Tôi biết hầu hết các trò chơi lưu trữ văn bản đối thoại trong các tệp, nhưng tôi cũng đã thấy một số trò chơi dựa trên văn bản thực sự lập trình nội dung (bản đồ, lựa chọn, lệnh người chơi có thể, văn bản câu chuyện) vào mã trò chơi.

Tôi có thể nghĩ ra một vài lý do, nhưng lý do chính tại sao ngay cả các trò chơi văn bản giữ mọi thứ trong các tệp bên ngoài chương trình?

Các chi tiết triển khai khác nhau rất ít giữa việc giữ nội dung theo một định dạng như định dạng XML phổ biến, phân tích cú pháp, sau đó hiển thị bản đồ / hiển thị văn bản dựa trên các biến được tạo từ tệp XML và chỉ đơn giản là gửi toàn bộ tệp XML. Cả hai kết thúc với chuỗi xuất ra màn hình. Không phải là sự khác biệt chỉ là ký hiệu?

Một số trò chơi thậm chí còn giữ đồ họa (nghệ thuật ASCII?) Bên trong mã. Tôi biết điều này không đúng và tôi có thể đoán một vài lý do tại sao nó xấu, nhưng không biết lý do chính tại sao.

Nó là rất phổ biến để có hầu hết các nội dung bên ngoài chương trình. Ngay cả Pháo đài Lùn cũng không sử dụng các ký tự ASCII thực tế, nhưng hình ảnh của các ký tự ASCII được tải vào bộ nhớ.

Tôi chủ yếu yêu cầu bởi vì đó là một chút của PITA để tạo, phân tích cú pháp và làm việc với các tệp XML. Bạn biết đấy ... so với sự thay thế lười biếng chỉ làm cho mỗi dungeon độc đáo (nội dung) trở thành lớp học riêng của nó.

Có nhiều lý do cho điều đó. Tôi sẽ chỉ chạm vào một vài:

1. Nó làm cho mã nguồn của bạn trở nên lộn xộn. Nếu bạn có nhiều hộp thoại (cây), một phần lớn trong cơ sở mã của bạn chỉ là văn bản không liên quan gì đến mã trò chơi thực tế của bạn.
2. Bạn sẽ cần biên dịch lại mỗi khi bạn thay đổi quá nhiều thành một ký tự.
3. Bản thân hộp thoại khó điều hướng. Tôi tưởng tượng việc cố gắng thực hiện toàn bộ cây hộp thoại, huống chi là một vài, hoàn toàn bên trong nguồn của bạn sẽ dẫn đến một mớ hỗn độn của spaghetti và các ifs, switches, v.v. Mà sau đó dẫn đến mã dễ bị lỗi, khó đọc và khó gỡ lỗi hơn.
4. Nếu bạn muốn cho phép mọi người sửa đổi hoặc mở rộng trò chơi của mình, điều đó sẽ dễ dàng hơn nhiều nếu họ không phải đối phó với mã nguồn để thay đổi điều gì đó.
5. Điểm trên thậm chí còn quan trọng hơn nếu bạn làm việc trong một nhóm. Bạn không muốn nhà văn của bạn phải lộn xộn với mã chỉ để nhập một đoạn hộp thoại.
6. Phân tích cú pháp XML hoặc các định dạng tệp tiêu chuẩn khác khá dễ thực hiện nếu bạn sử dụng các thư viện hiện có, do đó chi phí thực hiện theo cách đó rất thấp trong khi mang lại cho bạn nhiều lợi thế và tránh các vấn đề được đề cập ở trên và nhiều hơn nữa.
7. Như @Miloprice chỉ ra bên dưới, việc bản địa hóa trò chơi cũng dễ dàng hơn nhiều nếu văn bản của bạn nằm trong các tệp bên ngoài. Bạn có thể thêm ngôn ngữ bằng cách thêm tệp, nhóm của bạn có thể đảm nhiệm việc dịch mà không cần phải chạm vào nguồn (điều này đặc biệt quan trọng nếu bạn cho phép mọi người dịch những người không được phép xem tất cả mã của bạn - nghĩ rằng những người làm việc tự do, những người từ cộng đồng không thuộc về nhóm của bạn, v.v.).

Đưa dữ liệu nội dung trò chơi vào mã có nghĩa là để thấy bất kỳ thay đổi hoặc lặp lại tiềm năng nào của dữ liệu nội dung trò chơi đó, bạn phải tự biên dịch lại trò chơi. Điều này là xấu vì hai lý do:

• Nhiều ngôn ngữ mà các trò chơi được viết trong thời gian biên dịch dài. C ++ đặc biệt có thể rất tệ về mặt này và C ++ là ngôn ngữ rất phổ biến cho các trò chơi thương mại lớn. Nó không phải là vấn đề với các ngôn ngữ như C # và Java, nhưng vẫn không nhanh như khả năng lưu trữ dữ liệu trò chơi trong các tệp bên ngoài có thể được tải lại nóng trong khi trò chơi đang thực sự chạy để xem các thay đổi.

• Nhiều trò chơi được phát triển bởi các đội thường bao gồm các nhà phát triển phi kỹ thuật (nhà thiết kế và nghệ sĩ) sản xuất nội dung. Những người không có kỹ thuật không muốn phải biên dịch lại trò chơi hoặc xử lý "công cụ lập trình rườm rà" để lặp lại nội dung của họ, có thể mong muốn giảm thiểu tiếp xúc với mã nguồn chỉ với các lập trình viên (vì càng ít người hơn có quyền truy cập vào mã nguồn, càng ít người có thể rò rỉ nó - vô tình hay không).

Tôi nghĩ rằng bạn đang đánh giá quá cao sự phức tạp của việc tải dữ liệu từ các tệp văn bản hoặc XML. Hầu hết thời gian bạn nên sử dụng một thư viện để làm điều này, điều này làm cho quá trình phân tích cú pháp XML / JSON / bất cứ điều gì dễ dàng hơn nhiều. Đúng, có một chút chi phí trả trước để viết một hệ thống tải mức được điều khiển theo dữ liệu nhưng nhìn chung sẽ giúp bạn tiết kiệm rất nhiều thời gian trong thời gian dài so với hàng tấn các lớp duy nhất để đại diện cho mỗi cấp.

Các trò chơi nhỏ hơn hoặc đơn giản hơn có thể không thu được nhiều từ khoản đầu tư dài hạn của phương pháp dựa trên dữ liệu, vì vậy trừ khi các nhà phát triển đang sử dụng các khung / công cụ hiện có hỗ trợ, việc mã hóa dữ liệu có thể hiệu quả hơn. mã trò chơi.

Tất nhiên có một loạt lý do tại sao bất kỳ trò chơi cụ thể nào cũng có thể chọn đưa dữ liệu của họ vào các tệp bên ngoài (hoặc không); không thể liệt kê tất cả Ở một mức độ nào đó, tất cả chúng thường sẽ sôi sục với tốc độ lặp lại bổ sung hoặc tính linh hoạt mà không cần phải xây dựng lại trò chơi có thể cung cấp.

Như mọi khi, như mọi khi, nó phụ thuộc. Nhưng trước tiên, tôi muốn lập luận rằng mã hóa cứng không phải là xấu.

Tôi có nội dung được mã hóa cứng, cụ thể là văn bản hộp thoại, trong một số trò chơi đơn giản và thế giới không kết thúc. Chúng tôi lập trình viên thích những thứ trừu tượng, nhưng hãy nhớ rằng mỗi lớp trừu tượng bạn thực hiện sẽ làm cho chương trình của bạn phức tạp hơn và khó hiểu hơn.

Nếu trò chơi của bạn đủ đơn giản để bạn có thể mã hóa một số nội dung trong đó, tôi chắc chắn sẽ xem xét nó vì mục đích đơn giản.

Điều này, tuy nhiên, không thực sự quy mô quá nhiều. Chắc chắn lý do phổ biến nhất để đưa nội dung vào các nguồn lực bên ngoài là để đơn giản hóa tinh thần đồng đội, vì một người hoặc nhóm có thể tập trung vào viết trò chơi, trong khi một người khác có thể tập trung vào việc tạo và đánh bóng nội dung.

Tuy nhiên, việc vẽ ranh giới giữa chương trình và nội dung không phải lúc nào cũng thực sự tầm thường. Người ta có thể nói rằng kết cấu là 100% nội dung; Nhưng những gì về kết cấu tạo thủ tục? Văn bản hộp thoại có thể được coi là 100% nội dung; Nhưng khi hộp thoại thay đổi tùy thuộc vào hành động trước của bạn thì sao? Các yếu tố khác mà người ta có thể coi là 100% của chương trình, như kịch bản hoặc trình đổ bóng, cũng có thể được coi là một phần của nội dung của trò chơi. Họ có nên được mã hóa cứng? chúng có nên được tải như một nguồn tài nguyên bên ngoài?

Mặc dù vậy, hãy nhớ rằng mỗi loại nội dung bạn hỗ trợ trong trò chơi của bạn phải có mã tải và diễn giải liên quan đến nó, vì vậy, nói chung, nếu nghi ngờ, tôi khuyên bạn nên giới thiệu nội dung mã hóa cứng và chỉ đưa nó ra tài nguyên bên ngoài khi bạn thực sự cần sự linh hoạt đó (không phải khi bạn nghĩ rằng bạn - tôi cần nó, mà là khi bạn thực sự làm)

Cuối cùng, một lợi thế của việc lưu trữ dữ liệu trong các tệp tài nguyên là bạn chỉ có thể tải chúng khi bạn cần (do đó có thể tăng tốc thời gian tải trò chơi) và hủy tải chúng khi bạn không cần chúng nữa (do đó cho phép bạn có thêm nội dung hơn có thể phù hợp với bộ nhớ). (Góc của Nitopperers: DLL tài nguyên có thể được coi là tài nguyên bên ngoài)

Một lý do lớn để lưu trữ trong các tập tin văn bản là tái sử dụng. Tạo khung trò chơi văn bản đọc bản đồ, hộp thoại và các tài nguyên khác từ tệp văn bản cho phép bạn sử dụng lại khung của mình cho các trò chơi khác. Vượt xa hơn các trò chơi văn bản, đây là cách các tựa game có ngân sách lớn như Call of Duty phát hành một trò chơi mới mỗi năm.

Một lý do khác là tính di động. Bạn có thể sử dụng cùng một tệp cho web, pc, Mac, Android, v.v. Tất cả những gì bạn cần làm là mô phỏng khung của bạn cho các nền tảng khác nhau này và phần lớn dữ liệu trò chơi không được xử lý.

Khi vượt ra ngoài các trò chơi dựa trên văn bản có tập lệnh và dữ liệu được lưu trữ trong các tệp sẽ giảm thời gian biên dịch lại và cho phép bạn tạo giao diện để thao tác dữ liệu dễ dàng hơn.

Vì mục đích thực hiện các thay đổi nhanh hơn, nó tăng tốc độ phát triển trên các sản phẩm lớn hơn hàng tấn.

Bạn không cần dạy mọi người học cách đi vào và chỉnh sửa nguồn để thực hiện các thay đổi đơn giản. Bằng cách kéo nó ra khỏi mã thực tế, nhiều người có cơ hội đánh lừa hơn, việc tìm ra các tùy chọn bạn có thể chơi xung quanh sẽ dễ dàng hơn và toàn bộ quá trình hoàn thiện các phần khác nhau của trò chơi của bạn tốn ít thời gian hơn. Ngay cả Q & A cũng có thể giúp với điều đó.

Tôi không thể tin rằng chưa có ai đề cập đến vấn đề này, nhưng một lý do lớn là làm cho việc bản địa hóa RẤT NHIỀU dễ dàng hơn. Nếu bạn cần hỗ trợ tiếng Anh, tiếng Pháp, tiếng Đức, tiếng Tây Ban Nha, tiếng Bồ Đào Nha, tiếng Ý, tiếng Nga, tiếng Trung và bất kỳ ngôn ngữ nào khác mà bạn nhắm đến, mã hóa cứng đòi hỏi bạn phải có mã riêng biệt cho mỗi ngôn ngữ. Điều đó cũng có nghĩa là nếu bạn cần xóa một số nội dung nhất định (đọc: kiểm duyệt), bạn cần thay đổi mã của mình để tránh nó, thay vì nói "chỉ cần thay thế minigame thăm dò hậu môn này bằng biểu ngữ tích cực thụ động này giải thích bằng đồ họa những gì đang diễn ra ". Nó cũng không thân thiện với người tiêu dùng, vì có khả năng họ sẽ cần phải khởi động lại trò chơi để thay đổi ngôn ngữ, vì bạn cần tải các thư viện khác. Cuối cùng,

Mặt khác, nếu bạn đang sử dụng các tài nguyên bên ngoài, việc hỗ trợ các ngôn ngữ khác nhau chỉ có nghĩa là tải một tệp tài nguyên khác. Điều này có thể dễ dàng được thực hiện trong khi trò chơi đang chạy. điều đó có nghĩa là bạn có thể có một cơ sở mã duy nhất, đơn giản hóa sự phát triển. Và nó cũng có nghĩa là bạn có thể dễ dàng thêm hỗ trợ sau khi phát hành cho các ngôn ngữ khác. Cuối cùng, điều đó có nghĩa là bạn có thể cho phép người dùng từ chối cài đặt một số ngôn ngữ nhất định (một tính năng không xảy ra thường xuyên trong các trò chơi, nhưng một ngôn ngữ vẫn có thể) để tiết kiệm dung lượng đĩa và băng thông.

Tôi nghĩ rằng một cụm từ quan trọng là tách mối quan tâm .

Nếu mã của bạn không bao gồm văn bản thì mã sẽ ít phức tạp hơn. Lập trình viên viết mã không phải suy nghĩ về văn bản cụ thể và có thể tập trung vào mã.

Anh ta không phải suy nghĩ về nội địa hóa. Người thực hiện nội địa hóa không phải lo lắng về mã.

Tôi nghĩ thật quá dễ dàng để trở thành anh chàng 'khô héo' hơn và khuyên bạn nên sử dụng một tệp tài nguyên văn bản bên ngoài.

Tại sao? Bởi vì có một sự lựa chọn ở đây là về việc cân bằng chi phí / vấn đề / lợi thế của từng giải pháp.

Khi sử dụng một tập tin bên ngoài ... Chà, tôi đoán các câu trả lời khác giải thích đủ lợi ích. Nhưng những gì về chi phí? Bạn phải xác định một hình thức chính thức hợp lệ, xây dựng một trình thông dịch, đồng ý về định dạng tệp và tệ hơn là ... xây dựng một ứng dụng khác - một trình soạn thảo-. Đó là vấn đề 0,00% nếu bạn là thành viên của nhóm 50 lập trình viên xây dựng một dự án lớn. Nhưng nếu bạn cô đơn: bạn bị đình trệ.

Một lần nữa, tôi không đánh giá thấp lợi ích linh hoạt to lớn của tài nguyên bên ngoài: lập trình dựa trên dữ liệu dường như là cách để tôi chơi trò chơi điện tử. Nhưng đừng quên chi phí.

Mặt khác, có văn bản bên trong mã cho phép tạo mẫu nhanh, vì vậy nó nên được ưu tiên trong lần đầu tiên. Sau đó, lời khuyên của tôi là, khi dự án trưởng thành, để phân tích loại dữ liệu cần thiết để mô hình hóa các hộp thoại (tâm trạng / lịch sử-trạng thái / ...). Sau đó, tại một số điểm, bạn quyết định một số lớp / quy tắc / định dạng tệp và đi đến thực tế, cho phép người khác chỉnh sửa / tách mã từ nội dung và vv. HOẶC cho một trò chơi với các hộp thoại đơn giản (Mario ...) bạn chỉ cần xem xét chi phí quá cao và bạn giữ cho một vài chuỗi / hành vi được mã hóa cứng.
Cuộc gọi của bạn.

(Lưu ý về nội địa hóa: nó chỉ là một bảng băm, vì vậy đây là một vấn đề độc lập và dễ giải quyết.)

Tôi đoán việc cấp phép cũng có thể là một lý do không bao gồm nội dung trong mã.

Ví dụ,

• mã của bạn có thể là FLOSS , nhưng bạn hoàn toàn không muốn cấp phép cho nội dung của mình (có thể bạn muốn xuất bản mã trò chơi của mình để người khác có thể sử dụng nó để tạo các trò chơi tương tự có nội dung khác nhau)
• mã của bạn có thể là FLOSS, nhưng bạn muốn sử dụng giấy phép Creative Commons cho nội dung của mình (vì giấy phép phần mềm không hoạt động tốt cho nội dung và ngược lại)
• mã của bạn có thể là độc quyền , nhưng bạn đang sử dụng lại nội dung miễn phí
• mã của bạn có thể là độc quyền, nhưng bạn muốn xuất bản nội dung của riêng bạn theo giấy phép miễn phí / libre