Socket Berbasis Scripting

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

while (!end)

{

// baca opcode dari soket

switch (opcode)

{

case QUIT:

end=true;

break;

// 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.