Wandering Monster: cara menyingkirkan masalah di peta

Sudah dalam proses menciptakan The Witness telah menjadi salah satu game favorit saya. Saya mulai memainkannya sejak saat Jonathan Blow mulai mengembangkannya, dan tidak bisa menunggu rilisnya.

Tidak seperti game John Braid sebelumnya, skala sumber daya dan pemrograman The Witness jauh lebih dekat dengan proyek AAA daripada game indie. Setiap orang yang bekerja pada proyek seperti itu tahu bahwa jumlah pekerjaan ketika memilih jalur ini meningkat secara signifikan. Ada lebih banyak orang yang bekerja pada Saksi daripada pada Braid , tetapi seperti halnya proyek pada tingkat ini, ada banyak aspek yang membutuhkan lebih banyak perhatian daripada yang bisa diberikan manajemen proyek.

Karena itu, saya selalu ingin mencari waktu luang untuk membantu menciptakan The Witness ketika akan merilis game. Jadi suatu hari, Thanksgiving, John dan saya duduk dan melihat daftar hal-hal dalam basis kode yang akan mendapat manfaat dari upaya tambahan dari programmer lain. Setelah memutuskan kepentingan relatif dari item dalam daftar, kami memutuskan bahwa permainan akan mendapat manfaat paling besar jika kami melakukan perbaikan pada kode gerakan pemain.

Walkmonster di dinding

Dalam konteks Saksi , tujuan kode gerakan pemain adalah untuk tidak mengganggu mungkin. Pemain harus sepenuhnya membenamkan dirinya dalam realitas alternatif, dan dalam pengalaman permainan ini setiap detail adalah penting. Hal terakhir yang kami inginkan adalah agar pemain memperhatikan bahwa ia sedang duduk di depan komputer dan menggerakkan kamera virtual.

Karenanya, kode gerakan pemain harus benar-benar andal. Jika seorang pemain menempel di sudut-sudut, terjebak di dinding, jatuh melalui lantai, turun dari bukit tanpa kemampuan untuk kembali, dll., Ini akan langsung menghancurkan ilusi perendaman dan mengingatkan pemain bahwa ia berada di dalam proses permainan buatan yang diganggu oleh sistem yang tidak dapat diandalkan perpindahan. Dalam beberapa keadaan, ini bahkan dapat menyebabkan konsekuensi bencana bagi pemain jika ia tidak memiliki kesempatan untuk menyelesaikan masalah dengan memulai kembali permainan atau memuat ulang "mungkin" yang lama. Jika Anda sering bermain game, Anda pasti mengalami masalah jenis ini, dan Anda tahu apa yang saya maksud.

Setelah diskusi kami, saya mulai mengerjakan tugas ini. Pertama-tama, saya memutuskan untuk menulis alat terintegrasi untuk bekerja dengan kode gerakan pemain, sehingga kami dapat menganalisisnya dan mengamati perilakunya saat ini. Setelah membuka proyek, saya mengalami masalah serius yang sudah diketahui oleh saya: apa yang harus saya beri nama file kode sumber pertama? Ini selalu menjadi bagian terpenting dari proyek apa pun ( seperti yang pernah dikatakan Bob Pollard tentang nama grup musik dan album ). Jika Anda memberikan file sumber nama yang sesuai, maka pekerjaan lebih lanjut akan jelas dan lancar. Pilih yang salah - Anda dapat menghancurkan seluruh proyek.

Tapi apa nama sistem untuk memastikan kualitas kode gerakan pemain? Saya belum pernah menulis kode seperti ini sebelumnya. Ketika saya memikirkan hal ini, saya menyadari bahwa saya pribadi melihat contoh kode semacam itu hanya sekali: ketika memainkan beta awal Quake . Isinya bug dengan lokasi monster, dan di jendela konsol Anda bisa melihat pesan kesalahan yang menyatakan bahwa monster, bukannya menciptakan di permukaan bumi, dibuat, sebagian berpotongan dengan geometri level. Setiap pesan debug dimulai dengan frasa "walkmonster di dinding di ..."

