Cách quản lý thay đổi dữ liệu thiết kế cùng với thay đổi dữ liệu người chơi

Tôi có một trò chơi trực tuyến nơi người chơi có thể định hình thế giới theo một cách nào đó - ví dụ. Nhà ở của Ultima Online, nơi bạn có thể xây dựng nhà của mình trực tiếp trên một số phần của bản đồ thế giới. Đây là những thay đổi nên tồn tại theo thời gian như một phần của thế giới bền bỉ.

Đồng thời, nhóm thiết kế đang thêm nội dung mới và sửa đổi nội dung cũ để cải thiện và mở rộng trò chơi cho người chơi mới. Họ sẽ làm điều này trên một máy chủ phát triển trước trong quá trình thử nghiệm và sau đó phải hợp nhất công việc của họ với "công việc" của người chơi trên máy chủ trực tiếp.

Giả sử chúng tôi sửa các vấn đề thiết kế trò chơi - ví dụ. Người chơi chỉ có thể xây dựng trong các khu vực được chỉ định, vì vậy họ không bao giờ xung đột về mặt địa lý với các chỉnh sửa của nhà thiết kế - cách tốt nào để xử lý dữ liệu hoặc sắp xếp cấu trúc dữ liệu để tránh xung đột khi dữ liệu nhà thiết kế mới được hợp nhất với dữ liệu người chơi mới?

Ví dụ 1: người chơi tạo ra một loại vật phẩm mới và trò chơi gán ID 123456 cho nó. Tất cả các trường hợp của mục đó đều quay trở lại 123456. Bây giờ hãy tưởng tượng các nhà thiết kế trò chơi có một hệ thống tương tự, và một nhà thiết kế tạo ra một mục mới cũng được đánh số 123456. Làm thế nào để tránh điều này?

Ví dụ 2: ai đó tạo một mod phổ biến cung cấp cho tất cả những con rồng của bạn một giọng Pháp. Nó bao gồm một tập lệnh với một đối tượng mới được gọi là assignFrenchAccentchúng sử dụng để gán các tài sản giọng nói mới cho mỗi đối tượng rồng. Nhưng bạn sắp triển khai DLC "Napoleon vs Smaug" có một đối tượng cùng tên - làm thế nào bạn có thể làm điều này mà không gặp nhiều vấn đề về dịch vụ khách hàng?

Tôi đã nghĩ đến các chiến lược sau:

• Bạn có thể sử dụng 2 tệp / thư mục / cơ sở dữ liệu riêng biệt, nhưng sau đó các thao tác đọc của bạn phức tạp đáng kể. "Hiển thị tất cả các mục" phải thực hiện một lần đọc trên DB thiết kế và một lần đọc trên DB của người chơi (và vẫn phải phân biệt giữa 2, bằng cách nào đó.)
• Bạn có thể sử dụng 2 không gian tên khác nhau trong một cửa hàng, vd. sử dụng các chuỗi làm khóa chính và tiền tố chúng với "THIẾT KẾ:" hoặc "PLAYER:", nhưng việc tạo các không gian tên đó có thể không tầm thường và các phụ thuộc không rõ ràng. (vd dữ liệu người chơi. Nhưng thông tin đó là vô hình đối với RDBMS và các liên kết khóa ngoài sẽ vượt qua 'chia', nghĩa là tất cả các công cụ và tập lệnh cần phải hoạt động rõ ràng xung quanh nó.)
• Bạn luôn có thể làm việc trên cùng một cơ sở dữ liệu được chia sẻ trong thời gian thực, nhưng hiệu suất có thể kém và nguy cơ thiệt hại cho dữ liệu người chơi có thể được nâng cao. Nó cũng không mở rộng cho các trò chơi chạy trên nhiều máy chủ với dữ liệu thế giới khác nhau.
• ... còn ý tưởng nào khác không?

