Quản lý nhiều tài liệu tham khảo của cùng một thực thể trò chơi ở những nơi khác nhau bằng ID

Tôi đã thấy những câu hỏi hay về các chủ đề tương tự, nhưng không có câu hỏi nào đề cập đến phương pháp đặc biệt này:

Cho rằng tôi có nhiều bộ sưu tập các thực thể trò chơi trong trò chơi [XNA Game Studio] của mình, với nhiều thực thể thuộc nhiều danh sách, tôi đang xem xét các cách tôi có thể theo dõi bất cứ khi nào một thực thể bị phá hủy và xóa nó khỏi danh sách mà nó thuộc về .

Rất nhiều phương thức tiềm năng có vẻ cẩu thả / hỗn độn, nhưng tôi nhắc nhở về một cách mà tôi đã thấy trước đây, thay vì có nhiều bộ sưu tập thực thể trò chơi, thay vào đó bạn có bộ sưu tập ID thực thể trò chơi . Các ID này ánh xạ tới các thực thể trò chơi thông qua một "cơ sở dữ liệu" trung tâm (có lẽ chỉ là một bảng băm).

Vì vậy, bất cứ khi nào bất kỳ bit mã nào muốn truy cập vào các thành viên của thực thể trò chơi, trước tiên, nó sẽ kiểm tra xem liệu nó có còn trong cơ sở dữ liệu hay không. Nếu không, nó có thể phản ứng tương ứng.

Đây có phải là một cách tiếp cận âm thanh? Dường như nó sẽ loại bỏ nhiều rủi ro / rắc rối khi lưu trữ nhiều danh sách, với sự đánh đổi là chi phí tra cứu mỗi khi bạn muốn truy cập một đối tượng.

Câu trả lời ngắn gọn: có.

Câu trả lời dài: Trên thực tế, tất cả các trò chơi tôi đã thấy hoạt động theo cách này. Tra cứu bảng băm là đủ nhanh; và nếu bạn không quan tâm đến các giá trị ID thực tế (nghĩa là chúng không được sử dụng ở bất kỳ nơi nào khác), bạn có thể sử dụng một vectơ thay vì bảng băm. Mà thậm chí còn nhanh hơn.

Là một phần thưởng bổ sung, thiết lập này cho phép sử dụng lại các đối tượng trò chơi của bạn, giảm tỷ lệ phân bổ bộ nhớ của bạn. Khi một đối tượng trò chơi bị phá hủy, thay vì "giải phóng" nó, bạn chỉ cần dọn sạch các trường của nó và đặt vào một số "nhóm đối tượng". Sau đó, khi bạn cần một đối tượng mới, chỉ cần lấy một đối tượng hiện có từ nhóm. Nếu các đối tượng mới sinh sản liên tục, điều này đáng chú ý có thể cải thiện hiệu suất.

Đây có phải là một cách tiếp cận âm thanh? Dường như nó sẽ loại bỏ nhiều rủi ro / rắc rối khi lưu trữ nhiều danh sách, với sự đánh đổi là chi phí tra cứu mỗi khi bạn muốn truy cập một đối tượng.

Tất cả những gì bạn đã làm là chuyển gánh nặng thực hiện kiểm tra từ lúc phá hủy sang thời điểm sử dụng. Tôi sẽ không tuyên bố rằng tôi chưa bao giờ làm điều này trước đây, nhưng tôi không coi đó là 'âm thanh'.

Tôi đề nghị sử dụng một trong nhiều lựa chọn thay thế mạnh mẽ hơn. Nếu số lượng danh sách được biết đến, bạn có thể thoát khỏi chỉ cần xóa đối tượng khỏi tất cả các danh sách. Điều đó là vô hại nếu đối tượng không nằm trong một danh sách nhất định và bạn được đảm bảo đã xóa nó một cách chính xác.

Nếu số lượng danh sách là không xác định hoặc không thực tế thì lưu trữ các tham chiếu ngược đến chúng trên đối tượng. Việc triển khai điển hình của điều này là mẫu quan sát viên , nhưng bạn có thể có thể đạt được hiệu ứng tương tự với các đại biểu, họ gọi lại để xóa mục khỏi bất kỳ danh sách có chứa nào khi cần thiết.

Hoặc đôi khi bạn không thực sự cần nhiều danh sách. Thường thì bạn có thể giữ một đối tượng chỉ trong một danh sách và sử dụng các truy vấn động để tạo các bộ sưu tập tạm thời khác khi bạn cần chúng. ví dụ. Thay vì có một danh sách riêng cho kho đồ của một nhân vật, bạn chỉ có thể lấy ra tất cả các đối tượng trong đó "mang theo" bằng với ký tự hiện tại. Điều này nghe có vẻ không hiệu quả, nhưng nó đủ tốt cho cơ sở dữ liệu quan hệ và có thể được tối ưu hóa bằng cách lập chỉ mục thông minh.