Bingo! Sulit menemukan nama yang lebih baik untuk file kode daripada "walk_monster.cpp". Dan saya hampir yakin bahwa mulai sekarang kode akan dibuat tanpa masalah.

Gerakan ke titik

Ketika Anda ingin menguji sistem, yang paling penting adalah benar-benar menguji sistem . Meskipun aturan ini tampak sederhana, orang yang menulis tes sering gagal untuk mematuhinya.

Dalam kasus khusus kami, sangat mudah untuk membayangkan bahwa kami menguji kode gerakan pemain tanpa benar-benar mengujinya. Berikut ini salah satu contohnya: Anda dapat menganalisis volume tabrakan dan permukaan tempat Anda dapat bergerak dalam permainan, mencari permukaan kecil, celah, dll. Setelah menghilangkan semua masalah ini, kita dapat mengatakan bahwa sekarang pemain dapat bergerak dan berjalan dengan aman di seluruh dunia.

Namun pada kenyataannya, kami menguji data, bukan kode. Sangat mungkin bahwa akan ada bug dalam kode gerak yang menyebabkan perilaku buruk bahkan dengan data berkualitas tinggi.

Untuk menghindari jebakan seperti itu, saya ingin sistem pengujian sedekat mungkin dengan perilaku orang yang benar-benar mengendalikan pergerakan karakter dalam permainan. Saya mulai dengan menulis dua prosedur yang akan menjadi dasar pengujian tersebut.

Prosedur pertama paling dekat dengan tindakan nyata manusia. Ini adalah panggilan pembaruan yang menghubungkan ke sistem pemrosesan input The Witness dan meneruskan kejadian keyboard dan mouse yang disintesis kepadanya. Ia mampu melakukan hal-hal sederhana yang dapat dilakukan seseorang: melihat-lihat, pergi ke suatu titik, melihat suatu titik, dan seterusnya. Prosedur melakukan tindakan-tindakan ini dengan hanya meniru interaksi pengguna dengan keyboard dan mouse, jadi saya yakin bahwa ketika memproses input dari The Witness semuanya akan dilakukan persis seperti saat pengujian. Dalam artikel berikut saya akan berbicara lebih banyak tentang sistem ini dan penggunaannya.

Prosedur kedua adalah satu langkah yang tidak digunakan pada level ini. Ini adalah fungsi yang disebut DriveTowardPoint , yang menerima dua poin di dunia dan, menyebabkan sistem tabrakan pemain yang ada, mencoba untuk berpindah dari satu titik ke titik lainnya. Melaksanakan kembalinya, dia mentransmisikan informasi tentang upaya: apa hambatan yang dia temui di jalan dan apakah dia berhasil mencapai titik akhir.

Fungsi ini tidak dapat diandalkan seperti metode pengujian dengan input yang disintesis, karena menghilangkan bagian dari sistem pergerakan pemain dari pengujian. Misalnya, kondisi salah apa pun yang terkait dengan lokasi pemain jika terjadi masalah dengan sistem tumbukan tidak akan mempengaruhi pengujian menggunakan fungsi ini. Namun demikian, saya menganggap tingkat pengujian ini berharga karena dapat menguji area yang luas lebih cepat, karena tidak memerlukan pelaksanaan seluruh siklus permainan, yaitu, dapat digunakan lebih sering di seluruh dunia, dan tidak hanya dalam uji coba terpisah .

Perlu juga dicatat bahwa fungsi ini tidak mengirimkan data input fisik; misalnya, kecepatan tidak ditunjukkan untuk titik awal. Ini karena The Witness bukan permainan aksi, jadi pemain memiliki beberapa sifat fisik yang signifikan. Pemain tidak bisa melompat, berlari di dinding, menyalakan waktu peluru. Anda dapat mendukung perilaku tersebut menggunakan sistem yang akan saya uraikan nanti, tetapi mereka menambahkan tingkat kompleksitas yang tidak diperlukan dalam proyek kami.

Namun, setelah menerapkan DriveTowardPoint saya bisa mulai menyelesaikan tugas pertama sistem: menentukan di mana pemain dapat pindah ke Pulau Witness .

Menjelajahi Pohon Acak Dengan Cepat