Tôi nhận thấy rằng mặc dù điều này chủ yếu là vấn đề đối với các trò chơi trực tuyến, các khái niệm cũng có thể áp dụng cho việc sửa đổi, trong đó cộng đồng tạo ra các bản mod cùng lúc với việc các nhà phát triển vá trò chơi của họ. Có chiến lược nào được sử dụng ở đây để giảm cơ hội phá vỡ mod khi các bản vá mới xuất hiện không?

Tôi cũng đã gắn thẻ này là "kiểm soát phiên bản" bởi vì ở một cấp độ, đây là - 2 nhánh phát triển dữ liệu cần hợp nhất. Có lẽ một số hiểu biết có thể đến từ hướng đó.

EDIT - một số ví dụ được thêm vào ở trên để giúp làm rõ vấn đề. Tôi bắt đầu nghĩ rằng vấn đề thực sự là một trong những không gian tên, có thể được thực hiện trong một cửa hàng thông qua các khóa tổng hợp. Điều đó đơn giản hóa chiến lược hợp nhất, ít nhất. Nhưng có thể có những lựa chọn thay thế mà tôi không thấy.

Tôi nghĩ rằng các câu trả lời đề xuất giải pháp DB đang chuyển sang một triển khai cụ thể mà không hiểu vấn đề. Cơ sở dữ liệu không làm cho việc hợp nhất trở nên dễ dàng, chúng chỉ cung cấp cho bạn một khung để lưu trữ dữ liệu của bạn. Xung đột vẫn là xung đột ngay cả khi nó ở trong DB. Và kiểm tra là một giải pháp của một người nghèo cho vấn đề - nó sẽ hoạt động, nhưng với chi phí làm tê liệt khả năng sử dụng của bạn.

Những gì bạn đang nói ở đây rơi vào mô hình phát triển phân tán của vấn đề. Bước đầu tiên tôi tin là không nghĩ người chơi và nhà thiết kế là những người sáng tạo nội dung riêng biệt. Điều đó loại bỏ kích thước nhân tạo cho vấn đề của bạn mà không ảnh hưởng đến giải pháp.

Thực tế, bạn có dòng chính của mình - phiên bản chính thức, được nhà phát triển phê duyệt. Bạn có thể (có thể) cũng có các chi nhánh khác - máy chủ trực tiếp là những người đang tích cực phát triển và chia sẻ các mod. Nội dung có thể được thêm vào bất kỳ chi nhánh. Điều quan trọng, các nhà thiết kế của bạn không có gì đặc biệt ở đây - họ chỉ là những người sáng tạo nội dung tình cờ sống trong nhà (và bạn có thể đi tìm họ và đánh họ khi họ làm hỏng).

Sau đó, chấp nhận nội dung do người dùng tạo là một vấn đề hợp nhất tiêu chuẩn. Bạn phải kéo các thay đổi của họ trở lại dòng chính, hợp nhất, sau đó đẩy ra một lần nữa hoặc kéo các thay đổi của dòng chính lên nhánh của họ và hợp nhất (để lại dòng chính 'sạch' của nội dung do người dùng tạo). Như thường lệ, kéo đến chi nhánh của bạn và sửa chữa ở đó thân thiện hơn là yêu cầu người khác kéo các thay đổi của bạn và sau đó cố gắng sửa nó từ xa về phía họ.

Khi bạn đang làm việc với loại mô hình đó, tất cả các quy trình thông thường về việc tránh xung đột hợp nhất sẽ được áp dụng. Một số điều rõ ràng hơn:

