Sprite sebagai Aktor

Saya tidak berpengalaman dalam pertanyaan Pengembangan Game, tetapi sebagai programmer. Dalam bahasa Scala, Anda dapat memiliki multi-tasking yang dapat diskalakan dengan Aktor, sangat stabil, seperti yang saya dengar. Anda bahkan dapat memiliki ratusan ribu dari mereka berjalan sekaligus tanpa masalah.

Jadi saya pikir, mungkin Anda bisa menggunakan ini sebagai kelas dasar untuk 2D-Sprite, untuk keluar dari game-loop yang harus melalui semua sprite dan memindahkannya. Mereka pada dasarnya akan bergerak sendiri, dikendalikan oleh peristiwa.

Apakah itu masuk akal untuk sebuah game? Setelah multitasking seperti itu? Bagaimanapun, ini akan berjalan pada JVM, meskipun itu seharusnya tidak menjadi masalah saat ini.

EDIT:

Setelah mencoba-coba sebentar, saya perhatikan hanya ada satu keuntungan nyata untuk ide ini: Dukungan Multicore. Loop game sederhana hanya akan berjalan pada satu inti dan akan bekerja melalui semuanya secara berurutan.

Karena komputer modern, bahkan di rumah, saat ini memiliki dua atau lebih inti built-in, saya pikir itu adalah ide yang baik untuk memungkinkan pemrogram game untuk secara efisien menggunakan core lainnya. Setelah semua, saya pikir biasanya pemain hanya akan menjalankan permainan pada mesin delapan-inti, jadi mengapa tidak.

Keuntungan lain yang saya lihat adalah bahwa di Scala, Anda dapat memiliki RemoteActors, yang dapat diperlakukan dengan cara yang sama tetapi dijalankan di komputer lain. Jadi mungkin ini bisa menyederhanakan permainan jaringan juga.

Saya berniat membangun itu ke dalam mesin Scala 2D saya sesegera mungkin.

Saya tidak mencoba, tetapi saya seorang programmer Scala, dan saya akan mengatakan bahwa ini bukan pendekatan terbaik. Sprite harus dianimasikan secara sinkron. Aktor tidak memiliki jaminan bahwa mereka akan dieksekusi secara adil - beberapa sprite mungkin lebih cepat daripada yang lain, yang bukan yang Anda inginkan. Anda mungkin ingin menggunakan penghalang untuk menyinkronkannya, tetapi kemudian - mengapa menggunakan aktor. Jika Anda hanya mengandalkan pesan yang lewat, menerapkan sinkronisasi semacam ini (menerapkan penghalang untuk 1000+ aktor) adalah hal yang berlebihan.

Masalah lainnya adalah - untuk apa Anda menggunakan passing pesan? Apakah Anda memerlukan sprite untuk berkomunikasi? Anda bisa mengirim pesan oleh aktor utama, memberi tahu setiap sprite untuk pindah ke frame berikutnya, tetapi dalam hal kinerja, itu magnitude dan magnitude lebih dari memanggil metode secara langsung dan beralih melalui seperangkat sprite.

Menurut saya apa yang Anda butuhkan di sini adalah semacam multitasking yang sangat ringan, dan tidak ada pesan yang lewat sama sekali. Bergulir dalam implementasi aktor-seperti Anda sendiri yang memastikan keadilan mungkin adalah cara terbaik untuk pergi jika Anda ingin memastikan ini, tapi itu terlalu banyak bekerja untuk mendapatkan terlalu sedikit. Satu hal yang perlu diperhatikan adalah pemrograman reaktif fungsional dan scala.react, saya percaya itu adalah kecocokan yang lebih baik untuk kasus penggunaan ini.

Saya telah mengimplementasikan mesin game isometrik 2d di Scala. Saya hanya menggunakan 1 aktor global untuk memperbarui sprite yang terlihat yang dianimasikan.