Ke mana pemain bisa pergi? Ini sepertinya pertanyaan sederhana, tetapi Anda akan terkejut mengetahui berapa banyak game yang dirilis ketika tim pengembang tidak tahu jawaban yang sebenarnya. Jika ini mungkin, maka saya ingin Saksi menjadi salah satu dari beberapa game di mana pengembang sebelum rilis tahu persis di mana pemain bisa dan tidak bisa mendapatkan - tidak ada kejutan.

Ini membuat pernyataan masalah (tapi mungkin bukan solusinya) sangat sederhana: jika ada fungsi DriveTowardPoint yang dapat menentukan apakah pemain dapat bergerak dalam garis lurus antara dua titik, buat peta cakupan yang menunjukkan di mana pemain berada.

Untuk beberapa alasan, tanpa menulis satu baris kode, untuk beberapa alasan saya pikir akan lebih baik menggunakan Rapidly Exploring Random Tree . Bagi mereka yang tidak terbiasa dengan algoritma ini, saya akan menjelaskan: ini adalah proses yang sangat sederhana di mana kami merekam semua poin yang kami kunjungi dengan referensi ke titik dari mana kami berasal. Untuk menambahkan titik ke pohon, kami mengambil titik target acak di mana saja di dunia, pilih titik terdekat, sudah di pohon, dan mencoba untuk mendapatkan dari titik ini ke target. Tempat di mana kami akhirnya menjadi titik pengambilan sampel berikutnya.

Biasanya algoritma ini digunakan untuk mencari jalur: secara bergantian untuk titik-titik acak, kami selalu memilih titik yang sama dengan target. Ini cenderung mengeksplorasi ruang menuju titik target, dan inilah yang diperlukan ketika satu-satunya tugas kita adalah mencapai tujuan. Tetapi dalam kasus ini, saya ingin membuat peta lengkap tempat pemain bisa jatuh, jadi saya hanya menggunakan sampel acak.

Setelah menerapkan algoritma ini (untungnya, ini sangat sederhana dan tidak memerlukan banyak waktu), saya melihat bahwa ia melakukan pekerjaan yang cukup baik dalam menjelajahi ruang (jalur yang ditunjukkan ditunjukkan oleh jalur putih dan garis merah vertikal menunjukkan tempat-tempat di mana algoritma bertabrakan dengan penghalang) :


Namun, setelah mengamati perilakunya, saya menyadari bahwa sebenarnya saya tidak perlu algoritma seperti itu. Sebagai contoh, bahkan setelah banyak iterasi, ia hampir tidak dapat menjelajahi kamar yang mirip dengan yang ditunjukkan di bawah ini, meskipun cakupan area luarnya padat. Ini karena dia tidak bisa memilih titik acak yang cukup di dalam kamar:


Jika saya memikirkan hal ini sebelum mulai bekerja, saya akan mengerti bahwa keuntungan dari algoritma seperti Rapidly Exploring Random Tree adalah bahwa mereka secara efektif menjelajahi ruang dimensi tinggi. Bahkan, ini biasanya menjadi alasan utama penggunaannya. Tetapi Saksi tidak memiliki ruang dimensi tinggi. Kami memiliki ruang dua dimensi (ya, didistribusikan pada varietas yang kompleks, tetapi ini masih merupakan ruang dua dimensi).

Dalam ruang berdimensi rendah ini, keuntungan dari Rapidly Exploring Random Tree lemah, dan kelemahannya sangat penting untuk tugas saya: algoritme ini dirancang untuk pencarian jalur yang paling efisien untuk pasangan titik yang terhubung di ruang, dan bukan untuk pencarian yang efisien untuk semua titik yang dapat dijangkau dari ruang ini. Jika Anda memiliki tugas seperti itu, maka sebenarnya Rapidly Exploring Random Tree akan membutuhkan banyak waktu untuk menyelesaikannya.

Jadi saya segera menyadari bahwa saya perlu mencari sebuah algoritma yang secara efektif sepenuhnya menutupi ruang dimensi rendah.

Mengisi Banjir 3D