• Khuyến khích sử dụng tự do các không gian tên cho nội dung vòng rào từ một tác giả / mod / nhóm cụ thể.
• Khi nội dung cần tương tác, hãy thiết lập các quy ước gọi / sử dụng rõ ràng, quy ước đặt tên và các 'quy tắc' lỏng lẻo khác hướng dẫn phát triển để dễ dàng hợp nhất trở lại. Cung cấp các công cụ cho phép người tạo nội dung biết nếu họ tuân theo các quy tắc đó, được tích hợp lý tưởng vào chính việc tạo nội dung.
• Cung cấp các công cụ báo cáo / phân tích để phát hiện các lỗi có khả năng hợp nhất trước khi chúng xảy ra. Sửa nó hợp nhất có lẽ là rất đau. Làm cho nó để một chút nội dung cụ thể có thể được kiểm tra và đưa ra tất cả rõ ràng là sẵn sàng hợp nhất, để việc hợp nhất không gây đau đớn
• Làm cho sự hợp nhất / tích hợp của bạn mạnh mẽ. Cho phép rollback dễ dàng. Thực hiện kiểm tra nghiêm ngặt nội dung được hợp nhất: nếu không thử nghiệm, đừng hợp nhất nội dung đó! Lặp lại nội dung của họ hoặc của bạn cho đến khi hợp nhất sẽ được tiến hành sạch sẽ.
• Tránh sử dụng ID số nguyên tăng dần cho bất cứ điều gì (bạn không có cách đáng tin cậy để chuyển chúng cho người tạo). Điều đó chỉ hoạt động trong một DB vì bản thân DB là nhà cung cấp ID hợp lệ để bạn không bao giờ bị trùng lặp; tuy nhiên, nó cũng giới thiệu một điểm lỗi / tải trong hệ thống của bạn.
• Thay vào đó, hãy sử dụng GUID - chúng có chi phí cao hơn để lưu trữ, nhưng là máy cụ thể và do đó sẽ không gây ra va chạm. Ngoài ra, sử dụng mã định danh chuỗi, việc gỡ lỗi / giải quyết dễ dàng hơn nhiều, nhưng tốn kém hơn cho việc lưu trữ và so sánh.

Lưu trữ mọi thứ như một thuộc tính (hoặc trang trí) - với các điểm gắn kết. Hãy lấy một ngôi nhà mà người chơi đã thiết kế làm ví dụ:

o House: { Type = 105 } // Simple square cottage.
 o Mount point: South Wall:
  o Doodad: Chair { Displacement = 10cm }
   o Mount point: Seat:
    o Doodad: Pot Plant { Displacement = 0cm, Flower = Posies } // Work with me here :)
 o Mount point: North Wall:
  o Doodad: Table { Displacement = 1m }
    o Mount point: Left Edge:
     o Doodad: Food Bowl { Displacement = 20cm, Food = Meatballs}

Vì vậy, mỗi thực thể có thể có một hoặc nhiều điểm gắn kết - mỗi điểm gắn kết có thể chấp nhận 0 hoặc nhiều thành phần khác. Dữ liệu này sẽ được lưu trữ cùng với phiên bản mà nó đã được lưu tại đó, cùng với bất kỳ thuộc tính có liên quan nào (chẳng hạn như Dịch chuyển, v.v. trong ví dụ của tôi) - NoQuery có thể sẽ thực sự phù hợp ở đây Dữ liệu).

Mỗi thành phần sau đó sẽ cần có khả năng 'nâng cấp' dữ liệu cũ từ phiên bản trước (không bao giờ xóa các trường khỏi dữ liệu được tuần tự hóa - chỉ là 'null' chúng) - việc nâng cấp này xảy ra ngay khi được tải (sau đó sẽ được lưu lại ngay lập tức phiên bản mới nhất hiện có). Hãy nói rằng ngôi nhà của chúng tôi đã thay đổi kích thước. Mã nâng cấp sẽ tương đối tìm ra khoảng cách giữa các bức tường phía bắc và phía nam và thay đổi tương ứng các chuyển vị của tất cả các thực thể chứa trong đó. Như một ví dụ khác, bát thịt của chúng tôi có thể loại bỏ trường 'Thực phẩm', và thay vào đó, hãy lấy 'Giống' (Thịt) và 'Công thức' (Bóng). Kịch bản nâng cấp sẽ biến 'Meat Balls' thành 'Meat', 'Balls'. Mỗi thành phần cũng nên biết cách xử lý các thay đổi đối với các điểm gắn kết - ví dụ:

