Sẽ tốt hơn nếu sử dụng XML / JSON / Text hoặc cơ sở dữ liệu để lưu trữ nội dung trò chơi?


29

Tôi đang xem xét làm thế nào để thực hiện một trò chơi dựa trên thành phần, vì đó dường như là điều nóng bỏng và tôi thích ý tưởng về một thiết kế linh hoạt như vậy. Một trong những tính năng của thiết kế như vậy là việc thêm những thứ mới vào trò chơi có thể được thực hiện thông qua dữ liệu, thường được trình bày dưới dạng tải nội dung thông qua các tệp văn bản như XML. Điều này có lợi thế là con người có thể đọc và dễ dàng chỉnh sửa trong bất kỳ trình soạn thảo văn bản nào. Mặt khác, văn bản có thể chậm hơn để xử lý và bạn phải quản lý một bộ sưu tập lớn các tệp dữ liệu. Các định dạng dựa trên văn bản tương tự như tệp JSON hoặc tệp cấu hình sẽ có lợi ích tương tự.

Mặt khác, có các cơ sở dữ liệu nhỏ, di động như SQLite hoặc Nội các Tokyo. Mặc dù không thể trực tiếp đọc được con người, nhưng các tệp này rất dễ giao tiếp và tôi tưởng tượng một loại công cụ chỉnh sửa nào đó sẽ thích hợp hơn cho thiết kế nội dung trò chơi. Sử dụng DB cho phép lưu trữ nhất quán thông tin cấu hình và dễ dàng truy xuất. Bạn cũng có thể tuần tự hóa dữ liệu vào DB để lưu trò chơi.

Hiệu suất khôn ngoan, tôi nghĩ rằng nói chung XML nhanh hơn đối với các tệp nhỏ nhưng cơ sở dữ liệu chia tỷ lệ tốt hơn với lượng lớn dữ liệu. Tôi tưởng tượng bất kỳ trò chơi thực sự nào cũng sẽ có rất nhiều đối tượng trò chơi.

Vì vậy, câu hỏi: phương pháp nào là thích hợp hơn? Tôi đang nghiêng về DB, nhưng tôi muốn biết liệu có những cạm bẫy tiềm ẩn hoặc lợi thế thực sự mạnh mẽ đối với các tệp văn bản. Hoặc nếu có những lựa chọn thay thế khác ngoài những điều này (nối tiếp sang định dạng nhị phân tôi đoán vậy?)

Câu trả lời:


18

Nó có thể không xuất hiện nhiều cho một trò chơi cá nhân nhỏ, nhưng một vấn đề khó khăn khi nói đến dữ liệu trò chơi là chỉnh sửa / phiên bản nhiều người dùng. Chúng tôi sử dụng rất nhiều tệp văn bản nhỏ được đưa vào một số lượng nhỏ các đốm nhị phân theo quy trình xây dựng. Điều này làm cho cuộc sống dễ dàng hơn cho các nhà thiết kế vì họ có rất nhiều sự linh hoạt trong quy trình làm việc của họ. ĐCSTQ, như một ví dụ ngược lại, sử dụng cơ sở dữ liệu chỉnh sửa trung tâm mà tất cả các nhà thiết kế kết nối với. Điều này làm cho bước xây dựng không cần thiết (hoặc ít nhất là đơn giản hơn rất nhiều) nhưng điều đó có nghĩa là bạn cần phải tự thực hiện tất cả các tính năng tạo phiên bản và quy trình công việc, vì vậy chúng bị ràng buộc đơn giản hơn các công cụ khác ngoài kia. Bạn có thể đối phó với hiệu suất trong cả hai trường hợp, vì vậy câu hỏi thực sự là bạn muốn gì cho một quy trình thiết kế và làm thế nào bạn có thể đến đó?


Đó là một điểm tuyệt vời. Tôi đã không xem xét quy trình làm việc của nhiều người quá chặt chẽ cũng như kiểm soát phiên bản. Cả hai đều là những đối số rất tốt có lợi cho các tệp văn bản, ít nhất là dưới dạng tài liệu nguồn. Hỗ trợ công cụ dễ dàng hơn là tốt. Cảm ơn quan điểm đó!
CodexArcanum

Việc xuất một cơ sở dữ liệu sang XML cũng khá dễ dàng. Chỉ với một chút lập kế hoạch chuyển tiếp, bạn có thể viết trình tải thành phần của mình dưới dạng giao diện - sau đó chỉ cần cắm trình đọc cơ sở dữ liệu hoặc trình đọc tệp xml. Trong khi xây dựng các thành phần, cơ sở dữ liệu có thể dễ dàng hơn vì có GUI sẵn sàng cho tất cả các thao tác dữ liệu so với chỉnh sửa nhiều tệp. Sau đó, trong quá trình xây dựng cuối cùng, chỉ cần lưu cơ sở dữ liệu vào xml, nướng thành nhị phân, v.v ... và phiên bản sản xuất của trò chơi chỉ cần sử dụng trình tải thích hợp.
khoan hồng