Ketika saya benar-benar berpikir tentang memilih algoritma, menjadi jelas bahwa sebenarnya saya membutuhkan sesuatu seperti isian dua dimensi yang bagus, yang digunakan untuk mengisi area bitmap. Untuk setiap titik awal, saya hanya perlu mengisi seluruh ruang, memeriksa setiap cara yang mungkin. Sayangnya, karena berbagai alasan, solusi untuk The Witness akan jauh lebih rumit daripada untuk bitmap dua dimensi.

Pertama, kita tidak memiliki konsep yang jelas tentang keterhubungan terbatas suatu titik. Semua ruang kontinu. Ini untuk piksel, kami dapat dengan mudah mendaftar 4 tempat yang mungkin dapat dijangkau dari titik tertentu, dan memeriksa masing-masing secara bergantian.

Kedua, tidak ada ukuran posisi yang tetap di ruang angkasa, seperti piksel pada bitmap. Permukaan tempat pemain bergerak, dan rintangan dapat berada di mana saja, mereka tidak memiliki ukuran topologi maksimum atau minimum, serta tidak mengikat ke grid eksternal.

Ketiga, meskipun pergerakan melalui ruang Saksi dapat secara lokal dianggap bergerak di sepanjang pesawat, ruang itu sendiri sebenarnya sangat saling berhubungan dan berganti-ganti, di mana area walkable pemain berada tepat di atas area lain (kadang-kadang mungkin ada beberapa level yang terletak satu di atas yang lain) . Selain itu, ada koneksi yang bervariasi tergantung pada kondisi dunia (pintu terbuka / tertutup, elevator yang naik / turun, dll.).

Mengingat kesulitan yang diuraikan, sangat mudah untuk membuat versi Anda sendiri dari implementasi pengisian, yang sebagai hasilnya akan diisi dengan daerah yang bersinggungan, kehilangan rute-rute penting, informasi yang salah tentang koneksi di tempat-tempat kompleks manifold. Pada akhirnya, algoritme akan terlalu rumit untuk digunakan, karena untuk memperhitungkan perubahan akun di negara dunia itu harus dijalankan kembali.

Saya tidak segera memikirkan solusi yang baik, jadi saya memutuskan untuk memulai dengan eksperimen sederhana. Dengan menggunakan kode Random Tree yang Saya Eksplorasi Secara Cepat , saya mengubah pemilihan titik target dari acak menjadi sangat terkontrol. Setiap kali sebuah titik baru ditambahkan ke pohon, saya menunjukkan bahwa titik-titik tersebut berada pada satuan jarak sepanjang arah utama dari titik yang akan dianggap sebagai titik target masa depan, seperti yang terjadi pada pengisian dua dimensi yang sederhana.

Tetapi tentu saja, jika tidak hati-hati, ini akan menciptakan siklus pengambilan sampel yang tidak berguna. Poin tersebut akan bercabang ke 8 poin di sekitarnya, tetapi 8 poin ini kemudian akan mencoba lagi untuk kembali ke titik awal, dan ini akan berlanjut selamanya. Oleh karena itu, selain pemilihan titik target yang terkontrol, saya memerlukan batasan sederhana: titik target mana pun yang tidak berada dalam jarak minimum tertentu yang bermanfaat dari titik target yang ada tidak akan diperhitungkan. Yang mengejutkan saya, dua aturan sederhana ini membuat isian yang cukup sukses:


Tidak buruk untuk percobaan yang cukup sederhana. Tetapi algoritma menderita dari apa yang saya sebut "echo batas". Efek ini dapat dilihat pada tangkapan layar berikut yang diambil selama studi peta:


Di daerah tanpa hambatan, algoritma bekerja dengan baik dengan mengambil sampel pada jarak yang relatif sama. Tetapi ketika persimpangan mencapai perbatasan, mereka menciptakan titik yang "di luar kotak", yaitu, mereka tidak selaras sesuai dengan pola sampel, yang menurutnya algoritma mengisi area terbuka yang berdekatan. Alasan bahwa poin-poin "di dalam grid" tidak menciptakan tessellation yang terlalu padat adalah karena setiap titik baru yang mencoba untuk kembali ke salah satu yang sebelumnya menemukan titik sebelumnya di sana dan menolak untuk menceritakannya lagi. Tetapi ketika membuat titik baru di perbatasan, mereka sepenuhnya tidak sejajar, sehingga tidak ada yang bisa menghentikan mereka untuk kembali ke ruang yang sudah dieksplorasi. Ini mengarah pada penciptaan gelombang sampel yang bias, yang berlanjut sampai mencapai garis acak titik di tempat lain, yang cukup dekat sehingga algoritma dapat menemukannya bertepatan dengan bagian depan yang bergerak dari titik.