Tất cả điều này để lại chính xác một vấn đề mở: điều gì xảy ra nếu hai đối tượng đụng độ với nhau (không phải điểm chứa của chúng - điểm gắn kết bảo vệ bạn khỏi điều đó)? Sau khi nâng cấp, bạn nên kiểm tra va chạm và cố gắng giải quyết chúng (bằng cách di chuyển mọi thứ ra xa, giống như SAT). Nếu bạn không thể tìm ra cách giải quyết vụ va chạm, hãy loại bỏ một trong các vật thể và đặt nó vào thùng rác - nơi họ có thể mua những vật phẩm bị loại bỏ này (miễn phí) hoặc bán chúng (với giá đầy đủ); và rõ ràng thông báo cho người chơi rằng bản nâng cấp đã phá vỡ một số bố cục của họ - có thể với tính năng 'phóng to' để họ có thể thấy vấn đề.

Cuối cùng, bạn nên để lại những thay đổi phức tạp trong tay người chơi (không nhanh) vì không thuật toán nào có thể giải thích được tính thẩm mỹ - bạn chỉ có thể đưa ra bối cảnh của người chơi về vị trí của vật phẩm đó (để họ có thể nhớ, không chỉ đáp ứng với tất cả những vật phẩm này trong hầm chứa của chúng và không biết chúng ở đâu).

Tôi đang cố gắng liên kết điều này với thứ gì đó mà tôi hiểu, vì vậy tôi đang nghĩ về Minecraft ngay bây giờ. Tôi đang hình dung một máy chủ trực tiếp với những người chơi thực hiện thay đổi trong thời gian thực trong khi các nhà phát triển đang chạy trên một máy chủ thử nghiệm sửa / tạo nội dung mới.

Câu hỏi của bạn gần giống như 2 câu hỏi độc đáo:

1. Làm thế nào để đảm bảo rằng ID đối tượng là duy nhất
2. Làm thế nào để đảm bảo rằng không gian tên tập lệnh không va chạm

Tôi sẽ thử giải quyết # 1 thông qua một hệ thống tham chiếu tạm thời. Chẳng hạn, khi một đối tượng mới được tạo bởi ai đó, nó có thể được đánh dấu là không ổn định hoặc tạm thời. Tôi sẽ tưởng tượng rằng tất cả nội dung mới được tạo trên máy chủ thử nghiệm sẽ được đánh dấu là không ổn định (mặc dù nó cũng có thể tham chiếu nội dung không bay hơi).

Khi bạn sẵn sàng đưa nội dung mới vào máy chủ trực tiếp, quy trình nhập của bạn sẽ tìm thấy các đối tượng dễ bay hơi và gán cho chúng ID đối tượng máy chủ trực tiếp được đặt trong đá. Điều này khác với nhập / hợp nhất thẳng vì bạn cần có thể tham chiếu các đối tượng không bay hơi hiện có nếu bạn cần sửa hoặc cập nhật chúng.

Đối với # 2, có vẻ như bạn thực sự cần phải có một số mức độ chuyển đổi tập lệnh trung gian có thể băm tên hàm thành một không gian tên duy nhất. I E

assignFrenchAccent

Trở thành

_Z11assignFrenchAccent

Nếu các tệp cho dữ liệu là văn bản trái ngược với nhị phân và các nhà thiết kế và người chơi đang sửa đổi các khu vực khác nhau, bạn có thể thử hợp nhất SVN.

Tôi nghĩ rằng một cơ sở dữ liệu / hệ thống tập tin được nhân rộng trên các môi trường với quy trình 'kiểm tra' là tốt nhất.

Vì vậy, bất cứ khi nào một nhà thiết kế muốn thực hiện một số sửa đổi cho thế giới, anh ta sẽ kiểm tra / khóa tất cả các tài sản mà anh ta muốn tạo / sửa đổi trên tất cả các bản sao của cơ sở dữ liệu (phát triển và sản xuất), vì vậy không người chơi hay nhà thiết kế nào có thể sửa đổi nó . Sau đó, anh ta sẽ làm việc trên cơ sở dữ liệu phát triển cho đến khi thiết kế mới kết thúc và tại thời điểm đó, các thay đổi sẽ được hợp nhất với cơ sở dữ liệu sản xuất và các tài sản đó sẽ được đăng ký / mở khóa trong tất cả các môi trường.

