Cách quản lý các phụ thuộc giữa bản đồ và đơn vị

11

Tôi có một chiến lược dựa trên gạch 2D trong các tác phẩm. Tôi đang đi lang thang làm thế nào để xử lý mối quan hệ giữa bản đồ và các đơn vị trên bản đồ.

Nếu có tọa độ ô, tôi sẽ cần có thể đặt đơn vị đứng trên nó, nếu có. Đồng thời, nếu được cung cấp một đơn vị, tôi sẽ muốn có thể có được tọa độ của đơn vị đó.

Tôi đã thấy hai giải pháp cho vấn đề này. Giải pháp đầu tiên là có các đơn vị lưu trữ tọa độ và tham chiếu đơn vị lưu trữ bản đồ trong các ô của nó. Điều này tạo ra sự phụ thuộc theo chu kỳ giữa bản đồ và đơn vị. Tôi cần đảm bảo rằng bản đồ mà bất kỳ đơn vị nào được giữ đồng bộ nếu đơn vị di chuyển.

Giải pháp thứ hai là chỉ các đơn vị theo dõi tọa độ của chúng. Để biết một ô có chứa một đơn vị không và để có được đơn vị đó, tôi sẽ lặp qua toàn bộ đơn vị đơn vị tôi tìm thấy một đơn vị có tọa độ khớp. Điều đó có được sự phụ thuộc của sự phụ thuộc theo chu kỳ, nhưng nó làm mất tính chất O (1), giải pháp đầu tiên có được khi tìm kiếm các đơn vị từ bản đồ. Điều này có thể bổ sung vì tôi muốn có thể quét bản đồ thường xuyên để tìm những thứ như tìm đường, xác định phạm vi di chuyển và tìm mục tiêu hợp lệ cho một đơn vị nhất định.

Tôi cũng không thể lưu trữ các đơn vị trong bản đồ (hoặc tôi có thể?). Các đơn vị được liên kết với "quân đội", người chơi hoặc AI. Một đội quân sẽ có thể dễ dàng truy cập và lặp lại trên tất cả các đơn vị của nó.

Vì đây có vẻ là một vấn đề phổ biến trong các trò chơi chiến lược, có bất kỳ mẫu nào khác ngoài hai mẫu tôi đã mô tả để quản lý các mối quan hệ đơn vị / bản đồ không?

tiles maps character

— AJM
nguồn

3

Nó không phải là một mẫu phổ biến nhưng thế giới cơ sở dữ liệu quan hệ cung cấp một cách thứ ba: sử dụng cấu trúc dữ liệu có nhiều khóa. Ở dạng bảng, nó có thể trông như thế này:

Unit id    Location
-------------------
  1309     13,15
  2357      7,93
  8552      7,93

Bạn muốn có thể hỏi, đơn vị 2357 ở đâu? và lấy lại 7.93. Bạn cũng muốn có thể hỏi, những gì ở vị trí 7,93? và lấy lại 2357 và 8552. Có các cấu trúc dữ liệu cho phép nhiều khóa để tìm kiếm mọi thứ. Bạn có thể lưu trữ bên ngoài các đơn vị và bên ngoài bản đồ nếu bạn muốn loại bỏ các phụ thuộc.

Tuy nhiên, trên thực tế, việc lưu trữ vị trí trong mỗi đơn vị là phổ biến hơn và sau đó ở bên sử dụng cấu trúc dữ liệu phân vùng không gian cho bạn biết đơn vị nào ở trong một khu vực nhất định. Vì nó là một cấu trúc riêng biệt, các vùng không phải là không gian lưới; chúng có thể là những khu vực lớn hơn.

Tôi khuyên bạn nên làm bất cứ điều gì dễ dàng nhất (giải pháp thứ hai của bạn) và sau đó nếu đó là vấn đề về hiệu suất, bạn có thể thêm phân vùng không gian để giúp tra cứu nhanh hơn.

— amitp
nguồn

Vì vậy, cấu trúc dữ liệu phân vùng không gian mà bạn đề cập có thể chỉ là bản đồ (trong trường hợp của tôi rõ ràng là một lưới các ô xếp hình 2D). Tôi giả sử khi một đơn vị di chuyển (hoặc được thêm hoặc xóa) Tôi vẫn cần cập nhật cả cấu trúc phân chia đơn vị và không gian để giữ chúng đồng bộ. Có lẽ đó là một trong những điều tôi sẽ phải sống với?

— AJM

1

Vâng, bản đồ là phân vùng không gian hạt mịn nhất mà bạn sẽ sử dụng. Danh sách toàn cầu của tất cả các đơn vị là phân vùng hạt thô nhất. ;) Bạn chỉ cần cập nhật phân vùng trước khi sử dụng. Nếu bạn đang sử dụng nó mọi lúc bạn có thể muốn cập nhật nó mỗi khi thiết bị được di chuyển. Tuy nhiên, nếu bạn chỉ sử dụng nó cho một số giai đoạn của logic cập nhật, bạn có thể đi qua danh sách đơn vị trong một lần và tính toán cấu trúc dữ liệu phân vùng, sau đó loại bỏ nó khi bạn hoàn thành. Bằng cách đó, bạn không cần phải giữ chúng đồng bộ mọi lúc.

— amitp

5

Chà, trừ khi bạn vài nghìn đơn vị cho mỗi người chơi, tôi sẽ không lo lắng về việc sử dụng bộ nhớ và sử dụng giải pháp đầu tiên. Bộ nhớ có vẻ rẻ hơn CPU.

Trên thực tế, ngay cả khi bạn có 4000 đơn vị cho mỗi người chơi, sử dụng hai số nguyên để lưu trữ vị trí đó và 8 người chơi, chỉ mất 2 MB, nhưng với giải pháp đầu tiên, bạn có thể sử dụng bộ nhận phối hợp O (1), thay vì O (n) (giả sử chưa được sắp xếp), với rất nhiều đơn vị có thể bị chậm.

Hầu hết các trò chơi dường như dựa trên pixel, thay vì gạch, bây giờ là một ngày, vì vậy họ chỉ cần có đơn vị để lưu trữ các đồng quỹ.

— Ray Britton
nguồn

Tôi không lo lắng về việc sử dụng bộ nhớ, tôi quan tâm hơn đến việc quản lý các phụ thuộc (theo nghĩa Thiết kế hướng đối tượng). Đó không phải là bộ nhớ thêm, giải pháp đầu tiên sẽ khiến tôi lo lắng, đó là sự phụ thuộc theo chu kỳ mà tôi không hài lòng, cũng giống như tôi thích bộ điều phối phối hợp O (1). Ngoài ra, tôi biết nhiều trò chơi dựa trên pixel bây giờ, nhưng tôi thích gạch nên đó là những gì tôi đang sử dụng. : P

— AJM

@AJM, tương tự, các ứng dụng trả phí tôi sẽ phát hành trên Android sẽ sử dụng gạch.

— Ray Britton