Meskipun ini tampaknya bukan masalah serius, ini sebenarnya penting. Inti dari algoritma tersebut adalah untuk memusatkan sampel di area di mana mereka paling mungkin menghasilkan hasil yang produktif. Semakin banyak waktu yang kita habiskan untuk pengambilan sampel dan pengambilan sampel kembali area terbuka yang luas, semakin sedikit waktu yang akan kita habiskan untuk menandai wajah-wajah area ini, yang merupakan informasi yang kita butuhkan. Karena kita berhadapan dengan ruang kontinu, dan hanya jumlah sampel tak terbatas yang dapat menggambarkan bentuk aslinya, rasio sampel signifikan dan tidak signifikan secara literal adalah ukuran efektivitas algoritma dalam menciptakan permukaan yang bisa dilewati pemain.

Namun, ada solusi sederhana untuk masalah khusus ini: Anda perlu memperluas jarak di mana dua titik dianggap "cukup dekat." Dengan melakukan itu, kami akan mengurangi kepadatan pengambilan sampel di tempat-tempat yang tidak penting bagi kami, tetapi juga kehilangan kepadatan pengambilan sampel di tempat-tempat yang penting bagi kami, misalnya, area di sekitar perbatasan yang kami ingin hati-hati memeriksa keberadaan "lubang".

Pengambilan Sampel Directional Lokal

Mungkin karena saya mulai dengan Pohon Acak yang Menjelajah Cepat, otak saya menggantikan semua gagasan lain kecuali gagasan kedekatan. Semua algoritma sebelumnya menggunakan kedekatan untuk tugas mereka, misalnya, untuk menentukan titik baru yang perlu dipertimbangkan berikutnya, atau untuk memilih titik dari mana untuk mulai sampai ke titik target baru.

Tetapi setelah memikirkan tugas itu selama beberapa waktu, saya menyadari bahwa semuanya menjadi lebih logis, jika kita berpikir tidak hanya tentang kedekatan, tetapi juga tentang arah . Maka menjadi jelas, tetapi jika Anda mengerjakan tugas-tugas serupa, maka Anda tahu bahwa mudah untuk jatuh ke dalam perangkap pemikiran picik dan tidak melihat gambaran besarnya, bahkan jika itu lebih mudah. Itulah yang terjadi pada saya.

Ketika saya mengubah pandangan saya tentang berbagai hal, pendekatan yang benar untuk pengambilan sampel tampak jelas. Setiap kali saya ingin memperluas eksplorasi ruang saya dari suatu titik, saya mengajukan permintaan untuk keberadaan titik-titik terdekat di lingkungan lokal. Namun, alih-alih menggunakan jarak ke titik-titik ini untuk penelitian, saya akan mengklasifikasikan mereka sesuai dengan arahan mereka (sebelumnya saya hanya menggunakan delapan arah utama, tetapi saya ingin bereksperimen dengan kernel lain).

Ke arah mana pun saya tidak “melihat” titik, saya pergi jarak yang ditentukan dan menambahkan titik di tempat di mana saya berhenti (terlepas dari apakah saya menemukan sesuatu atau tidak). Jika saya melihat titik di salah satu arah, saya pindah ke sana dan memeriksa apakah saya bisa sampai di sana. Jika saya bisa, maka saya hanya menambahkan tepi yang terlihat sehingga pengguna dapat dengan mudah melihat bahwa titik-titik tersebut terhubung. Jika saya tidak bisa, maka saya menambahkan titik baru di titik tabrakan, mendefinisikan batas hambatan.

