Socket
Berbasis Scripting translate by: Hana Pertiwi
Sebagian besar proyek
akan bekerja baik jika Anda memilih salah satu metode scripting yang hanya
menjelaskan. Entah itu jenis bahasa yang dibangun, seperti Lua, atau JNI, kita
telah membahas banyak hal-hal dasar yang akan membantu
Anda dalam banyak skenario.
Untuk
peningkatan fleksibilitas, kami bahkan melihat bagaimana perpustakaan sistem scripting dinamis terhubung yang mungkin akan berhasil.
Namun,
ada teknik tambahan yang dapat berguna ketika fleksibilitas ekstrim dan keamanan
diperlukan. Kita bisa memilih untuk kode script aplikasi dengan menggunakan
DLL. Akan tetapi DLL dapat berisi perangkat lunak berbahaya,
kode yang dapat membuat aplikasi kita nakal atau bahkan crash. Selain
itu, DLL (atau apa pun yang kit gunakan pada akhirnya setara dengan mekanisme) platform
tertentu.
Jadi, kita mencoba datang dengan solusi baru yang menyediakan:
1. Lingkungan yang terpisah untuk menjalankan script, sehingga dapat
dengan aman menutup jika diperlukan
2.
Sebuah infrastruktur platform-independen
Solusinya adalah dengan
menerapkan modul scripting Anda melalui soket. Socket (dijelaskan secara
rinci dalam Bab 10, "Pemrograman
Jaringan") adalah mekanisme standar untuk melaksanakan koneksi jaringan
menggunakan
protokol TCP / IP.
Hal ini dapat dibayangkan sebagai antrian dua
arah. Kedua rekan-rekan dalam aliran
komunikasi yang
dapat menulis data ke salah
satu ujung soket, dan komputer lain maka akan dapat mengambilnya dengan membaca
dari ujung.
Seperti yang mungkin sudah ditebak, salah satu ujung
soket akan menjadi milik modul permainan utama, dan ujung lainnya akan berada
di modul script. Karena mereka akan ada dua
aplikasi yang terpisah, script modul rusak tidak akan selalu mempengaruhi
permainan. Di sisi lain, pemrograman
socket sebagian besar standar.
Soket yang didukung oleh PC, UNIX
/ Linux kotak, dan komputer Macintosh, dan mungkin akan menjadi didukung di
Internet-siap konsol game. Mereka dapat dikodekan
dari C, C + +, Java, dan sejumlah pemrograman
bahasa lainnya.
Tapi soket memiliki dua manfaat
yang tak terduga. Pertama, modul naskah dapat dikompilasi
menjadi biner, yang berarti kinerja akan lebih baik dari dalam strategi
script lainnya (dikecualikan DLL). Kedua, script tidak perlu secara
fisik pada mesin yang sama sebagai kode permainan utama. Skrip dieksekusi melalui koneksi Internet
, yang dapat berguna dalam
skenario tertentu.
Perhatikan, bagaimanapun, manfaat
ini datang dengan biaya. Anda harus Bahasa memilih scripting pemrograman bahasa pilihan (C, C + +, dan
sebagainya). Rutinitas kustom tentu dapat
ditambahkan untuk membuat hidup penulis naskah
menjadi mudah, tapi secara keseluruhan
Anda mendapatkan kontrol yang kurang dari sintaks (sebagai lawan dari bahasa penerjemah). Selain itu, komunikasi soket sangat
tidak cocok untuk waktu-tugas penting. Diakui, jaringan menjadi lebih baik sepanjang waktu, tetapi beberapa proyek akan
menemukan soket terlalu membatasi dalam hal kinerja-bukan untuk naskah itu
sendiri, tetapi untuk waktu yang dibutuhkan untuk melewati argumen (dan hasil
kembali). Masalah lainnya yang harus anda
sadari adalah bahwa soket bisa rumit untuk dipertahankan jika ada banyak script
harus ditangani. Dalam kasus ekstrim, permainan
Anda menyerupai massively judul multiplayer dengan script bukan gamer.
Mari kita memeriksa penciptaan
sistem skrip berbasis soket.
Langkah pertama adalah menentukan
taksonomi dari callable modul. Jelas, kita menginginkan
efisiensi maksimum, jadi kami akan terus memuat modul yang dimuat dalam memori bukan
mengeksekusi setiap saat. Selain itu, dengan membuatnya
terus-menerus, kita bisa membuat modul yang menjaga negara variabel mereka sendiri dan menggunakannya dari
satu iterasi yang lain.
Dengan demikian, modul akan dimulai dari induk, dan sekali jalan, akan memasuki perulangan
berulang yang akan tetap berulang sampai diperintahkan untuk mati (shutdown). Sementara di ulang, mereka akan meminta
permintaan proses soket, proses mereka, dan secara opsional kembali dengan hasil
apapun itu
untuk proses panggilan. Berikut adalah ide coding untuk modul:
// buka soket untuk modul bermain game
// baca opcode dari soket
// spesifik operasi dari opcode letakkan disini
// tutup socket
Algoritma ini cukup efisien
baik dalam hal penggunaan kecepatan dan
CPU. Mengenai kecepatan, dimuat untuk menjaga modul dan soket
terbuka memastikan
bahwa biaya komunikasi yang melebihi batas disimpan
menjadi
minimum. Tapi tetap banyak script di
memori yang dapat menyebabkan beberapa masalah, terutama
jika CPU mereka lapar. Itu
sebabnya kita perlu
menjaga agar soket membuka dan membaca dari awal pada setiap
iterasi. Seperti yang akan Anda pelajari dalam Bab
10,apa
yang paling membuat soket biasa di blokir. Ini artinya bahwa dengan
membaca dari soket kosong akan menyebabkan proses
penghentian sampai data baru tiba. Dengan demikian, "membaca soket" berlangsung seperti semaphore.
Ini merupakan jeda proses skrip sampai perintah tiba (sehingga penggunaan
CPU sampai
tahap hampir nol). Setelah permintaan
baru tiba,
proses ini dilanjutkan,
permintaan tersebut dibahas dalam salah
satu rutin saklar opcode-penanganan, hasilnya dikembalikan menggunakan socket yang sama, dan proses ini ditidurkan lagi sampai perintah
baru diterima. Proses lengkap dipamerkan pada Gambar 9.3.
Gambar 9.3. Socket berbasis scripting transparan mengintegrasikan jaringan ke
dalam
mesin permainan.
Perhatikan, bahwa bagaimanapun setiap masalah yang kita punya, dengan
Java script masih
ada disini. Misalnya, sulit untuk script untuk
mengakses struktur data atau algoritma yang disimpan pada mesin permainan inti.
Ketika kami menggunakan JNI, kita melihat bagaimana membuat panggilan dari script untuk kode native C /
C + + adalah sedikit rumit dan terkadang di atas kepala. Dengan soket,
situasinya menjadi lebih buruk. Script ini hanya dirancang untuk menerima parameter melalui soket, melakukan perhitungan lokal, dan mengembalikan hasilnya.
Ada dua solusi untuk masalah ini. Yang pertama adalah solusi orang miskin:
mengirim perintah melalui pipa ke
aplikasi host menggunakan protokol yang telah ditetapkan. Hal ini dapat bekerja pada kasus sederhana, tetapi ketika banyak
perintah yang hadir, dengan cepat akan menjadi tidak terkendali. Solusi yang
lebih elegan untuk ini adalah dengan menggunakan Remote Procedure Call (RPC) mekanisme untuk
memastikan bahwa kami dapat membuat panggilan ke kode kita dari modul script. RPC memungkinkan pengembang untuk mendaftarkan fungsi pada
waktu kompilasi sehingga mereka terlihat baik oleh rekan-rekannya. Hal
yang rutin yang dilaksanakan
di mesin permainan inti dapat terkena script dan juga sekitarnya. Hal ini membuat kompilasi sedikit lebih kompleks karena kita perlu
menggunakan alat seperti RPCGen, tetapi manfaatnya jelas.
Penutup
Belum lama ini, permainan merupakan entitas tunggal yang
monolitik. Dengan scripting,
Anda sekarang dapat merurai kode Anda menjadi komponen-komponen yang
lebih kecil yang berinteraksi satu sama lain. Kita
telah melihat bagaimana teknik ini dapat digunakan untuk mencegah kesalahan, mengisolasi bagian dari
kode yang dapat membahayakan seluruh
aplikasi, atau mesin terpisah kode dari semua
kode yang ditulis secara efektif oleh tim pengembangan konten.
Alternatif scripting dan bahasa kami telah dieksplorasi akan membantu Anda meningkatkan ekspresif potensi subsistem AI Anda. Ditambah
dengan teknik kami yang telah dibahas dalam bab-bab sebelumnya, Anda sekarang padti siap untuk membuat padat, hal yang menarik.