Đây dường như chỉ là một ví dụ cụ thể hơn về vấn đề "làm thế nào để loại bỏ các đối tượng khỏi danh sách, trong khi lặp qua nó", rất dễ giải quyết (lặp theo thứ tự ngược có lẽ là cách đơn giản nhất cho danh sách kiểu mảng như C # List).

Nếu một thực thể sẽ được tham chiếu từ nhiều nơi, thì dù sao nó cũng phải là một loại tham chiếu . Vì vậy, bạn không phải trải qua một hệ thống ID phức tạp - một lớp trong C # đã cung cấp các hướng dẫn cần thiết.

Và cuối cùng - tại sao phải "kiểm tra cơ sở dữ liệu"? Chỉ cần cung cấp cho mỗi thực thể một IsDeadcờ và kiểm tra xem.

Tôi thường sử dụng phương pháp này trong trò chơi C # /. NET của riêng tôi. Ngoài các lợi ích khác (và các mối nguy hiểm!) Được mô tả ở đây, nó cũng có thể giúp tránh các vấn đề nối tiếp.

Nếu bạn muốn tận dụng các phương tiện tuần tự hóa nhị phân tích hợp sẵn của .NET Framework, thì việc sử dụng ID thực thể có thể giúp giảm thiểu kích thước của biểu đồ đối tượng được viết ra. Theo mặc định, trình định dạng nhị phân của .NET sẽ tuần tự hóa toàn bộ biểu đồ đối tượng ở cấp trường. Hãy nói rằng tôi muốn tuần tự hóa một Shipví dụ. Nếu Shipcó một _ownertrường tham chiếu đến Playerngười sở hữu nó, thì Playertrường hợp đó cũng sẽ được tuần tự hóa. Nếu Playerchứa một _shipstrường (của, giả sử, ICollection<Ship>), thì tất cả các tàu của người chơi cũng sẽ được viết ra, cùng với bất kỳ đối tượng nào khác được tham chiếu ở cấp trường (theo cách đệ quy). Thật dễ dàng để vô tình tuần tự hóa một biểu đồ đối tượng khổng lồ khi bạn chỉ muốn tuần tự hóa một phần nhỏ của nó.

Nếu, thay vào đó, tôi có một _ownerIdtrường, thì tôi có thể sử dụng giá trị đó để giải quyết Playertham chiếu theo yêu cầu. API công khai của tôi thậm chí có thể không thay đổi, với thuộc Ownertính chỉ cần thực hiện tra cứu.

Mặc dù tra cứu dựa trên hàm băm nói chung là rất nhanh, nhưng chi phí bổ sung có thể trở thành vấn đề đối với các tập thực thể rất lớn với việc tra cứu thường xuyên. Nếu nó trở thành vấn đề với bạn, bạn có thể lưu trữ tham chiếu bằng cách sử dụng trường không được tuần tự hóa. Ví dụ: bạn có thể làm một cái gì đó như thế này:

public class Ship
{
    private int _ownerId;
    [NonSerialized] private Lazy<Player> _owner;

    public Player Owner
    {
        get { return _owner.Value; }
    }

    public Ship(Player owner)
    {
        _ownerId = owner.PlayerID;
        EnsureCache();
    }

    private void EnsureCache()
    {
        if (_owner == null)
            _owner = new Lazy<Player>(() => Game.Current.Players[_ownerId]);
    }

    [OnDeserialized]
    private void OnDeserialized(StreamingContext context)
    {
        EnsureCache();
    }
}

Tất nhiên, cách tiếp cận này cũng có thể làm cho việc tuần tự hóa trở nên khó khăn hơn khi bạn thực sự muốn tuần tự hóa một biểu đồ đối tượng lớn. Trong những trường hợp đó, bạn sẽ cần nghĩ ra một số loại 'container' để đảm bảo rằng tất cả các đối tượng cần thiết đều được bao gồm.

Một cách khác để xử lý việc dọn dẹp của bạn là đảo ngược điều khiển và sử dụng một đối tượng Dùng một lần. Bạn có thể có một yếu tố phân bổ các thực thể của bạn, vì vậy hãy vượt qua tất cả các danh sách mà nó cần được thêm vào. Thực thể giữ một tham chiếu đến tất cả các danh sách mà nó là một phần của và thực hiện IDis Dùng. Trong phương thức xử lý, nó loại bỏ chính nó khỏi tất cả các danh sách. Bây giờ bạn chỉ phải quan tâm đến việc quản lý danh sách ở hai nơi: nhà máy (sáng tạo) và xử lý. Xóa trong đối tượng cũng đơn giản như entity.Dispose ().

Vấn đề về tên và tham chiếu trong C # thực sự chỉ quan trọng để quản lý các thành phần hoặc loại giá trị. Nếu bạn có danh sách các thành phần được liên kết với một thực thể, sử dụng trường ID làm khóa băm có thể hữu ích. Nếu bạn chỉ có danh sách các thực thể, chỉ cần sử dụng danh sách có tham chiếu. Tài liệu tham khảo C # là an toàn và đơn giản để làm việc với.

Để xóa hoặc thêm các mục khỏi danh sách, bạn có thể sử dụng Hàng đợi hoặc bất kỳ số giải pháp nào khác để xử lý việc thêm và xóa khỏi danh sách.