Metode pengambilan sampel ini bekerja dengan baik. Hal ini memungkinkan kita untuk mengontrol pengambilan sampel secara tepat menggunakan parameter nyaman yang mudah disesuaikan, menyimpan semua poin yang diperlukan dan menghindari tessellation yang tidak perlu, yang mengarah pada pengisian ruang yang sangat cepat:


Karena algoritme melakukan pencarian sepanjang arah, dan tidak hanya menggunakan kedekatan, ia dilindungi dari gema batas dan membatasi pengambilan sampel berlebihan hanya pada batas-batas yang kami butuhkan:


Selain itu, algoritma ini sama sekali tidak terpengaruh oleh transisi negara atau masalah dengan manifold yang kompleks. Ini hanya berurusan dengan poin, dan poin ini bisa di mana saja, dan yang baru dapat ditambahkan kapan saja. Jika Anda sudah menyusun peta area dengan pintu tertutup, maka setelah membuka pintu, Anda hanya perlu menempatkan satu-satunya titik penelitian di sisi lain pintu dan memesan algoritma untuk terus memperluas peta ini, setelah itu akan terhubung dengan benar dan dengan benar memeriksa seluruh area di luar pintu.

Juga, kapan saja, Anda dapat mengubah parameter dasar, dan sistem akan terus bekerja. Ingin pengambilan sampel area dilakukan dengan kepadatan yang lebih tinggi? Turunkan jarak standarnya. Ini dapat dilakukan sudah dalam proses membangun peta, dan algoritma akan mulai pengambilan sampel dengan kepadatan yang lebih tinggi tanpa perlu mengatur ulang hasil sebelumnya (yang mungkin memakan waktu lama).

Verifikasi dasar belum sempurna

Algoritme default sudah membatasi sampel dengan sangat hati-hati, karena persimpangan membuat titik tambahan yang tidak termasuk dalam pola pengambilan sampel, tetapi tidak perlu memeriksanya dengan perawatan yang diperlukan, karena tidak melakukan tindakan khusus saat menghadapi hambatan. Saya menyadari bahwa karena saya tahu titik mana yang dibuat selama tabrakan, dua titik tabrakan yang terdeteksi terhubung oleh tepi dan kita dapat memanggil sampel tambahan untuk mencoba menemukan lebih banyak titik batas di lingkungan.

Saya tidak secara aktif meneliti pendekatan ini, tetapi menciptakan metode yang belum sempurna untuk menguji teori ini, dan itu tampak menjanjikan bagi saya. Setelah mengambil dua titik tabrakan yang dihubungkan oleh sebuah tepi, saya bergeser ke titik tengah dari tepi dan mencoba untuk menarik keluar yang tegak lurus ke tepi. Jika tidak memotong perbatasan pada jarak yang sangat pendek, maka saya berasumsi bahwa perbatasan lebih kompleks, dan menambahkan titik target baru untuk melanjutkan pencarian di area ini.

Bahkan skema sederhana ini menciptakan sampling padat berkualitas tinggi di sepanjang perbatasan tanpa perlu mengambil sampel area terbuka yang berdekatan. Berikut adalah area dengan beberapa batas, tetapi tanpa memeriksa tepinya:


Dan di sini adalah area yang sama dengan memeriksa tepi:


Tidak peduli betapa senangnya saya dengan hasil ini, saya terkejut dengan kurangnya algoritma yang secara signifikan lebih baik untuk pengambilan sampel perbatasan, dan saya akan mencoba untuk mengambil beberapa metode lagi di masa depan.

Kemenangan cepat

Meskipun hanya menginvestasikan sedikit waktu dalam pengembangan dan membuat kode yang cukup sederhana, saya memastikan bahwa Walk Monster sudah menciptakan output yang cukup cocok yang dapat mendeteksi masalah nyata dalam game. Berikut adalah contoh masalah yang saya temukan selama pengembangan algoritma:


Lereng di sisi platform ini tidak boleh dilewati, tetapi pemain bisa berjalan di atasnya. Ini terjadi karena dalam kode gerakan pemain ada cara patologis yang buruk dalam memproses geometri miring. Sekarang saya tahu bahwa dia ada di sana, dan saya akan memperbaikinya untuk memastikan keandalannya.


