Thành thật mà nói:tất cả chúng ta đều thích chơi trò chơi, đặc biệt là trên máy tính của mình. Cho đến khi Internet trở nên phổ biến, hầu hết chúng ta đều chơi trò chơi máy tính một mình, thường là chống lại các đối thủ AI. Nó rất thú vị, nhưng ngay sau khi bạn nhận ra cách thức hoạt động của cơ chế gameplay, trò chơi đã mất đi phần lớn sự kỳ diệu của nó.
Sự phát triển của Internet chuyển trò chơi trực tuyến. Giờ đây, chúng ta có thể đấu với đối thủ là con người và kiểm tra kỹ năng của mình trước chúng. Không còn chơi vẹt nữa!
Sau đó, các trò chơi trực tuyến nhiều người chơi (MMO) xuất hiện và thay đổi mọi thứ. Hàng nghìn người chơi đã tìm thấy mình trong cùng một vũ trụ trò chơi, cạnh tranh tài nguyên, đàm phán, giao dịch và chiến đấu. Để làm cho những trò chơi như vậy trở nên khả thi, cần phải có một cấu trúc cơ sở dữ liệu có thể lưu trữ tất cả các thông tin liên quan.
Trong bài viết này, chúng tôi sẽ thiết kế một mô hình kết hợp các yếu tố phổ biến nhất được tìm thấy trong các trò chơi MMO. Chúng ta sẽ thảo luận về cách sử dụng nó, những hạn chế của nó và những cải tiến có thể có.
Giới thiệu về Mô hình Dữ liệu cho Trò chơi MMO
Có rất nhiều trò chơi MMO rất phổ biến hiện nay, và chúng liên quan đến tất cả các loại kịch bản. Ở đây tôi sẽ tập trung vào các trò chơi chiến lược như Ogame , Travian , Sparta : War of Empires và Imperia Online . Những trò chơi này thiên về lập kế hoạch, xây dựng và lập chiến lược, chứ không thiên về hành động trực tiếp.
Các trò chơi MMO lấy bối cảnh ở các vũ trụ khác nhau, khác nhau về mặt hình ảnh và sử dụng ít nhiều các tùy chọn lối chơi khác nhau. Tuy nhiên, một số ý tưởng vẫn giống nhau. Người chơi cạnh tranh cho các vị trí, chiến đấu cho họ và hình thành liên minh với (và chống lại) những người chơi khác. Họ xây dựng cấu trúc, thu thập tài nguyên và nghiên cứu công nghệ. Họ xây dựng các đơn vị (chẳng hạn như chiến binh, xe tăng, thương nhân, v.v.) và sử dụng chúng để giao dịch với đồng minh hoặc chiến đấu với đối thủ. Tất cả những điều đó cần được hỗ trợ trong cơ sở dữ liệu của chúng tôi.
Chúng ta có thể coi những trò chơi này là trò chơi hội đồng trực tuyến với nhiều ô vuông được lập chỉ mục. Mỗi ô vuông có thể có nhiều hành động khác nhau được kết hợp với nó; một số hành động sẽ bao gồm nhiều ô vuông - ví dụ:khi chúng tôi di chuyển các đơn vị hoặc tài nguyên từ vị trí này sang vị trí khác.
Cơ sở dữ liệu được chia thành năm lĩnh vực chính:
-
Players / Users -
Alliances -
Locations and Structures -
Research and Resources -
Units
Bảy bảng chưa nhóm còn lại có liên quan đến các đơn vị và mô tả vị trí đơn vị cũng như các chuyển động trong trò chơi. Chúng tôi sẽ xem xét từng lĩnh vực này chi tiết hơn, bắt đầu với Người chơi và Liên minh .
Người chơi và Liên minh
Không nghi ngờ gì nữa, người chơi là phần quan trọng nhất của bất kỳ trò chơi nào.
player bảng chứa danh sách tất cả người chơi đã đăng ký tham gia vào một phiên bản trò chơi. Chúng tôi sẽ lưu trữ tên người dùng, mật khẩu và tên hiển thị của người chơi. Chúng sẽ được lưu trữ trong user_name , password và nickname các thuộc tính tương ứng.
Người dùng mới sẽ cần cung cấp địa chỉ email trong khi đăng ký. Một mã xác nhận sẽ được tạo và gửi cho họ, họ sẽ trả lời. Chúng tôi sẽ cập nhật confirmation_date khi người dùng xác minh địa chỉ email của họ. Vì vậy, bảng này có ba khóa duy nhất:user_name , nickname và email .
Mỗi khi người dùng đăng nhập, một bản ghi mới sẽ được thêm vào login_history bàn. Tất cả các thuộc tính trong bảng này là tự giải thích. logout_time là cụ thể. Nó có thể là NULL khi phiên hiện tại của người dùng đang hoạt động hoặc khi người dùng thoát khỏi trò chơi (mà không đăng xuất) do sự cố kỹ thuật. Trong login_data , chúng tôi sẽ lưu trữ các chi tiết đăng nhập như vị trí địa lý, địa chỉ IP của người chơi cũng như thiết bị và trình duyệt mà họ sử dụng.
Hầu hết các trò chơi MMO cho phép chúng tôi hợp tác với những người chơi khác. Một trong những hình thức hợp tác tiêu chuẩn của người chơi là liên minh. Người chơi chia sẻ “dữ liệu cá nhân” trong trò chơi của họ (trạng thái trực tuyến, kế hoạch, vị trí của các thành phố và thuộc địa của họ, v.v.) với những người khác để hưởng lợi từ các hành động của đồng minh và vì điều đó.
alliance bảng lưu trữ thông tin cơ bản về liên minh trò chơi. Mỗi người có một alliance_name duy nhất mà chúng tôi sẽ lưu trữ. Chúng tôi cũng sẽ có một trường, date_founded , cửa hàng khi liên minh được thành lập. Nếu một liên minh bị giải tán, chúng tôi sẽ lưu trữ thông tin đó trong date_disbanded thuộc tính.
alliance_member bảng liên quan đến người chơi với các liên minh. Người chơi có thể tham gia và rời khỏi cùng một liên minh nhiều hơn một lần. Do đó, player_id - alliance_id cặp không phải là một khóa duy nhất. Chúng tôi sẽ giữ thông tin về thời điểm người chơi tham gia liên minh và thời điểm (nếu) họ rời đi trong date_from và date_to lĩnh vực. membership_type_id thuộc tính là một tham chiếu đến membership_type từ điển; nó lưu trữ cấp độ quyền hiện tại của người chơi trong liên minh.
Quyền của người chơi trong liên minh có thể thay đổi theo thời gian. membership_actions , membership_type và actions_allowed các bảng cùng nhau xác định tất cả các quyền có thể có cho các thành viên liên minh. Mô hình này không cho phép người chơi xác định các cấp quyền của riêng họ trong liên minh, nhưng điều đó có thể được thực hiện đủ dễ dàng bằng cách thêm các bản ghi mới trong membership_type từ điển và lưu trữ thông tin về những liên minh mà chúng có liên quan.
Tóm lại:các giá trị được lưu trữ trong các bảng này được chúng tôi xác định trong quá trình thiết lập ban đầu; chúng sẽ chỉ thay đổi nếu chúng tôi giới thiệu các tùy chọn mới.
membership_history bảng lưu trữ tất cả dữ liệu liên quan đến vai trò hoặc quyền của người chơi trong liên minh, bao gồm phạm vi khi các quyền này hợp lệ. (Ví dụ:anh ta có thể có quyền "mới làm quen" trong một tháng và sau đó là "tư cách thành viên đầy đủ" kể từ thời điểm đó.) date_to thuộc tính NULLable vì quyền hiện đang hoạt động vẫn chưa kết thúc.
membership_actions từ điển chứa danh sách mọi hành động mà người chơi có thể thực hiện trong liên minh. Mỗi hành động có action_name riêng của nó và logic trò chơi được xây dựng xung quanh những cái tên này. Chúng tôi có thể mong đợi các giá trị như “xem danh sách thành viên” , “xem trạng thái của thành viên” và “gửi tin nhắn” tại đây.
membership_type từ điển chứa các tên riêng của các nhóm hành động được sử dụng trong trò chơi. actions_allowed bảng chỉ định các hành động cho các loại thành viên. Mỗi hành động chỉ có thể được gán cho một loại một lần. Do đó, membership_action - membership_type cặp tạo thành khóa duy nhất cho bảng này.
Vị trí và cấu trúc
Địa điểm trò chơi là khu vực mà người chơi thu thập tài nguyên và xây dựng các cấu trúc và đơn vị. Một số trò chơi có phạm vi vị trí có thể được xác định trước, trong khi những trò chơi khác có thể cho phép người dùng xác định vị trí của riêng họ.
Trong không gian 3D, các vị trí có thể được xác định bằng tọa độ [x:y:z]. Nếu một trò chơi có phạm vi được xác định trước, trò chơi đó có thể không cho phép người chơi sử dụng bất kỳ vị trí nào ngoài phạm vi [0:1000] cho cả ba trục, vì vậy chúng tôi bị giới hạn trong khoảng không gian 1000 * 1000 * 1000.
Mặt khác, có thể chúng tôi muốn cho phép người chơi nhập tọa độ chính xác của vị trí mới của họ - ví dụ:[1001:2073:4] - và chúng tôi muốn trò chơi xử lý nó cho họ.
Chúng tôi sẽ giữ một danh sách tất cả các vị trí được sử dụng trong một phiên bản trò chơi của chúng tôi ở location bàn. Mỗi địa điểm đều có tên riêng, nhưng những cái tên đó không phải là duy nhất. Mặt khác, coordinates thuộc tính chỉ được chứa các giá trị duy nhất. Tọa độ vị trí được lưu trữ dưới dạng giá trị văn bản, vì vậy chúng tôi có thể lưu trữ tọa độ cho trò chơi 3D dưới dạng [112:72:235]. Tọa độ cho trò chơi 2D có thể được lưu trữ dưới dạng <1102:98>.
Trong một số trò chơi, các địa điểm sẽ có một số ô vuông được sử dụng để đặt các cấu trúc hoặc đơn vị. Chúng tôi sẽ giữ thông tin đó theo thứ nguyên dimension thuộc tính, là một trường văn bản. Thứ nguyên có thể đơn giản là số ô vuông trong lưới 2D hoặc 3D. player_id thuộc tính lưu trữ thông tin về chủ sở hữu hiện tại của vị trí đó. Nó có thể là KHÔNG khi các vị trí được xác định trước và người chơi cạnh tranh để chiếm chúng.
structure bảng chứa danh sách tất cả các cấu trúc mà chúng ta có thể xây dựng tại các địa điểm trò chơi khác nhau. Các cấu trúc đại diện cho những cải tiến cho phép chúng tôi sản xuất các đơn vị tốt hơn, thực hiện các loại nghiên cứu mới, sản xuất nhiều tài nguyên hơn, v.v. Mỗi cấu trúc được sử dụng trong trò chơi đều có structure_name độc đáo của riêng nó . Một số structure_name có thể có các giá trị là “trang trại”, “mỏ quặng”, “nhà máy năng lượng mặt trời” và “trung tâm nghiên cứu”.
Chúng tôi có thể mong đợi mỗi cấu trúc được nâng cấp nhiều lần, vì vậy chúng tôi cũng sẽ lưu trữ thông tin về cấp độ hiện tại của cấu trúc đó. Mỗi lần nâng cấp sẽ cải thiện kết quả đầu ra của cấu trúc, do đó, nó tạo ra nhiều tài nguyên hơn hoặc cho phép chúng tôi sử dụng các tính năng mới trong trò chơi. Chúng tôi không thể biết trước mức nâng cấp tối đa, vì vậy, chúng tôi sẽ xác định tất cả những thứ liên quan đến cấp (chi phí, thời gian nâng cấp và sản xuất) bằng các công thức. Tất cả các công thức được lưu trữ trong cơ sở dữ liệu là cốt lõi của cơ chế trò chơi và việc điều chỉnh chúng là rất quan trọng đối với sự cân bằng của trò chơi và lối chơi nói chung.
Đó cũng là trường hợp của upgrade_time_formula thuộc tính. Giá trị mẫu cho trường này là “
Trong hầu hết các trường hợp, có những yêu cầu phải được đáp ứng trước khi người chơi thực hiện một số hành động nhất định. Có thể chúng ta cần hoàn thành một lượng nghiên cứu xác định trước khi có thể xây dựng các cấu trúc mới hoặc ngược lại. Chúng tôi sẽ lưu trữ mức nghiên cứu cần thiết để xây dựng cấu trúc trong prerequisite_research bàn. Các mối quan hệ và cấp độ cấu trúc cần thiết để bắt đầu các nghiên cứu khác nhau được lưu giữ trong prerequisite_structure bàn. Trong cả hai bảng, các khóa ngoại research_id và structure_id được ghép nối để tạo thành một khóa duy nhất. level_required thuộc tính là giá trị duy nhất.
Hai bảng này, prerequisite_research và prerequisite_structure , cũng là cốt lõi của trò chơi.
Đối với mỗi cấu trúc, chúng tôi sẽ xác định danh sách các điều kiện tiên quyết:các cấu trúc khác và cấp độ tối thiểu của chúng mà người chơi phải bắt đầu xây dựng. Chúng tôi sẽ lưu trữ dữ liệu này trong structure_required bàn. Đây, structure_id đại diện cho cấu trúc mà chúng tôi muốn xây dựng; structure_required_id là tham chiếu đến (các) cấu trúc điều kiện tiên quyết và level là mức bắt buộc.
structure_built bảng lưu trữ thông tin về các cấp cấu trúc hiện tại trên một vị trí nhất định. upgrade_ongoing thuộc tính sẽ chỉ được đặt nếu quá trình nâng cấp hiện đang diễn ra, trong khi upgrade_end_time thuộc tính sẽ chứa dấu thời gian sau khi nâng cấp hoàn tất.
structure_formula bảng liên quan đến cấu trúc và tài nguyên. Cặp khóa ngoại của bảng này tạo thành khóa duy nhất của nó. Bảng này cũng có hai thuộc tính văn bản chứa công thức với tham số upgrade_time_formula . Chúng tôi cần chúng bởi vì chúng tôi phải xác định các nguồn lực được sử dụng để xây dựng mỗi cấu trúc. Chúng tôi cũng cần xác định sản xuất tài nguyên sau khi nâng cấp, nếu cấu trúc tạo ra bất kỳ tài nguyên nào (tức là mỏ quặng sẽ sản xuất
Nghiên cứu và Tài nguyên
Nghiên cứu (hoặc công nghệ) trong trò chơi thường là cần thiết để tạo ra các tính năng khác. Nếu không có các cấp độ nghiên cứu nhất định, không thể xây dựng các cấu trúc hoặc loại đơn vị mới. Nghiên cứu cũng có thể có những yêu cầu riêng. Một trong những cấp độ phổ biến nhất là cấp độ của một cấu trúc nhất định, thường được gọi là “phòng nghiên cứu”. Hoặc có lẽ người chơi cần phải hoàn thành một mức độ nghiên cứu nhất định trước khi họ có thể bắt đầu nghiên cứu mới. Tất cả những yêu cầu này sẽ được xử lý trong phần này. Dưới đây, chúng ta có thể tìm thấy mô hình dữ liệu cho Nghiên cứu và Tài nguyên:
research bảng chứa danh sách tất cả các hành động nghiên cứu có thể có trong trò chơi của chúng tôi. Nó sử dụng cùng một logic với structure bàn. research_name thuộc tính là khóa duy nhất của bảng, trong khi upgrade_time_formula trường chứa biểu diễn văn bản của công thức yêu cầu thời gian nghiên cứu, với upgrade_formula được lưu trữ trong research_formula bảng.
Đối với cấu trúc, chúng tôi sẽ xác định danh sách tất cả các nghiên cứu khác và các cấp độ của chúng phải được hoàn thành trước khi chúng tôi có thể bắt đầu một loại nghiên cứu khác. Chúng tôi sẽ lưu trữ dữ liệu này trong research_required bảng, trong đó research_id đại diện cho nghiên cứu mong muốn; research_required_id là tham chiếu đến nghiên cứu tiên quyết và level là mức bắt buộc.
Nghiên cứu liên quan đến từng người chơi và đối với từng người chơi - xem lại ch cặp, chúng tôi phải lưu trữ cấp độ nghiên cứu hiện tại của người chơi và mọi trạng thái nâng cấp đang diễn ra. Chúng tôi sẽ lưu trữ thông tin này bằng cách sử dụng research_level bảng giống như cách mà chúng tôi đã sử dụng structure_built bảng.
Các tài nguyên như gỗ, quặng, đá quý và năng lượng được khai thác hoặc thu thập và sử dụng sau đó để xây dựng các công trình kiến trúc và các cải tiến khác. Chúng tôi sẽ lưu trữ danh sách tất cả các tài nguyên trong trò chơi trong resource từ điển. Thuộc tính duy nhất ở đây là resource_name và nó cũng là khóa duy nhất của bảng.
Để theo dõi số lượng tài nguyên hiện tại trên mỗi vị trí, chúng tôi sẽ sử dụng resources_on_location bàn. Một lần nữa, một cặp khóa ngoại (resource_id và location_id ) tạo thành khóa duy nhất của bảng, trong khi number thuộc tính lưu trữ các giá trị tài nguyên hiện tại.
Đơn vị và Chuyển động
Các nguồn lực được sử dụng để sản xuất các đơn vị. Các đơn vị có thể được sử dụng để vận chuyển tài nguyên, tấn công người chơi khác hoặc nói chung là cướp bóc và đốt cháy.
Danh sách các loại đơn vị được sử dụng trong trò chơi của chúng tôi được lưu trữ trong unit từ điển chỉ có một giá trị, unit_name; thuộc tính đó là khóa duy nhất của bảng này. Một số đơn vị trò chơi phổ biến là “kiếm sĩ”, “tàu tuần dương”, “tàu chiến”, “máy bay phản lực”, “xe tăng”, v.v.
Chúng ta cần mô tả từng đơn vị với các đặc điểm cụ thể. Danh sách tất cả các đặc điểm có thể có được lưu trữ trong characteristic từ điển. characteristic_name trường chứa một giá trị duy nhất. Các giá trị trong trường này có thể bao gồm:“tấn công”, “phòng thủ” và “điểm trúng đích”. Chúng tôi sẽ chỉ định các đặc điểm cho các đơn vị bằng cách sử dụng unit_characteristic quan hệ. Cặp khóa ngoại của unit_id và characteristic_id tạo thành khóa duy nhất của bảng. Chúng tôi sẽ chỉ sử dụng một thuộc tính, value , để lưu trữ giá trị mong muốn.
research_unit bảng chứa danh sách tất cả các hoạt động nghiên cứu phải hoàn thành trước khi chúng tôi có thể bắt đầu sản xuất một loại đơn vị nhất định. unit_cost bảng xác định các nguồn lực cần thiết để sản xuất một đơn vị duy nhất. Cả hai bảng đều có các khóa duy nhất bao gồm cặp khóa ngoại (research_id hoặc resources_id kết hợp với unit_id ) và một trường giá trị (cost và level_required ).
Và bây giờ, phần thú vị. Sản xuất rất thú vị, nhưng di chuyển các đơn vị xung quanh và thực hiện hành động thậm chí còn tốt hơn. Chúng tôi đã giới thiệu unit nhưng chúng tôi sẽ giữ nó ở đây vì nó liên quan như thế nào với các bảng khác.
Các đơn vị đóng quân trên một địa điểm hoặc họ đang di chuyển giữa các địa điểm. Thêm player_id trường xác định ai sở hữu vị trí hoặc nhóm đang di chuyển giữa các vị trí.
Nếu các đơn vị chỉ đóng quân tại một vị trí nhất định, chúng tôi sẽ lưu trữ vị trí đó và số lượng các đơn vị đóng quân ở đó. Để làm như vậy, chúng tôi sẽ sử dụng units_on_location bảng.
Khi các đơn vị không đóng quân, chúng sẽ di chuyển xung quanh. Chúng tôi sẽ cần lưu trữ điểm khởi hành và điểm đến của họ. Ngoài ra, chúng ta cần xác định các hành động có thể xảy ra trong quá trình chuyển động. Tất cả các hành động như vậy được lưu trữ trong movement_type từ điển. type_name thuộc tính duy nhất trong khi allows_wait thuộc tính xác định xem một hành động có cho phép đợi ở điểm đích hay không.
Chúng tôi có thể di chuyển một loại đơn vị, nhưng trong hầu hết mọi trường hợp, chúng tôi sẽ di chuyển nhiều đơn vị thuộc một số loại đơn vị khác nhau. Nhóm đó sẽ chia sẻ dữ liệu chung và chúng tôi sẽ lưu trữ chúng trong group_movement bàn. Trong bảng này, chúng tôi sẽ xác định các mục sau:
- trình phát đã bắt đầu hành động đó
- loại hành động
- điểm bắt đầu
- điểm đến
-
arrival_timetại điểm đến -
return_timeđến điểm xuất phát -
wait_timetại điểm đến
return_time thuộc tính có thể là NULL nếu đây là hành trình một chiều và wait_time được xác định bởi người chơi. Các đơn vị thuộc một nhóm được xác định bởi các giá trị được lưu trữ trong units_in_group bàn. Cặp khóa ngoại của units_id và group_moving_id tạo thành khóa duy nhất của bảng. Số lượng các đơn vị cùng loại trong một nhóm được xác định trong number thuộc tính.
Mỗi chuyển động có thể vận chuyển tài nguyên từ vị trí này đến vị trí khác. Do đó, chúng tôi sẽ xác định mối quan hệ nhiều-nhiều giữa group_movement và resources những cái bàn. Bên cạnh các khóa chính và khóa ngoài, resources_in_group bảng chỉ chứa number thuộc tính. Trường này lưu trữ lượng tài nguyên mà người chơi di chuyển từ điểm xuất phát đến điểm đến của họ.
Trong hầu hết các trường hợp, người chơi có thể kêu gọi người khác tham gia cuộc phiêu lưu của mình. Để hỗ trợ điều đó, chúng tôi sẽ sử dụng hai bảng:allied_movement và allied_groups . Một người chơi sẽ bắt đầu hành động chung và điều đó sẽ tạo ra một bản ghi mới trong allied_movement bàn. Tất cả các nhóm đơn vị tham gia vào một hành động đồng minh được xác định bởi các giá trị được lưu trữ trong allied_groups bàn. Mỗi nhóm chỉ có thể được chỉ định cho một hành động đồng minh một lần, do đó, các khóa ngoại tạo thành khóa duy nhất của bảng này.
Mô hình này cho chúng ta cấu trúc cơ bản cần thiết để xây dựng một trò chơi chiến lược MMO. Nó chứa các tính năng trò chơi quan trọng nhất:địa điểm, cấu trúc, tài nguyên, nghiên cứu và đơn vị. Nó cũng liên quan đến chúng, cho phép chúng tôi xác định các điều kiện tiên quyết trong cơ sở dữ liệu và lưu trữ hầu hết logic trò chơi trong cơ sở dữ liệu.
Sau khi các bảng này được điền, hầu hết logic trò chơi được xác định và chúng tôi không mong đợi các giá trị mới được thêm vào. Hầu hết mọi bảng đều có một giá trị khóa duy nhất, tên đặc điểm hoặc cặp khóa ngoại. Việc thay đổi đặc điểm của đơn vị và công thức sản xuất / chi phí sẽ cho phép chúng tôi thay đổi cân bằng trò chơi trong lớp cơ sở dữ liệu.
Bạn sẽ thay đổi mô hình này như thế nào? Bạn thích gì, và bạn sẽ làm gì khác đi? Hãy cho chúng tôi biết trong phần bình luận!