Anda mungkin ingin menerapkan logika game Anda menggunakan aktor - misalnya, untuk mendistribusikan perhitungan pada bagian berbeda dari peta permainan Anda ke aktor yang berbeda, sehingga mereka memperbarui keadaan game secara paralel - dan mendapatkan keuntungan kinerja. Saya tidak akan menggunakan aktor tunggal per objek game, melainkan aktor per wilayah. Jika Anda terlalu berbutir halus, kinerja akan terganggu.

Tetap saja, jika aku jadi kamu, aku akan mencobanya, hanya untuk melihat apa yang terjadi.

Jadi saya pikir, mungkin Anda bisa menggunakan ini sebagai kelas dasar untuk 2D-Sprite, untuk keluar dari game-loop yang harus melalui semua sprite dan memindahkannya. Mereka pada dasarnya akan bergerak sendiri, dikendalikan oleh peristiwa.

Acara apa yang menggerakkan mereka?

Apakah itu acara yang Anda pancarkan satu kali per frame?

Dan jika demikian, bagaimana ini mengubah sistem dengan cara praktis?

Ketika awalnya mempelajari orientasi objek dalam konteks C ++, saya belajar bahwa beberapa orang suka memikirkan pernyataan seperti xyz.doThis(x)makna 'mengirim pesan doThis ke xyz (dengan muatan x) dan menunggu tanggapan segera`. Jika dilihat pada level ini, tidak ada perbedaan intrinsik antara sistem berbasis peristiwa atau pesan dan sistem prosedural normal.

Itu pendekatan yang keren untuk berpikir tentang memperbarui objek game Anda. Saya tidak tahu Scala, tapi saya katakan mencobanya dan lihat bagaimana hasilnya, dan bahkan lebih baik kirim hasil Anda!

Pertanyaan utama yang muncul di benak saya adalah: Bagaimana Anda mengelola seberapa sering beberapa objek game diperbarui dibandingkan yang lain? Apakah Anda perlu khawatir tentang aktor sprite mengambil terlalu banyak siklus sehingga sistem rendering tidak punya waktu untuk menggambar bingkai setiap 1 / 60th | 30th | 24th per detik?

Hal lain yang perlu dipertimbangkan adalah bagaimana ini akan mempengaruhi resolusi interaksi pemain vs AI yang bergantung pada urutan urutan peristiwa yang sangat cepat. Tergantung pada jenis permainan, ini mungkin tidak mungkin tidak akan peduli banyak.

Ya, saya juga bukan programmer, tapi saya tidak melihat masalah dengan proposal Anda. Saya bahkan tidak memikirkan cara mengembangkan aktor seperti itu.

Ini mungkin sebuah tantangan, karena IA harus sangat akurat, untuk menghindari perilaku yang tidak diinginkan, tetapi selain itu, saya melihat itu adalah proposal yang cukup bagus

Jika dengan sprite yang Anda maksud entitas game maka yakin.

Entitas game tidak boleh menggambar dirinya sendiri. Mereka harus memperbarui pegangan grafis yang menjelaskan di mana dan bagaimana mereka harus ditarik. Sistem render atau grafik adegan atau apapun gambar aslinya. Ada satu kartu grafis, lebih lanjut kartu grafis harus disinkronkan setiap 16ms. Pengaturan seperti itu tidak berfungsi dengan baik untuk pemrosesan asinkron yang didistribusikan.

Sistem render harus menjadi satu aktor (atau mungkin pasangan jika Anda rumit). Saat entitas gim memperbarui pegangan grafis, ia mengirim pesan ke sistem render. Sistem render, dapatkah mereka membuat segala macam keputusan dan / atau optimisasi, misalnya rendering batch, oklusi, smoothing jitter fisika, dll.

Saya bukan pengembang Scala, tapi saya sudah melakukan banyak hal dengan Erlang. Jadi jika beberapa terminologi Scala saya salah, mohon maafkan saya.