Saksi seharusnya menjadi permainan kontemplatif, tetapi bertanya-tanya mengapa tampaknya ada batu, meskipun bukan, bukan salah satu dari koansnya. Seperti yang Anda tebak, masalah ini muncul karena seseorang meninggalkan jumlah tabrakan dalam permainan setelah menghapus geometri yang menunjukkannya. Ini dapat dengan mudah terjadi, dan sangat baik bahwa kami memiliki alat yang dapat dengan cepat mengenali kesalahan tersebut sehingga orang tidak perlu melakukannya.



Benda-benda ini seharusnya adalah batu yang tidak bisa dilewati, tetapi Walk Monster menemukan bahwa ini tidak terjadi. Lebih buruk lagi, Walk Monster menemukan bahwa karena alasan tertentu jalannya hanya satu arah (dari tangkapan layar dari kiri ke kanan), tetapi ini tidak boleh terjadi. Saya memastikan bahwa pemain benar-benar dapat melakukan ini (saya berhasil). Sangat menarik untuk mengamati terjadinya kesalahan seperti itu!

Pertanyaan terbuka

Ketika Anda melihat hasil yang baik yang dapat dikembangkan lebih lanjut, itu menginspirasi. Seperti yang saya katakan, jika Anda memilih nama yang cocok untuk file sumber, maka semuanya akan berjalan seperti jam! Tetapi semua pekerjaan ini selesai hanya dalam beberapa hari, jadi itu jauh dari lengkap, dan banyak yang telah dilakukan sepenuhnya diimprovisasi. Jika saya punya cukup waktu untuk pengembangan lebih lanjut dari sistem ini, maka ada baiknya menjawab beberapa pertanyaan.

Pertama, apa yang perlu dilakukan pasca pengolahan dengan data sehingga lebih mudah untuk divisualisasikan? Akan sulit bagi orang untuk mengetahui jaringan titik dan tepi yang tidak diproses, tetapi jika Anda meningkatkan deskripsi data, ini mungkin akan membuat sulit untuk mengevaluasi area yang sulit dilewati pada pandangan pertama.

Kedua, bagaimana pola pengambilan sampel di sekitar perbatasan dapat ditingkatkan untuk memastikan bahwa jumlah "lubang" maksimum ditemukan? Adakah cara yang baik untuk mengkarakterisasi pengurangan angka menjadi kisi, dan adakah skema tesselasi berkualitas tinggi yang memaksimalkan kemungkinan melintasi dan melewati angka-angka ini?

Ketiga, pola pengambilan sampel mana yang paling baik untuk mengisi ruang - teratur atau acak? Saya dapat dengan mudah mengubah kriteria untuk memilih poin target untuk membuat lebih banyak pola acak, tetapi tidak begitu jelas apakah ini layak dilakukan, dan jika demikian, jenis pola acak apa yang akan lebih baik.

Keempat, informasi lain apa yang ingin kita dapatkan dari peta area yang bisa dilewati jika kita sudah belajar bagaimana membangunnya? Misalnya, sangat mudah untuk memperluas sistem yang ada dengan fungsi seperti mencari jalur atau peta jarak, sehingga pengguna dapat memilih titik dan meminta jalur terpendek di antara itu dan beberapa titik lain, atau melihat peta panas jarak antara titik dan titik lain dari peta. Apakah pertanyaan seperti itu akan membantu? Pertanyaan apa lagi yang bisa saya gunakan?

Saat ini, visualisasi Walk Monster dari area yang dapat dilewati lebih dari cukup untuk menunjukkan bahwa kode gerakan pemain sangat buruk. Saya berencana untuk beralih ke menciptakan sistem untuk pengujian kartu malam menggunakan metode simulasi input pengguna, tetapi jelas bahwa kita sudah memiliki cukup banyak masalah untuk dipecahkan tanpa langkah ini. Oleh karena itu, langkah selanjutnya adalah meningkatkan keandalan kode gerakan pemain. Dan ketika saya sedang mengerjakan ini, saya ingin memeriksa apakah mungkin untuk meningkatkan kecepatan eksekusi sebesar satu atau dua urutan, karena sementara pekerjaan Walk Monster sangat diperlambat oleh sistem rem tabrakan.