Haruskah saya menggunakan Acara di Game XNA?

Saya membuat kelas tombol yang menggambar tombol di layar. Ketika saya mengkliknya, saya ingin melihat sesuatu terjadi. Di WinForm, saya hanya akan menggunakan event OnClick tombol. Bagaimana dengan XNA?

Haruskah saya menambahkan acara OnClick ke kelas tombol saya? Apakah itu praktik yang baik? Jika tidak, bagaimana Anda menangani acara di loop game Anda?

Satu-satunya alasan untuk tidak menggunakan eventdalam gim adalah bahwa membuat delegasi untuk dilampirkan ke event handler menciptakan objek tumpukan yang dapat menyebabkan pengumpulan sampah yang dapat menyebabkan cegukan tingkat bingkai pada Xbox 360 (dan mungkin WP7, belum diuji Itu).

Secara umum, ini seharusnya tidak relevan dengan UI game yang Anda set-up sekali dan cukup dijalankan.

Juga, memanggil event handler adalah sedikit, kecil, sedikit lebih lambat beberapa metode lain yang tersedia. Dan ini juga sama sekali tidak relevan untuk UI. (Ini hanya berlaku untuk pengerasan-angka yang dioptimalkan secara mikro).

Jadi, selama Anda tidak berlarian menugaskan event handler, mau tidak mau, maka pilihan menggunakan eventdalam permainan tidak berbeda dengan pilihan menggunakan satu dalam aplikasi reguler.

Menyalin desain WinForms untuk UI game Anda baik-baik saja.

(Ada baiknya menunjukkan satu peringatan dari peristiwa adalah bahwa mereka adalah "referensi kuat" yang tersembunyi yang dapat secara tidak sengaja menjaga objek tetap hidup jika Anda tidak menghapus pawang. Ini relevan untuk gim dan aplikasi reguler)

Sangat dapat diterima untuk menggunakan acara untuk menangani hal-hal seperti klik dan interaksi lainnya dengan antarmuka tombol Anda; itu tentu metode yang unggul untuk yang melibatkan subclass Buttonjenis untuk menerapkan perilaku yang disesuaikan.

Alternatif lain yang tidak umum adalah melampirkan skrip ke tombol dan elemen UI lainnya, tetapi ini lebih terlibat (kecuali Anda sudah memiliki sistem skrip yang kuat) dan tidak selalu lebih baik.

Anda mungkin juga ingin melihat konsep " GUI mode langsung ," yang menyediakan cara lain untuk menangani input.

Ada tiga pendekatan umum yang saya lihat di mesin permainan, saya tidak yakin tentang XNA mendukung ketiganya tetapi di sini mereka:

1. Anda bisa mewarisi kelas dari kelas tombol Anda dan menimpa OnClickFunction di kelas CustomButton Anda. Keuntungannya adalah Anda tidak perlu memeriksa apakah tombol ditekan itu memberi tahu Anda setiap kali diklik tetapi mungkin menyebabkan pewarisan yang berlebihan.

2. Anda dapat mendefinisikan beberapa fungsi OnClick dan meneruskannya ke kelas butten OnClickEvent (sama seperti penanganan acara biasa c #). ini memiliki manfaat yang sama dengan yang sebelumnya dan Anda tidak perlu khawatir untuk pewarisan yang berlebihan.

3. Anda harus memeriksa di loop utama Anda apakah tombol ini diklik atau tidak. dalam metode ini bukan acara yang sebenarnya. jadi kekurangannya adalah Anda harus memeriksa diri sendiri setiap kali Anda harus melakukan sesuatu berdasarkan input tombol tetapi memiliki keuntungan bahwa Anda dapat mengontrol di mana tombol benar-benar diperiksa dan berlaku.

Saya berhenti menggunakan acara .net dan mulai menyimpan semua acara dan perubahan dalam buffer:

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;
}

Pro:

1. Untuk dukungan multithreading, satu-satunya hal yang Anda butuhkan adalah untuk menukar buffer dan memproses semua acara dan perubahan dalam render thread
2. Setiap perubahan gamestep akan disimpan, sehingga logika permainan apa pun dapat didasarkan pada kombinasi acara. Anda bahkan dapat menerapkan pembalikan waktu.
3. Anda tidak perlu membuat bidang peristiwa yang menambah ukuran objek tunggal. Logika gim dalam kebanyakan kasus hanya membutuhkan satu pelanggan langka.
4. Hampir tidak ada alokasi memori tambahan (tidak termasuk kasus tinju) (WP7, XBox dan kerangka kerja mikro lainnya).
5. Anda dapat memiliki rangkaian acara berbeda yang menangani GameStateData yang telah ditentukan sebelumnya untuk objek.

Cons:

1. Lebih banyak pengeluaran memori, meskipun Anda hanya membutuhkan 3 buffer (game, swap, dan render).
2. Menulis kode tambahan di awal untuk mengimplementasikan fungsionalitas yang diperlukan.

BTW terkadang saya menggunakan keduanya: model acara dan model buffer.