1
Điều đó sẽ giúp như thế nào? Sử dụng trình chỉnh sửa tùy chỉnh và sau đó xuất ra tệp văn bản thực sự mang đến cho bạn những phần tồi tệ nhất của mỗi tùy chọn :-P
coderanger

7

JSON rất nhẹ và dễ hiểu. Tôi nghĩ rằng nó phù hợp hơn cho một trò chơi. CJSON thực sự tốt đẹp. nó cũng sẽ kết hợp vào nguồn của bạn theo cách tương tự như SQLlite.

Các tệp XML khó chỉnh sửa hơn người dùng bạn nghĩ. nếu bạn đi theo con đường đó, bạn có thể muốn tạo một trình soạn thảo cho mọi người sử dụng để giúp họ tránh những cạm bẫy thông thường.


Tôi thực sự chưa bao giờ nhìn JSON nhiều như vậy, vì tôi hài lòng với XML (Nó thực sự dễ đến mức nào) .. hóa ra JSON khá tuyệt vời ... nhưng giống như XML không chắc nó sẽ hoạt động như thế nào nếu nó rất dữ liệu nặng
Spooks

7

Tôi đến bữa tiệc muộn ở đây nhưng tôi đã dành rất nhiều thời gian để nghiên cứu về điều này.

Đầu tiên tại sao tôi không sử dụng như sau:

XML: Quá dài dòng. Tấn dư thừa. Lặp lại tên trường? TỔNG

JSON: Tôi nghĩ JSON là tuyệt vời cho bố cục UI nhưng đối với cơ sở dữ liệu, địa ngục không. Nó sẽ có các vấn đề tương tự như XML, dự phòng và lồng nhau sâu. TỔNG.

SQL : Đây là một lựa chọn tuyệt vời, nếu bạn quản lý những vấn đề đau đầu khi thiết lập nó. Tôi đã tạo các trò chơi di động nơi chúng tôi lưu trữ dữ liệu trò chơi trực tuyến trong cơ sở dữ liệu SQL. Các định dạng bảng là tốt đẹp. Vấn đề là chúng tôi đã phải tìm nạp cơ sở dữ liệu từ trực tuyến và thiết lập có thể gây rắc rối. Nhưng SQL là một giải pháp tốt. Unity không hỗ trợ điều này một cách tự nhiên và các plugin tôi đã thử có vấn đề lớn (đặc biệt là khi cố gắng làm cho nó hoạt động với kiểm soát phiên bản).

Cuối cùng, đây là giải pháp tôi chọn sử dụng (và tôi thích nó).

CSV : Đơn giản. Cho phép tôi sử dụng định dạng bảng và tôi có một điểm tham chiếu dễ dàng khi tôi cần cập nhật. Tôi có thể có một bảng cho tất cả các vũ khí của mình, các cột cho tất cả các thuộc tính và các hàng cho từng loại vũ khí.

Bạn có thể sử dụng Microsoft Excel nhưng nó sẽ đưa ra những cảnh báo ngu ngốc này mỗi khi bạn cần lưu. Bạn có thể sử dụng các macro để ghi đè lên nó nhưng tôi nói hãy tự cứu lấy rắc rối và nhận LibreOffice . Nó miễn phí, hỗ trợ chỉnh sửa CSV và khi bạn mở tệp, nó sẽ tải chiều rộng cột để khớp với tên (Excel không làm điều này và nó khiến tôi phát điên).

Sau đó, bạn chỉ cần phân tích các tệp CSV vào trò chơi của bạn. Tôi sử dụng Unity vì vậy tất cả những gì tôi phải làm là sử dụng trình phân tích cú pháp C # CSV tiện lợi mà tôi đã tìm thấy:

Ví dụ về trình phân tích cú pháp CSV

Bạn chuyển đổi các tệp CSV thành các đối tượng dữ liệu trong trò chơi của mình và bạn sẽ thấy ổn. Với Unity, bạn có thể biến chúng thành ScriptableObjects . Vì vậy, quy trình công việc của tôi là: Cập nhật CSV -> Phân tích CSV thành Đối tượng có thể đọc được -> Sử dụng dữ liệu từ ScriptableObjects cho trò chơi của tôi


6

Câu trả lời cho điều này phụ thuộc vào ngôn ngữ bạn đang sử dụng cho trò chơi.

Nếu bạn đang sử dụng C ++, bạn sẽ được khuyên sử dụng một trong các thư viện XML hiện có (chẳng hạn như TinyXml hoặc người nước ngoài ).

Mặt khác, nếu bạn đang sử dụng PHP, bạn có thể rất dễ dàng sử dụng máy chủ cơ sở dữ liệu như MySQL hoặc SQLite. (Hãy nhớ rằng nếu bạn đi theo tuyến đường này, bạn sẽ cần nhiều tài nguyên hơn vì máy chủ cơ sở dữ liệu sẽ chạy như một quy trình riêng biệt và các ứng dụng cơ sở dữ liệu lớn hơn như MySQL có thể tiêu tốn rất nhiều RAM khi chạy.)

