Làm thế nào để chọn làm thế nào để lưu trữ dữ liệu?

Cho một người đàn ông một con cá và bạn cho anh ta ăn trong một ngày. Dạy một người đàn ông câu cá và bạn nuôi anh ta cả đời. - Tục ngữ Trung Quốc

Tôi có thể hỏi tôi nên sử dụng loại lưu trữ dữ liệu nào cho dự án thực tế của mình, nhưng tôi muốn học cách câu cá , vì vậy tôi không cần yêu cầu một con cá mỗi khi tôi bắt đầu một dự án mới.

Vì vậy, cho đến khi tôi sử dụng hai phương pháp để lưu trữ dữ liệu trong dự án phi trò chơi của mình: tệp XML và cơ sở dữ liệu quan hệ. Tôi biết rằng cũng có loại cơ sở dữ liệu khác, thuộc loại NoQuery . Tuy nhiên tôi sẽ không biết nếu có thêm sự lựa chọn cho tôi, hoặc làm thế nào để chọn ở nơi đầu tiên, bỏ qua việc chọn một cách tùy tiện.

Vì vậy, câu hỏi là như sau: Làm thế nào tôi nên chọn loại lưu trữ dữ liệu cho một dự án trò chơi?

Và tôi sẽ quan tâm đến tiêu chí sau đây khi lựa chọn:

• Quy mô của dự án.
• Nền tảng được nhắm mục tiêu bởi trò chơi, cũng như nền tảng phát triển được sử dụng.
• Sự phức tạp của cấu trúc dữ liệu.
• Đã thêm Tính di động của dữ liệu trong số nhiều dự án.
• Đã thêm2 Sử dụng dữ liệu một cách tự nhiên giữa các dự án khác nhau. (tức là dữ liệu người dùng)
• Đã thêm tần suất dữ liệu nên được truy cập
• Đã thêm nhiều loại dữ liệu cho cùng một ứng dụng
• Đã thêm2 Cấu hình với nhiều lưu trữ dữ liệu.
• Bất kỳ điểm nào khác bạn nghĩ là quan tâm khi quyết định sử dụng cái gì.

EDIT Tôi biết về việc sử dụng XML / JSON / Text hoặc cơ sở dữ liệu để lưu trữ nội dung trò chơi sẽ tốt hơn? , nhưng nghĩ rằng nó không giải quyết chính xác quan điểm của tôi. Bây giờ nếu tôi sai, tôi sẽ vui lòng được hiển thị lỗi theo cách của tôi.

EDIT2 Đã thêm một số điểm mà tôi sẽ xem xét có liên quan. Hơn nữa, tôi rất muốn nghe những tùy chọn khác có sẵn, ngoài việc lưu trữ tệp phẳng và cơ sở dữ liệu quan hệ. Điều gì về cơ sở dữ liệu không liên quan, ví dụ? Khi có liên quan để sử dụng một cơ sở dữ liệu như vậy trên các tùy chọn khác đã đề cập trước đây?

Câu hỏi của bạn thực sự rộng vì số lượng thể loại tuyệt vời ngoài kia, nhưng đây là viễn cảnh của một nhà phát triển phần mềm chuyên nghiệp.

Bạn đã cung cấp một danh sách các tiêu chí mà bạn muốn sử dụng để xác định cơ chế lưu giữ dữ liệu nào bạn sử dụng. Đó là:

• Quy mô của dự án.
• Nền tảng được nhắm mục tiêu bởi trò chơi.
• Sự phức tạp của cấu trúc dữ liệu.
• Tính di động của dữ liệu giữa nhiều dự án.
• Dữ liệu nên được truy cập thường xuyên như thế nào
• Nhiều loại dữ liệu cho cùng một ứng dụng
• Bất kỳ điểm nào khác bạn nghĩ là quan tâm khi quyết định sử dụng cái gì.

Đầu tiên chúng ta cần thiết lập các tùy chọn có sẵn cho chúng ta. Vì bạn không chỉ định ngôn ngữ hoặc công nghệ, thật khó để nói chính xác, nhưng có lẽ bạn đang cố gắng quyết định giữa XML và lưu trữ cơ sở dữ liệu quan hệ .