Chỉnh sửa trình phát sẽ hoạt động theo cùng một cách, ngoại trừ vai trò cơ sở dữ liệu / hệ thống tệp sẽ bị đảo ngược - chúng hoạt động trên cơ sở dữ liệu sản xuất và tất cả các bản cập nhật được tải lên dev khi hoàn tất.

Việc khóa tài sản có thể được giới hạn ở các thuộc tính mà bạn muốn đảm bảo không có xung đột: trong ví dụ 1, bạn sẽ khóa ID 123456ngay khi người chơi bắt đầu tạo nó, vì vậy các nhà phát triển sẽ không được gán ID đó. Trong ví dụ 2, các nhà phát triển của bạn sẽ khóa tên tập lệnh assignFrenchAccenttrong quá trình phát triển, do đó, người chơi sẽ phải chọn một tên khác khi phát triển sửa đổi của mình (sự phiền toái nhỏ đó có thể được giảm bớt bằng cách đặt tên, nhưng bản thân nó sẽ không tránh được xung đột trừ khi bạn đưa ra mỗi người dùng / nhà phát triển một không gian tên cụ thể và sau đó bạn sẽ gặp vấn đề tương tự với việc quản lý các không gian tên). Điều này không có nghĩa là tất cả sự phát triển sẽ phải đọc từ một cơ sở dữ liệu trực tuyến, nhưng tất cả những gì bạn yêu cầu từ cơ sở dữ liệu đó trong các ví dụ này là tên đối tượng, vì vậy hiệu suất không phải là vấn đề.

Về mặt triển khai, có một bảng duy nhất với tất cả các khóa và trạng thái tài sản (có sẵn, bị khóa từ dev, bị khóa từ prod) được đồng bộ hóa / có thể truy cập trong thời gian thực trên các môi trường là đủ. Một giải pháp phức tạp hơn sẽ triển khai một hệ thống Kiểm soát Phiên bản hoàn chỉnh - bạn có thể sử dụng một hệ thống hiện có như CVS hoặc SVN nếu tất cả tài sản của bạn đều nằm trong một hệ thống tệp.

Tôi nghĩ vấn đề ở đây là chấp nhận sạch sẽ trách nhiệm của bạn. 1) Máy chủ cho biết những gì hiện được chấp nhận và API để truy cập. Cơ sở dữ liệu đang được sửa đổi, theo các quy tắc nhất định. 2) Người tạo được phép tạo nội dung, nhưng nó phải có thể phát được sau khi cập nhật. Đây hoàn toàn là trách nhiệm của bạn: mọi bản cập nhật phải có khả năng phân tích cấu trúc dữ liệu cũ tốt nhất là sạch sẽ và dễ dàng nhất có thể.

Ý tưởng đỉnh điểm có giá trị nếu bạn quan tâm đến việc theo dõi các vật phẩm và vị trí độc đáo bên trong cấu trúc dễ uốn, đặc biệt nếu chúng tôi chấp nhận rằng toàn bộ cấu trúc 'nhà' của người chơi sẽ trải qua một thay đổi lớn và bạn muốn giữ điều đó công cụ trang trí nhỏ trong tủ khóa tương ứng của họ.

Đây là một vấn đề rất phức tạp, chúc may mắn! Có lẽ không tồn tại bất kỳ một câu trả lời.

Tôi không nghĩ rằng điều này có vấn đề lớn khi bạn đang thực hiện nó.

Tôi sẽ ghi đè lên các mod do người dùng tạo, với một cảnh báo rằng "Mod X có thể không hoạt động chính xác với phiên bản này", hãy để nó cho người tạo mod thay đổi công việc của họ. Tôi không nghĩ rằng đây là một kỳ vọng không thực tế rằng các bản cập nhật có thể vô hiệu hóa một số mod nhất định.

Tương tự đối với nội dung do người dùng tạo, chỉ cần tạo bản sao lưu và ghi đè.

Tôi không có kinh nghiệm thực tế trong việc này, chỉ đưa ra gợi ý.