JSON đang đạt được rất nhiều động lực và chắc chắn là lựa chọn tốt nhất nếu ứng dụng của bạn được viết bằng nhiều ngôn ngữ.

Nói tóm lại, nó phụ thuộc vào những gì có thể sử dụng dễ dàng trong ngôn ngữ của bạn.


1
Có vấn đề gì khi sử dụng bất kỳ DB nào từ C ++?
Budda

2

Nếu bạn muốn ở lại trong vương quốc XML của những thứ bạn có thể sử dụng XML nhị phân để giúp tăng hiệu suất tải.

Ví dụ: Fast Infoset là một triển khai của xml nhị phân

Mọi người có thể nghĩ Fast Infoset là gzip cho XML, mặc dù FI nhằm mục đích tối ưu hóa cả kích thước tài liệu và hiệu suất xử lý, trong khi gzip chỉ tối ưu hóa kích thước. Mặc dù định dạng ban đầu bị mất, không có thông tin nào bị mất khi chuyển đổi từ XML sang FI và quay lại XML.


Mặc dù có lẽ không phải thứ gì đó tôi sẽ sử dụng (Tôi nghiêng về JSON qua XML) tôi đánh giá cao các liên kết.
CodexArcanum

1

Tôi đã thiết kế cơ sở dữ liệu và chơi xung quanh với nhiều ý tưởng trò chơi trong nhiều năm nay. Yêu thích cá nhân của tôi tại thời điểm này, là một số định dạng văn bản, có thể đọc được cho con người để cấu hình, nhưng sau đó phân tích các "tập lệnh chậm" này thành một cái gì đó dễ chạy hơn. Giống như JAVA và .NET được biên dịch thành mã byte thời gian chạy.

Cùng một ý tưởng ở đây. Tôi có một phiên bản "nguồn" của các thành phần và sau đó trình biên dịch trước / trình phân tích cú pháp chạy qua các thành phần này. Nếu chúng chiếm quá nhiều bộ nhớ, bạn có thể đặt chúng vào một cơ sở dữ liệu SQL nhanh của một số loại hoặc lưu chúng dưới dạng tệp nhị phân. Nhưng quan điểm của tôi là, sử dụng bộ nhớ hoặc cơ sở dữ liệu SQL làm không gian làm việc / bộ đệm của bạn để bạn không phải phân tích cú pháp các tập lệnh nhiều lần. Bạn có thể tạo trình biên dịch, di chuyển các tệp được phân tích cú pháp thành "nguồn-lib" và bằng cách này, hãy để trình biên dịch trước thực hiện phiên bản (giữ các tệp trước đó cho mục đích khôi phục).

Nếu đó là về "không gian ổ cứng không giới hạn", thì hãy đăng ký một cái gì đó như Dropbox hoặc Amazon S3 và đồng bộ hóa với chúng.

Vì vậy, kế hoạch cho tôi hiện tại là:

  1. Cấu hình / scripts / xml (một số định dạng có thể đọc được của con người) dưới dạng tệp văn bản (giống như mã nguồn)
  2. Trình phân tích cú pháp / trình xác nhận chạy qua các tập lệnh mới và kiểm tra xem chúng có tuân theo các quy tắc không
  3. Trình biên dịch làm cho hàng nhị phân hoặc SQL ra khỏi các tệp gốc, sao cho các tệp này nhanh chóng truy xuất lại + chạy nhanh.

Về tính ổn định, tôi hiện đang xây dựng cơ sở dữ liệu thành "đồng vị trí được lưu trữ" và tự động đồng bộ hóa giữa nhiều vị trí, do đó, nếu có một mạng / phần cứng bị lỗi một vị trí, các trang web khác sẽ có thể xử lý cùng một lưu lượng / các trò chơi.


Giải pháp thú vị, đặc biệt là đưa ra bao nhiêu lưu trữ đám mây đã phát triển kể từ khi câu trả lời của bạn được viết.
Rideoutcolin

1

Nếu bạn sử dụng couchdb, về cơ bản bạn sẽ lưu mọi thứ dưới dạng cấu trúc JSON. Couchdb sẽ đảm nhiệm việc sao chép dữ liệu (nhiều) người dùng của bạn ít nhiều không gây đau đớn.


0

Bạn có thể tìm thấy một quy trình trong Unity Wiki với PHP, MySQL và C # / JavaScript và nó hoạt động tốt cho mục đích của nó.

Nó bao gồm ba bước

  1. Tạo một cơ sở dữ liệu MySQL trống và một bảng.
  2. Tạo tập lệnh phía máy chủ PHP (Điều này sẽ kết nối với bảng MySQL, nhận dữ liệu từ tập lệnh Unity (bước 3) và truy vấn cơ sở dữ liệu (các ví dụ đã cho là chèn dữ liệu hoặc chọn))
  3. Tạo tập lệnh điều khiển Unity (Điều này sẽ kết nối với tập lệnh PHP được tạo ở bước 2)
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.