Một điểm khác biệt quan trọng cần thực hiện là XML không thực sự là một cơ chế lưu trữ nhiều như một kỹ thuật tuần tự hóa. Đó là một cách để thể hiện các cấu trúc trong bộ nhớ cho trò chơi của bạn. Cho rằng, bạn thực sự đang nói về tập tin phẳng so với lưu trữ cơ sở dữ liệu quan hệ . Đây không phải là những lựa chọn duy nhất, nhưng chúng là phổ biến nhất, vì vậy tôi sẽ sử dụng chúng.

Đối với các tệp phẳng:

• XML
• JSON
• YAML
• XAML
• Văn bản thô

Đối với cơ sở dữ liệu:

• Máy chủ SQL
• MySQL
• DB2
• Oracle
• Nhiều hơn nữa

EDIT: Bạn đã hỏi về các loại cơ chế khác ngoài các tệp và cơ sở dữ liệu quan hệ. Loại cơ sở dữ liệu đáng chú ý khác mà tôi đã thấy được sử dụng thường xuyên là cơ sở dữ liệu "kiểu Berkeley", về cơ bản là dựa trên khóa-giá trị. Những người này có xu hướng sử dụng cây B để cấu trúc dữ liệu để việc tra cứu được nhanh chóng. Đây là những điều tuyệt vời cho việc tra cứu cấu hình / cài đặt nơi bạn biết chính xác những gì bạn muốn (ví dụ: cung cấp cho tôi tất cả dữ liệu từ xa cho "Cấp 1").

Bây giờ chúng ta đã có tất cả những điều cơ bản trên đường đi, hãy chạm vào một số tiêu chí của bạn.

Quy mô của dự án.

Một số có thể không đồng ý, nhưng quy mô dự án của bạn sẽ không nhất thiết có tác động lớn đến cơ chế lưu giữ dữ liệu của bạn. Bạn sẽ muốn xây dựng một thư viện các hàm có thể sử dụng lại để lưu trữ / tải dữ liệu từ bất kỳ cơ chế nào bạn muốn. Tôi thậm chí sẽ đề nghị thực hiện một lớp trừu tượng (kiểm tra mẫu Adaptor ) để bạn có thể dễ dàng thay đổi cơ chế kiên trì của mình nếu bạn cần.

Phải nói rằng, đối với các dự án nhỏ, sử dụng XML trên hệ thống tệp có khả năng hoạt động tốt, nhưng bạn sẽ muốn giải quyết một số vấn đề bảo mật của mình (ví dụ: mã hóa) để người chơi không thể thay đổi dữ liệu theo ý muốn.

Nền tảng được nhắm mục tiêu bởi trò chơi.

Nền tảng sẽ không phải là một vấn đề lớn. Bạn nên quan tâm đến nền tảng phát triển của mình hơn nền tảng đích. Lý do cho điều này là một số ngôn ngữ xử lý một số loại đánh dấu hoặc cơ sở dữ liệu tốt hơn các ngôn ngữ khác. Điều đó không có nghĩa là bạn không thể sử dụng bất kỳ ngôn ngữ nào ở trên trong hầu hết mọi ngôn ngữ, nhưng đôi khi, tốt nhất là sử dụng các công cụ được hỗ trợ có sẵn cho bạn. Bất kỳ nền tảng nào cũng sẽ hỗ trợ các tệp phẳng và phân tích cú pháp XML, nhưng trên các nền tảng di động, bạn có thể muốn xem xét tuần tự hóa nhị phân nếu có thể hoặc ít nhất là tối ưu hóa XML của bạn để lưu trữ.

Sự phức tạp của cấu trúc dữ liệu.

Đây là một loại khó khăn. Cơ sở dữ liệu quan hệ rất tốt cho việc ... lưu trữ các thực thể và các mối quan hệ của chúng. Bạn có khả năng thực thi cấu trúc tốt hơn bằng cách sử dụng kho lưu trữ quan hệ so với các tệp trên hệ thống tệp. Xem xét các loại mối quan hệ giữa các thực thể của bạn cũng như tần suất bạn thay đổi chúng hoặc tìm các thực thể liên quan. Đối với các cấu trúc cực kỳ phức tạp, tôi sẽ đề nghị đi theo lộ trình cơ sở dữ liệu.

Tính di động của dữ liệu giữa nhiều dự án.

