Tôi có nên sử dụng Sự kiện trong Trò chơi XNA không?

Tôi đã tạo một lớp nút vẽ một nút trên màn hình. Khi tôi nhấp vào nó, tôi muốn thấy điều gì đó xảy ra. Trong WinForm, tôi chỉ cần sử dụng sự kiện OnClick của nút. XNA thì sao?

Tôi có nên thêm một sự kiện OnClick vào lớp nút của mình không? Đó có phải là một thực hành tốt? Nếu không, làm thế nào để bạn xử lý các sự kiện trong vòng lặp trò chơi của bạn?

Lý do duy nhất chống lại việc sử dụng eventtrong trò chơi là việc tạo một đại biểu để gắn vào trình xử lý sự kiện sẽ tạo ra một đối tượng heap có thể gây ra bộ sưu tập rác có thể gây ra trục trặc tốc độ khung hình trên Xbox 360 (và có thể cả WP7, chưa được thử nghiệm nó).

Nói chung, điều này không liên quan đến giao diện người dùng trò chơi mà bạn đã thiết lập một lần và chỉ cần chạy.

Ngoài ra, gọi một trình xử lý sự kiện là một phương thức nhỏ, nhỏ, chậm hơn một số phương thức có sẵn khác. Và điều này cũng hoàn toàn không liên quan đến UI. (Nó chỉ đi vào chơi cho crunching số tối ưu hóa vi mô).

Vì vậy, miễn là bạn không chạy xung quanh việc chỉ định xử lý sự kiện, thì việc lựa chọn sử dụng eventtrong trò chơi không khác gì với lựa chọn sử dụng một trong ứng dụng thông thường.

Sao chép thiết kế của WinForms cho giao diện người dùng trò chơi của bạn là hoàn toàn tốt.

(Điều đáng để chỉ ra một sự kiện là chúng là các tài liệu tham khảo mạnh "ẩn" có thể vô tình giữ các đối tượng sống nếu bạn không gỡ bỏ trình xử lý. Điều này có liên quan đến cả trò chơi và ứng dụng thông thường)

Hoàn toàn chấp nhận được khi sử dụng các sự kiện để xử lý những thứ như nhấp chuột và tương tác khác với giao diện nút của bạn; nó chắc chắn là một phương pháp ưu việt so với phương pháp liên quan đến phân lớp Buttonloại để thực hiện hành vi tùy chỉnh.

Một cách khác không phổ biến là gắn tập lệnh vào các nút và các thành phần UI khác, nhưng điều này có liên quan nhiều hơn (trừ khi bạn đã có một hệ thống tập lệnh mạnh mẽ) và dù sao cũng không tốt hơn.

Bạn cũng có thể muốn xem xét khái niệm " GUI chế độ tức thời ", cung cấp cho một cách xử lý đầu vào khác.

Có ba sự chấp thuận phổ biến mà tôi thấy trong các công cụ trò chơi, tôi không chắc về XNA hỗ trợ cả ba nhưng đây là:

1. bạn có thể kế thừa một lớp từ lớp nút của mình và ghi đè OnClickFunction trong lớp CustomButton của bạn. Lợi ích là bạn không phải kiểm tra xem nút có được nhấn hay không, nó thông báo cho bạn bất cứ khi nào nó nhấp nhưng nó có thể gây ra lạm dụng thừa kế.

2. bạn có thể xác định một số chức năng OnClick và chuyển nó vào lớp butten OnClickEvent (giống như xử lý sự kiện c # bình thường). điều này có lợi ích tương tự như trước đây và bạn không cần phải lo lắng về việc lạm dụng thừa kế.

3. bạn phải kiểm tra trong vòng lặp chính của mình xem nút này có được bấm hay không. trong phương pháp này nó không thực sự là sự kiện. Vì vậy, nhược điểm là bạn phải tự kiểm tra bất cứ khi nào bạn phải làm gì đó dựa trên đầu vào nút nhưng có một lợi thế là bạn có thể kiểm soát nơi các nút thực sự được kiểm tra và có hiệu lực.

Tôi đã ngừng sử dụng các sự kiện .net và bắt đầu lưu trữ tất cả các sự kiện và thay đổi của tôi trong bộ đệm:

public sealed class GameStateData
{
    public bool IsEmpty = true;
    public List<EventData> EventDatas = new List<EventData>();
    public List<ChangeData> ChangeDatas = new List<ChangeData>();
    ...//your additional data

    public void Reset()
    {
        IsEmpty = true;
        ManifoldDatas.Count = 0;
        ChangeDatas.Count = 0;
    }
}

public struct ChangeData
{
    public Node Sender;
    public short PropertyIndex; // predefined property index (f.e. (short)MyIndexEnum.Life)
    public object OldValue;
    public object NewValue;
    public object AdditionalData;
}

Ưu điểm:

1. Để hỗ trợ đa luồng, điều duy nhất bạn cần là trao đổi bộ đệm và xử lý tất cả các sự kiện và thay đổi trong luồng kết xuất.
2. Mọi thay đổi của trò chơi sẽ được lưu lại, do đó, bất kỳ logic trò chơi nào cũng có thể dựa trên sự kết hợp của các sự kiện. Bạn thậm chí có thể thực hiện đảo ngược thời gian.
3. Bạn không cần tạo các trường sự kiện tăng kích thước của một đối tượng. Logic trò chơi trong hầu hết các trường hợp chỉ yêu cầu thuê bao hiếm.
4. Hầu như không có phân bổ bộ nhớ bổ sung (không bao gồm các trường hợp đấm bốc) (WP7, XBox và các khung vi mô quan trọng khác).
5. Bạn có thể có các bộ sự kiện khác nhau xử lý một GameStateData được xác định trước cho đối tượng.

Nhược điểm:

1. Chi tiêu bộ nhớ nhiều hơn, mặc dù bạn chỉ cần 3 bộ đệm (trò chơi, trao đổi và kết xuất).
2. Viết mã bổ sung khi bắt đầu để thực hiện chức năng cần thiết.

BTW đôi khi tôi sử dụng cả hai: mô hình sự kiện và mô hình đệm.