Khi nói đến tính di động, bạn nên xem xét thực tế rằng cơ sở dữ liệu tự nhiên nặng hơn các tệp. Có chi phí cài đặt và cấu hình, các cơ sở dữ liệu khác nhau sẽ có sẵn cho các nền tảng khác nhau, v.v. SQLite là một cách khá hay xung quanh vấn đề này. Tuy nhiên, khi nói đến tính di động, bạn có thể sẽ có thời gian dễ dàng hơn với các giải pháp dựa trên tệp như XML.

EDIT: Có một số mối quan tâm khác mà bạn đã đề cập về tính di động trong một trong những bình luận của bạn. Cuối cùng, bạn không muốn dữ liệu của mình được ghép quá chặt với bất kỳ loại sản phẩm hoặc tệp nào. Cuối cùng, tốt nhất là bạn có thể lưu trữ dữ liệu chứng khoán (cấp độ, kẻ thù, v.v.) ở một dạng định dạng trừu tượng nào đó (tệp được phân tách bằng tab, XML, v.v.) mà bạn có thể dễ dàng phân tích và lưu trữ trong hệ thống cơ sở dữ liệu / tệp khi biên dịch hoặc tải thời gian. Điều này có nghĩa là bạn có thể trao đổi cơ chế lưu trữ của mình theo ý thích và chỉ cần viết lại phần phân tích cú pháp.

Dữ liệu nên được truy cập thường xuyên như thế nào

Nhiều truy cập dữ liệu có nghĩa là rất nhiều I / O trừ khi bạn có một loại cơ chế lưu trữ. Cơ sở dữ liệu giữ cấu trúc trong bộ nhớ và rất tốt cho thao tác và truy xuất dữ liệu. Nếu bạn thực sự kiên trì dữ liệu liên tục, bạn có thể muốn gắn bó với cơ sở dữ liệu.

Nhiều loại dữ liệu cho cùng một ứng dụng

Khối lượng chắc chắn là một sự cân nhắc, nhưng trừ khi bạn nói về việc tồn tại hàng ngàn hoặc hàng triệu đối tượng, hệ thống tệp sẽ vẫn được chấp nhận như một giải pháp.

Loại trò chơi

Loại trò chơi bạn đang xây dựng có thể có ảnh hưởng rất lớn đến nền tảng bạn chọn. Vâng, đối với hầu hết các trò chơi một người chơi chỉ dành cho khách hàng, bạn sẽ ổn khi sử dụng giải pháp dựa trên hệ thống tệp được nén hoặc mã hóa. Tuy nhiên, nếu bạn đang nói về các trò chơi với một thành phần trực tuyến, điều đó thật điên rồ. Đi theo con đường cơ sở dữ liệu và tiết kiệm cho mình đau đầu. Hãy để máy chủ quản lý tất cả dữ liệu của bạn bằng cụm sao lưu.

Hy vọng một số thông tin phản hồi này sẽ giúp. Điều đó không có nghĩa là hoàn toàn toàn diện, và việc đưa ra quyết định cuối cùng là tùy thuộc vào bạn, nhưng bài bình luận của tôi sẽ cho bạn một số điều cần suy nghĩ.

EDIT: Có một số thời điểm mà việc sử dụng một cách tiếp cận hybdrid có rất nhiều ý nghĩa. Ví dụ: giả sử bạn đang phát triển MMORPG. Về phía khách hàng, bạn có thể lưu trữ dữ liệu được lưu trong bộ nhớ cache về những người chơi khác trong cơ sở dữ liệu không liên quan (như đã đề cập ở trên). Về phía máy chủ, bạn đang lưu trữ tất cả dữ liệu trò chơi trong cơ sở dữ liệu quan hệ để duy trì dữ liệu đó. Và một lần nữa ở phía máy khách, có lẽ bạn đang lưu trữ dữ liệu nhật ký, dữ liệu cấu hình, v.v. trong các tệp XML / phẳng để dễ truy cập hơn.

Một poster khác cũng đề cập rằng đôi khi thật tuyệt, ngay cả khi bạn đang lưu trữ dữ liệu để sản xuất trong cơ sở dữ liệu, để có cách bạn có thể sử dụng các tệp phẳng để phát triển thay vào đó ... có thể dễ dàng hơn để xóa sản phẩm khác khỏi hỗn hợp .

Gần đây tôi thấy mình bị hạn chế bởi sự cứng nhắc / khó khăn khi thêm vào cơ sở dữ liệu quan hệ. Tôi thích khám phá cơ sở dữ liệu dựa trên tài liệu (ví dụ: couchdb), vì chúng có vẻ rất phù hợp với các trò chơi, trạng thái và tính linh hoạt. Nhưng nó không thực sự thiết lập nhiều loại cơ sở dữ liệu cho một dự án nhỏ. Kết quả là, tôi đã thiết lập một hack tương tự như chỉ sử dụng trường blob nhị phân trong các trường nhất định của cơ sở dữ liệu.

Những gì tôi đang làm là sử dụng dữ liệu được mã hóa json trong cơ sở dữ liệu và trình bao bọc chuyển đổi dữ liệu thành json và sao lưu bất cứ khi nào cần. Vì vậy, một hồ sơ nhân vật cơ bản có thể trông như thế này trong cơ sở dữ liệu:

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json vẫn có thể đọc được một cách độc đáo trong cơ sở dữ liệu, vì vậy nếu bạn làm việc hoàn toàn với kim loại với sql và đôi khi cũng truy cập trực tiếp vào cơ sở dữ liệu, bạn có thể sửa đổi theo cách thủ công nếu bạn muốn.

Bây giờ, tất cả những thứ đó là một bản hack và tôi không khuyên bạn sao chép nó, nhưng đây là điểm chung: Đừng chỉ dựa vào một hệ thống. Sử dụng một cơ sở dữ liệu quan hệ và làm mờ hệ thống. Hoặc sử dụng hai loại hệ thống lưu trữ dữ liệu khác nhau (ví dụ: tệp phẳng và cơ sở dữ liệu quan hệ?), Để bạn có thể nhận được lợi ích cao nhất từ ​​cả hai. Bất kể mọi người đề xuất gì, hoặc bạn sử dụng hệ thống nào, xuống dòng bạn sẽ tìm thấy tình huống trong đó phương pháp khác sẽ hiệu quả hơn, vì vậy hãy chuẩn bị thêm một giải pháp thay thế và xem bạn sẽ đưa bạn đến đâu.

Trong gen RTS, dữ liệu trò chơi đã được lưu trữ trong các tệp.

Các đơn vị và thuộc tính đã được lưu trữ trong các tệp INI hoặc XML hoặc các định dạng dựa trên văn bản khác và các mô hình là sự pha trộn của các định dạng nhị phân hoặc thậm chí dựa trên văn bản, kết cấu và âm thanh và phương tiện khác trong các định dạng chính. Đôi khi, nó đã ở trong một thùng chứa có mã hóa thô - định dạng hỗn hợp của Westwood xuất hiện trong tâm trí. Nhưng điều này chủ yếu là obfuscation - nếu bạn nhìn vào bên trong chúng, chúng chỉ là các tệp bình thường ở các định dạng dễ xử lý.

Với sự ra đời của chơi trực tuyến, ngày càng phổ biến dữ liệu trò chơi được cung cấp sau khi cài đặt qua internet, mặc dù điều này thường được lưu trữ trên hệ thống tập tin.

Tại sao sử dụng một phương pháp lưu trữ dữ liệu?

Trong hầu hết các trường hợp, trò chơi bạn phát hành ra thế giới không cần chức năng lưu trữ dữ liệu giống như trò chơi cần trong quá trình phát triển.

Dưới đây là so sánh một số yêu cầu phát hành / phát triển: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

Lý tưởng nhất là sau đó, bạn sẽ xác định một giao diện cho mô-đun tải dữ liệu của mình và sau đó tạo nhiều phiên bản, mỗi phiên bản được điều chỉnh theo nhu cầu cụ thể.

Trong một dự án tôi đã làm việc trong nhiều năm trở lại đây, việc tải dữ liệu ở cấp độ CD đã mất quá nhiều thời gian (tắt HD cũng không tuyệt lắm). Vì vậy, tôi đã đưa ra một sau đây. Tôi đã có ba phương pháp để tải dữ liệu cấp độ: -

1. Tải bình thường - cho thời gian phát triển khi tài sản đang thay đổi
2. Phát hành trước - thực sự là một phương pháp để chuyển đổi dữ liệu bình thường thành dữ liệu tải nhanh
3. Phát hành - chỉ dữ liệu nhanh (không thể chỉnh sửa)

Điều này giảm thời gian tải từ vài phút xuống vài giây.