Cara membuat mekanik game yang andal hanya menggunakan Excel: pemodelan dan optimalisasi solusi

Kami sedang mencari, bukan iterasi

Desain game pada dasarnya adalah proses pencarian . Terlibat dalam desain, kami mengeksplorasi banyak konfigurasi desain yang mungkin untuk memecahkan masalah desain tertentu. Misalnya, ini bisa menjadi cara menghubungkan kamar di ruang bawah tanah, serangkaian fungsi dan keterampilan yang dimiliki berbagai agen game, "angka ajaib" yang menentukan efektivitas unit dalam sistem pertempuran, atau kombinasi kemampuan yang akan hadir dalam permainan kami.

Sama seperti karakter yang dikendalikan AI menggunakan sistem pencarian jalur untuk menavigasi dunia game, seorang desainer perlu menavigasi ruang tingkat tinggi dari kemungkinan konfigurasi, mengambil beberapa konfigurasi awal dan mengubahnya secara iteratif. Kami dengan cermat mempertimbangkan aspek terpisah dari desain - sistem pertempuran, salah satu bagian dari dunia game, pohon teknologi dalam strategi - dan mencoba menemukan cara untuk memperbaikinya dengan mengubah konfigurasi ini.

Desainer suka menggunakan istilah "iterasi" untuk menggambarkan proses ini, tetapi kata "pencarian" akan lebih cocok di sini. Yang benar adalah ketika kita membuat "iterasi" desain, kita bereksperimen dengan game yang sedang dikembangkan. Kami membuat asumsi yang masuk akal tentang set kecil modifikasi yang mengubah konfigurasi desain saat ini menjadi yang baru, yang, menurut pendapat kami, akan lebih memenuhi kriteria desain.

"Iterasi" seperti itu sama sekali tidak seperti perubahan linear yang biasanya terjadi pada "iterasi" kode komputer; jauh lebih mirip pencarian dalam labirin dengan banyak belokan tajam dan pengembalian paksa. Seringkali mereka membawa kita lebih dekat ke gawang, tetapi seringkali tidak jelas apakah permainan telah membaik dari mereka. Kadang-kadang ternyata perubahan desain, yang, menurut pendapat kami, seharusnya meningkatkan permainan, memiliki kekurangan yang tidak terduga dan kami perlu mengembalikannya atau mencoba lagi.

Desain game adalah disiplin yang sangat kompleks. Desainnya seperti ruangan gelap dengan banyak benda tajam; sangat sulit untuk bergerak dengan aman di sepanjang jalan itu, menjauh dari jalan yang dilalui dengan baik. Hampir selalu luka yang menyakitkan menunggu kami di sepanjang jalan, terutama jika Anda bergerak terlalu cepat. Dan kami memiliki beberapa alat untuk menerangi ruangan gelap ini, serta beberapa teknik yang jelas dan terperinci untuk melakukan proses pencarian desain.



Karena keberadaan ruangan gelap ini, kami melakukan "iterasi" - kami tidak tahu apa konsekuensi dari keputusan itu sampai kami memeriksanya. Dengan kata lain, kita sedang dalam pencarian (Will Wright dalam ceramahnya di GDC 2004 menyebutnya "pencarian di ruang solusi").

Oleh karena itu, sangat sering desain menjadi hambatan kinerja, sumber kelemahan utama dan faktor risiko terbesar dalam pengembangan game. Tim pengembangan yang tak terhitung jumlahnya ternyata diikat tangan dan kaki oleh solusi desain yang salah, tergelincir dalam proses kreatif, perubahan fungsi, kesalahan persepsi pasar target dan masalah desain lainnya yang menyebabkan masalah kualitas produk.

Mengingat semua bahaya yang terkait dengan eksperimen desain, tidak mengherankan bahwa banyak penerbit dan pengembang besar begitu bersemangat untuk menghindari risiko, lebih memilih untuk secara ketat mematuhi asumsi genre, lisensi, dan genre yang telah diteliti dan diteliti dengan baik. Itu sebabnya mereka tidak pergi ke risiko terkenal dari inovasi desain yang mungkin membawa hasil yang tidak diketahui. Menjelajahi ruangan gelap terlalu berisiko.

Kami ingin menemukan cara untuk mengubah sikap ini. Daripada hanya menghindari inovasi, lebih baik mencari cara untuk meningkatkan keterampilan desain kami, memperluas kemampuan kami dan membuat alat yang kuat yang akan membuat inovasi desain lebih aman dan lebih efisien.

Seri artikel ini

Artikel ini akan menjadi yang pertama dari serangkaian posting tentang solusi pemodelan - seperangkat alat untuk menguraikan solusi menjadi model formal, yang kemudian dapat digunakan untuk mencari untuk menemukan hasil yang paling diinginkan.

Pemodelan dan optimalisasi keputusan sering digunakan dalam manajemen, keuangan, perencanaan proyek dan banyak bidang lainnya untuk meningkatkan proses pengambilan keputusan dan menyelesaikan berbagai masalah dan optimisasi pengambilan keputusan. Ini dilakukan dengan mencari di antara alternatif yang mungkin, yang lebih cepat daripada pilihan manual oleh orang-orang.

Terlepas dari semua potensi keuntungannya, pemodelan, dan optimalisasi solusi, tampaknya ini menjadi topik yang cukup belum dijelajahi untuk para desainer di industri game. Sebuah survei terhadap desainer profesional di forum pengembang populer menunjukkan bahwa hanya 25% responden yang setidaknya mendengar tentang pemodelan keputusan, dan hanya 8% yang menggunakannya dalam praktik. Survei serupa yang dilakukan antara desainer melalui Facebook menunjukkan hasil yang kurang lebih sama dengan jumlah responden yang sama.


Ketika digunakan dengan benar, solusi pemodelan dapat secara signifikan meningkatkan banyak aspek dari proses desain:

• Ini dapat membantu mengoptimalkan konfigurasi sistem desain tertentu atau nilai optimal dari parameter game.
• Ini dapat menjelaskan keputusan sebagai kombinasi fitur yang perlu dimasukkan dalam permainan.
• Ini membantu memodelkan keputusan yang dapat dibuat oleh seorang pemain, khususnya, untuk mengidentifikasi strategi dominan atau cara-cara di mana pemain mampu "mengalahkan sistem".

Dalam seri artikel ini saya akan berbicara tentang contoh-contoh dari ketiga kategori penggunaan.

Definisi

Apa itu "pemodelan keputusan"?

Sederhananya, maka:

Pemodelan keputusan adalah proses simulasi solusi dengan otomasi pencarian pencarian kalkulasinya berikutnya.

Kami mulai dengan menanyakan beberapa jenis solusi, kemudian kami mencoba untuk memilih semua faktor yang terdiri dari solusi ini, dan kemudian menanamkannya dalam model yang secara akurat menggambarkan solusi, dan menentukan set variabel input dan satu variabel output. Kemudian kami mencari solusi optimal untuk set variabel keputusan (atau variabel input) yang menciptakan output terbaik dari semua kemungkinan.

Jika semuanya dilakukan dengan benar, maka kita dapat mencari lebih banyak solusi yang mungkin daripada yang dilakukan secara manual atau dalam imajinasi. Meskipun kami tidak dapat menerapkan sistem ini untuk semuanya, untuk beberapa tugas kami bisa mendapatkan hasil yang lebih baik, menghitungnya lebih cepat, dan dalam beberapa kasus kami bahkan dapat memecahkan masalah yang tidak dapat diselesaikan dengan cara lain.

Selama proses ini, kami juga menunjukkan sejumlah satu atau lebih kondisi , yang digunakan sebagai batas yang mengkonfirmasikan kebenaran model kami. Kondisi tersebut dapat membatasi rentang nilai atau jenis variabel yang masuk, serta aspek lain dari model kami.

Mengapa membangun model?

Jika Anda memainkan Sid Meier's Civilisation , maka suatu hari Anda mungkin bertanya-tanya, “Tunggu sebentar, bagaimana cara terbaik untuk memulai pengembangan kota? Apakah saya perlu membangun monumen, dan kemudian gudang? Atau apakah gudang diperlukan terlebih dahulu? Atau mungkin kuil dulu, lalu gudang? Keputusan mana yang lebih baik untuk dibuat? Adakah yang bisa menjawab pertanyaan ini? "

Anda juga dapat mengingat mekanisme pertempuran dalam strategi waktu-nyata. Menyeimbangkan parameter beberapa unit dalam RTS adalah tugas yang terkenal karena kompleksitasnya. Bagaimana jika kita memiliki sistem yang memungkinkan kita untuk mempercepat solusi dari masalah keseimbangan dengan menjawab pertanyaan tentang menyeimbangkan pertempuran permainan tanpa memainkan setiap solusi? Bagaimana jika kita dapat mengajukan pertanyaan sistem? Misalnya: "berapa banyak pendekar pedang yang Anda butuhkan untuk mengalahkan dua pemetik dan tiga pemanah?" Atau: "Apa kombinasi termurah dari pemanah dan ketapel untuk mengalahkan menara pengawal musuh?"

Bahkan, sistem seperti itu dapat dibuat!

Jika kita dapat memodelkan tugas-tugas desain ini dengan cara yang benar, maka kita dapat menggunakan alat optimasi otomatis untuk mencari semua jawaban yang mungkin untuk menemukan jawaban yang paling sesuai dengan kriteria kita, tanpa harus memainkan permainan ribuan kali.

Berikut adalah contoh masalah serupa - contoh yang akan kami pecahkan dalam artikel mendatang di seri ini.

Katakanlah kita memiliki permainan yang disebut SuperTank. Di SuperTank, kami mengendarai tank fantastis besar yang bertarung di medan perang dengan tank super lainnya. Sebelum setiap pertempuran, kita dapat memilih kombinasi senjata tertentu untuk tank kita.


Kami memiliki 100 kredit yang dapat Anda pakai untuk peralatan. Supertank pemain dapat membawa 50 ton senjata, dan juga memiliki 3 slot "kritis" untuk senjata berdaya tinggi khusus.

Gim ini memiliki lima jenis senjata berikut, dan pemain dapat menggunakan jumlah apa pun dari setiap jenis, atau sepenuhnya mengabaikannya:


Misalkan kita memerlukan supertank untuk memiliki nilai kerusakan setinggi mungkin (kita mengasumsikan bahwa kerusakan per detik ditunjukkan, terlepas dari kecepatan senjata). Kami juga berasumsi bahwa semua senjata memiliki jangkauan yang sama, lintasan proyektil, akurasi dan frekuensi tembakan, yaitu, mereka identik dalam segala hal kecuali nilai-nilai yang ditunjukkan dalam tabel.

Sekarang cepat jawab berapa banyak senapan mesin, roket, laser, dll. perlu ditempatkan di tangki super? Kombinasi satu atau lebih jenis senjata apa yang akan memberi kita paling banyak kerusakan, sementara tidak melebihi batas berat, harga, dan slot kritis?

Cobalah untuk menyelesaikan masalah secara manual atau menggunakan kalkulator.

Bisakah ini dilakukan?

Jika Anda mencoba, maka dengan cepat pastikan itu sangat sulit.

Mungkin ada cara untuk menyelesaikannya dengan menggunakan persamaan matematika yang kompleks, tetapi kita adalah desainer, dan matematika bukanlah urusan kita.

Pikirkan juga bagaimana jawaban akan berubah dengan parameter lain. Akankah jawabannya berubah jika bukannya 50 ton tangki super dapat menampung 60? Atau jika alih-alih 100 pinjaman kita memiliki 110 atau 90? Bagaimana perubahan gigi yang optimal? Dan jika kita memiliki 2 atau 4 slot kritis?

Sekarang bayangkan bahwa kita memiliki sistem yang secara instan menghitung tata letak senjata dengan kerusakan terbesar untuk setiap set parameter (Bobot, Harga, Slot Kritis). Cukup memasukkan parameter senjata dari tabel, lalu masukkan parameter supertank (50 ton, 100 kredit, 3 slot kritis) - dan BOOM! - kami mendapat peralatan terbaik.

Bukankah itu luar biasa?

Kita dapat menggunakan sistem ini untuk secara instan mendapatkan jawaban untuk semua jenis pertanyaan berguna:

• Bagaimana skema optimal akan berubah ketika parameter tangki super berubah?
• Bagaimana peralatan optimal akan berubah ketika mengubah parameter senjata?
• Apa yang dapat dilakukan kerusakan maksimum oleh supertank untuk parameter apa pun (Bobot, Harga, Slot Kritis)?
• Apakah keempat parameter senjata (Kerusakan, Berat, Harga, Slot Kritis) sesuai dan seimbang untuk setiap jenis senjata?
• Apakah kita memiliki senjata terlalu kuat yang terlalu sering digunakan? Jika semua jenis senjata sangat berguna sehingga selalu benar untuk menggunakannya, maka itu akan selalu menjadi solusi optimal, sehingga tidak akan ada pilihan yang berarti. Dalam hal ini, kita harus menghapus senjata dari permainan, atau mengubah keseimbangannya sehingga dalam kondisi tertentu itu tidak berguna.
• Apakah kita jarang atau tidak pernah menggunakan senjata? Mirip dengan paragraf sebelumnya - jika beberapa jenis senjata sangat tidak berguna sehingga keputusan yang tepat adalah untuk tidak menggunakannya, maka tidak ada pilihan yang signifikan juga. Dalam hal ini, ada baiknya melepaskan senjata dari permainan, atau mengubah keseimbangannya, sehingga dalam kondisi tertentu akan bijaksana untuk menggunakannya.

Semua ini adalah pertanyaan desain yang sangat penting, jawaban yang harus diketahui oleh perancang. Mengetahui jawaban ini akan sangat berguna saat menyeimbangkan gim SuperTank .

Hanya dalam beberapa paragraf, kami menggambarkan tugas yang sangat sulit bagi kami untuk dipecahkan secara manual, tetapi yang dipecahkan dengan menggunakan alat yang dibangun ke dalam Microsoft Excel.

Dalam artikel mendatang, kami akan membangun model solusi nyata untuk contoh ini, yang akan menjawab semua pertanyaan di atas.

Anda akan melihat bahwa model yang dapat dibuat dalam hitungan menit akan memungkinkan Anda untuk menyelesaikan tugas yang sulit ini. Hanya dalam waktu singkat, kami akan menciptakan alat yang kuat yang memungkinkan kami untuk dengan cepat dan andal menjelajahi ruang desain.

Peta jalan

Dalam seri artikel ini, kami akan mengilustrasikan beberapa contoh yang lebih kompleks, dan membuat lembar bentang referensi sehingga Anda dapat menjalankan semua contoh ini sendiri, hanya menggunakan Excel yang diinstal dari alat. Di antara contoh-contoh ini adalah sebagai berikut:

• Contoh sederhana pertempuran untuk game strategi
• Sebuah model untuk mengoptimalkan koordinat dari beberapa teleport "lubang cacing" relatif satu sama lain dan sektor yang dihuni dalam game multiplayer ruang massal (MMO)
• Model yang menentukan tingkat pajak untuk model kota yang disederhanakan untuk menyeimbangkan kepuasan penduduk dan pendapatan pajak dalam strategi 4X seperti Peradaban Sid Meier
• Model untuk memilih mantra dan keterampilan untuk kelas karakter dalam gim multipemain masif
• Model optimasi untuk menentukan urutan konstruksi optimal untuk koloni planet dalam strategi 4X mirip dengan Master of Orion klasik
• Contoh tim yang mencoba menemukan kombinasi fitur yang tepat untuk sebuah game, dan model keputusan untuk membantu mereka memilih kompromi yang sesuai

Secara umum, seri ini akan terdiri dari contoh-contoh sederhana untuk menemukan strategi pemain yang optimal dalam subsistem spesifik permainan, dan kemudian beralih ke model keputusan yang mengoptimalkan parameter sistem permainan dan mengoptimalkan kombinasi set "fitur".

Dalam setiap kasus ini, kami menjelaskan tugas, menunjukkan bagaimana memodelkannya di Excel dan menyelesaikannya menggunakan alat Solver bawaan (dalam versi Rusia - "Finding Solutions") dari Excel. Dalam setiap kasus, Anda akan melihat bahwa kami dapat membuatnya lebih mudah, lebih cepat, dan lebih dapat diandalkan daripada tanpa menggunakan Solver atau alat serupa. Juga untuk setiap contoh, saya akan menambahkan spreadsheet sehingga Anda dapat mengunduhnya dan memeriksanya sendiri, membuat ulang hasil dan bereksperimen dengan model Anda sendiri.

Juga, jangan lupa bahwa representasi internal - apakah itu spreadsheet, program bahasa tingkat tinggi, atau yang lain - tidak masalah . Yang penting bukanlah apa yang kita kerjakan - di Excel dan Solver, Java / C ++ / C #, atau dalam hal lain, tetapi fakta bahwa kita memodelkan tugas dan berusaha untuk menyelesaikannya.

Mengapa menggunakan model keputusan?

Beberapa pembaca mungkin skeptis sekarang. Tampaknya membangun model keputusan banyak pekerjaan. Mengapa semua upaya ini diperlukan jika kita dapat melakukan pengujian khusus dalam bentuk pengujian grup fokus dan pengujian beta?

Untuk mulai dengan, saya akan mengatakan bahwa solusi pemodelan tidak berlaku untuk setiap tugas . Beberapa tugas terlalu rumit atau terlalu sulit untuk dimodelkan menggunakan teknik seperti itu, di samping itu, ada banyak aspek dalam desain (misalnya, pertimbangan estetika, nilai permainan sebagai hiburan dan "sensasi" permainan) yang sulit atau bahkan tidak mungkin untuk dimodelkan secara numerik. Dan solusi pemodelan jelas tidak menghilangkan kebutuhan untuk pengujian kelompok, pengujian beta, atau setiap hari memainkan proyek Anda sendiri dalam proses pengembangannya.

Tetapi bahkan dengan semua ini dalam pikiran, pada akhir seri artikel akan menjadi jelas bagi Anda bahwa metode pemodelan dan optimalisasi solusi memberi kita seperangkat alat yang unik dan kuat. Mereka dapat sepenuhnya atau sebagian menyelesaikan banyak masalah yang tidak dapat diselesaikan dengan cara lain, serta memberi Anda jawaban dan informasi tentang semua jenis masalah desain yang sulit didapat dengan cara lain.

Seperti halnya alat lain, penggunanya harus memutuskan penerapannya.

Ada banyak kasus di mana model keputusan mungkin tidak dapat diterima atau terlalu rumit. Tetapi seperti yang akan Anda lihat dalam serangkaian artikel, mereka juga sangat berguna, dan semakin kita membuat keputusan desain yang tepat dan menghilangkan bug pada tahap awal, bahkan sebelum tahap pengujian, semakin besar kemungkinan sistem desain akan tahan lama, menarik dan tidak salah lagi.

Pikirkan tentang alat yang tersedia untuk programmer biasa. Pekerjaan programmer sangat rumit, tetapi disederhanakan oleh banyak alat untuk membantu menemukan bug bahkan sebelum tahap pengujian. Mereka memiliki kompiler yang selalu mengingatkan Anda tentang kesalahan ketik yang dibuat; mereka memiliki praktik pemrograman defensif yang mengidentifikasi cacat perangkat lunak; mereka melakukan tinjauan kode yang membantu mengidentifikasi kelemahan dalam kode orang lain atau menunjukkan praktik pemrograman jahat; selain itu, mereka memiliki banyak profil dan alat analisis statis untuk menyingkirkan semua jenis bug kinerja dan cacat lainnya.

Tetapi desainer tidak memiliki alat seperti itu. Kita dapat mengatakan bahwa pekerjaan kita juga rumit, tetapi kita tidak memiliki kompiler yang akan memberi tahu kita bahwa kita “membuat kesalahan sintaks”.Kami tidak memiliki profiler, atau alat debugging, atau alat analisis statis. Kami tidak dapat melakukan tinjauan kode karena kami tidak memiliki "kode". Kami menulis spesifikasi dan dokumen desain, dan itu saja; kita dapat bertukar dokumen dan spesifikasi fungsi di dalam tim dan berharap kolega kita akan memberi kita umpan balik yang baik, tetapi paling sering kita perlu memasukkan sistem ke dalam permainan untuk memahami apakah itu berfungsi atau tidak.

Ini membuat desainnya sangat berisiko, panjang, dan mahal.

Seperti dalam kasus pemrograman, orang cenderung membuat kesalahan dan ini merupakan bagian integral dari proses, jadi kami membutuhkan alat berkualitas tinggi sebanyak mungkin untuk melindungi diri dan proyek kami.

Kami masih sangat jauh dari memiliki alat desain penuh yang membantu desainer dalam menjelajahi ruang desain. Kita masih harus mengikuti jalur yang telah dilakukan oleh kompiler, debugger, profiler, dan alat analisis statis dalam pemrograman. Tapi kita sudah melihat fajar beberapa pemecah spesifik dan alat desain gim, termasuk tester playability dari versi Cut the Rope yang disebut Cut the Rope: Play Forever ( tautan ); Sistem desain permainan abstrak Ludi, yang menghasilkan permainan papan Yavalath ( tautan ); dan asisten otomatis Evolver saya sendiri untuk menyeimbangkan permainan seluler City Conquest ( tautan ).

Solusi pemodelan akan membantu kita mengambil beberapa langkah lagi ke tingkat dukungan seperti itu dan akan memungkinkan kita untuk mulai melengkapi dan memperluas kecerdasan desainer kita sendiri dengan bantuan alat otomatis. Dan jika kita memiliki pilihan: memiliki atau tidak memiliki alat, mengapa memilih "tidak memiliki"?

Yang utama bukan spreadsheet, yang utama adalah model

Seri artikel ini ditulis untuk para desainer - yaitu, untuk semua desainer, terlepas dari jenis pengalaman apa yang mereka miliki: seni, perangkat lunak, pengalaman dalam menciptakan cerita atau permainan papan. Karenanya, kami tidak akan menyulitkan dan menjanjikan hal-hal berikut:

• . Microsoft Excel Solver (« »). , Excel, . , , ( ) .

• (, , ). , : , , , . .

• Tidak ada spreadsheet empat dimensi ; kita hanya akan menggunakan dua dimensi.

Jika Anda seorang desainer, seri artikel ini akan memberi Anda semua alat yang Anda butuhkan untuk membuat model solusi sendiri tanpa perlu kode atau programmer untuk menulis kode. Jika Anda seorang programmer, seri ini akan memberi Anda instruksi yang cukup mudah untuk memrogram model solusi Anda sendiri dalam bahasa Java apa pun sehingga Anda dapat membangun model solusi Anda sendiri, baik dari awal atau berdasarkan pada templat yang sudah digunakan di Solver dan di Excel.

Artikel-artikel ini harus menjadi titik awal sehingga Anda dapat mengambil konsep yang disajikan di sini dan memilih sendiri: apakah akan menerapkannya di Excel, apakah akan memilih alat pengoptimalan lain, atau mencoba membangun solver Anda sendiri dalam bahasa tingkat tinggi. Spreadsheet adalah fondasi yang solid untuk memulai, tetapi model keputusan seperti itu lebih cenderung menjadi batu loncatan Anda ke model yang lebih kaya dan lebih kompleks yang berintegrasi dengan arsitektur gim Anda.

Penjelasan

Sebelum kita terlalu jauh dalam solusi pemodelan, kita perlu memberikan beberapa penjelasan. Pemodelan dan optimalisasi solusi tidak menciptakan sistem lengkap untuk desain game, dan kami tidak akan mengatakan hal seperti itu. Sangat berguna untuk melihatnya sebagai alat yang membantu dalam beberapa aspek dari proses desain, dan seperti alat lainnya, alat ini memiliki banyak keterbatasan.

Berikut adalah beberapa batasan yang perlu Anda ketahui:

• . , , . , , . , , , , , .

• (). , . « », , Excel. ( / ), ( ), .

• . , - , , «» . . , , /, .

• . , Excel Solver, , , , . Solver , . , , « » . Solver ( Frontline ) , , Solver .

• Mereka tidak menjamin optimalitas . Karena kami bekerja dengan model yang kompleks, tidak mungkin 100% yakin bahwa kami telah menemukan solusi optimal . Terkadang kita harus fokus pada yang terbaik kedua: kita akan menghabiskan lebih banyak waktu untuk optimasi atau mulai dari awal dan mengoptimalkan lagi sehingga kita dapat mengatakan dengan tingkat kepercayaan yang tinggi bahwa kita telah menemukan yang optimal atau sangat dekat dengan solusi optimal.

Terakhir dan yang paling penting:

• Kita perlu memastikan bahwa model melakukan hal yang benar . Tidak semua tugas cukup penting untuk memerlukan upaya seperti itu, kita perlu mengetahui prioritas kita secara tepat dan menghindari fokus yang tidak perlu pada mengoptimalkan tugas yang tidak berguna dan mengabaikan yang lain, yang lebih besar, yang bisa jauh lebih penting.

Secara sederhana, agar solusi pemodelan berguna, beberapa kondisi harus dipenuhi. Kita harus dapat menanamkan solusi yang dimaksud dalam model diskrit tertentu, dan menyatakan hasil solusi sebagai nilai tunggal. Dengan kata lain, kita harus bisa mengekspresikan, menggunakan model solusi, satu set input data hingga dalam satu nilai output sehingga meminimalkan atau memaksimalkan nilai output memberi kita solusi yang lebih baik.

Dalam kasus di mana ada aspek subyektif yang tidak dapat tertanam dalam model ini, misalnya, aspek estetika atau aspek usability / playability, kita perlu memisahkannya dengan jelas dari model keputusan, atau menggunakan pemodelan keputusan sebagai pass pertama, atau hanya meninggalkan pemodelan keputusan sepenuhnya .

Agar kita dapat memodelkan solusi dalam spreadsheet, kita juga perlu membatasi kerumitan model. Jika game kami melakukan sesuatu yang sangat kompleks, kami mungkin tidak dapat membuat ulang kompleksitas ini di Excel. Namun, harus diingat bahwa ini hanya keterbatasan kekuatan model yang dapat dibangun di Excel, dan bukan dari model keputusan itu sendiri. Di mesin gim kami sendiri, kami dapat membangun pemecah yang jauh lebih kuat, dan saya harap seri artikel ini akan menginspirasi Anda untuk melakukan hal itu.

Di sisi lain, semua keterbatasan ini tidak mungkin membuat pemodelan keputusan menjadi sia-sia. Bahkan dalam kasus ketika tugas terlalu rumit untuk optimasi lengkap dalam model solusi, model ini masih dapat membantu kita memilih banyak komponen desain yang jauh lebih dekat dengan konfigurasi yang benar, serta menemukan dan men-debug banyak tugas dasar bahkan pada tahap awal pengembangan.

Dan bahkan ketika model solusi tidak dapat menemukan solusi optimal untuk masalah tersebut, baik karena tugasnya terlalu rumit, atau karena itu memerlukan pendekatan estetika dan faktor manusia subjektif lainnya, itu masih dapat membantu mempersempit batas-batas solusi, menghilangkan kebuntuan dan sebaliknya mengurangi kompleksitas masalah. .

Akhirnya, bahkan jika Anda memutuskan untuk tidak menggunakan pemodelan keputusan, jangan mencoba untuk mengoptimalkan spreadsheet atau membuat solver Anda sendiri, pemahaman tentang pemodelan keputusan masih akan membantu Anda berubah pikiran tentang membuat keputusan desain.

Seri artikel ini adalah studi. Kami akan melihat banyak contoh tugas desain game dan mengeksplorasi cara pemodelan dan optimasi yang disediakan oleh alat desain yang kuat. Anda mungkin skeptis atau memutuskan untuk tidak menggunakan optimasi sama sekali, tetapi saya harap Anda akan mengikuti penelitian kami dan mencari tahu bagaimana kami akan mengakhiri seri ini.

Kesimpulan

Pada akhirnya, kami ingin membuat desain dengan benar .

Banyak pertanyaan desain bersifat subyektif, mereka tidak memiliki jawaban "benar" atau "salah". Tapi mereka tentu, dalam beberapa kasus ada . Dan dalam kasus seperti itu, kita perlu tahu bagaimana mendapatkan jawaban yang benar, atau paling tidak memahami bagaimana menangani definisi dari jawaban yang “benar” dan mencari solusinya.

Pemodelan dan optimalisasi solusi adalah alat yang kuat yang membantu kami dalam banyak hal Saya percaya bahwa alat seperti itu harus di alat masing-masing desainer. Setelah beradaptasi dengan mereka, Anda akan menyadari bahwa alat-alat ini memiliki potensi besar yang belum direalisasi dalam studi yang lebih cepat dan lebih dapat diandalkan dari ruangan gelap desain game. Dalam serangkaian artikel kami, kami akan menunjukkan berapa banyak kegunaannya.

Bagian 2. Dasar-dasar optimasi dan penyebaran simulasi

Spreadsheet untuk artikel ini dapat diunduh di sini .

Persiapan Model Solusi

Sekarang kita telah berbicara tentang model solusi, menjelaskan bagaimana mereka berguna, dan mendaftar beberapa keterbatasan mereka, kami ingin menggambarkan konsep-konsep dasar dengan contoh sederhana.

Tetapi sebelum kita melakukan ini, kita perlu memperkenalkan beberapa aturan mengenai struktur dan format. Seperti halnya kode, jika Anda tidak berhati-hati, spreadsheet dapat dengan cepat berubah menjadi kekacauan.

Secara sederhana, akan ada empat jenis sel dalam spreadsheet kami:

• — , — , . 0 - , . , , . .
• « » — . , , Tootsie Pop 17 0,25 , « ». .
• «» — , . .
• "Tujuan" (atau "keluar") adalah sel yang nilainya kami berusaha untuk meminimalkan (atau memaksimalkan) ketika pengoptimal berjalan Dalam contoh kami, selalu ada hanya satu sel target, selalu memiliki warna oranye dan garis hitam. ( Catatan: ada banyak pemecah yang lebih kuat yang mendukung bekerja dengan banyak tujuan, tetapi untuk artikel kami itu akan terlalu rumit.)

Ketika kami menjalankan pengoptimal (alat Solver ("Solution Finder") yang dibangun di dalam Microsoft Excel), itu hanya akan melihat sel target yang kami tentukan dan kemudian mencoba untuk mengubah variabel keputusan, tetapi dapat (dalam batas yang kami tetapkan) atau meminimalkan, atau meminimalkan, atau maksimalkan nilai sel target ini (apa pun yang kami tentukan).

Solver hampir tidak tahu apa-apa tentang perhitungan yang terjadi di dalam, atau tentang hubungan antara sel keputusan dan sel tujuan; ia hanya melakukan salah satu dari beberapa algoritma yang tersedia untuknya, mencoba untuk meminimalkan atau memaksimalkan nilai sel target dengan mencari nilai-nilai yang mungkin dari sel solusi. Algoritme seperti itu ("LP Simplex", "GRG Nonlinear", "Evolutionary") dirancang sedemikian rupa sehingga mereka jauh lebih pintar daripada menjelajahi semua opsi yang mungkin untuk solusi variabel dengan brute force, dan sangat sering menemukan jawaban untuk masalah serius dengan efisiensi luar biasa.

Misalnya, jika kami ingin tahu berapa kali Anda perlu menjilat untuk sampai di tengah Tootsie Pop, kami dapat menggunakan spreadsheet yang serupa:


Kita dapat meminta Excel Solver untuk menyelesaikan masalah ini dengan memesannya untuk meminimalkan sel target "Massisa di Tootsie Pop", dan dia akan dengan cepat menggunakan eksperimen menentukan bahwa nilai sel solusi kuning memberikan hasil seperti itu ( "Berapa kali menjilat untuk sampai ke tengah Tootsie Pop") adalah 68.

Tentu saja, melakukan ini sedikit bodoh, karena dari pernyataan masalah jelas bahwa jawabannya adalah 17 / 0,25 = 68. Tidak masuk akal untuk menjalankan optimizer untuk memecahkan masalah yang dapat diselesaikan dengan aritmatika sederhana.

Namun, dalam praktiknya, sebagian besar masalah yang kita hadapi tidak akan memiliki solusi matematika sederhana. Mereka akan memiliki banyak variabel keputusan yang mengarah ke tujuan dengan cara yang tidak jelas, dan mencocokkan variabel keputusan dan output akan terlalu rumit untuk secara manual menghitung persamaan matematika (dan sekali lagi, dalam seri ini kita akan dengan cermat menghindari matematika yang rumit).

Kami akan fokus pada deskripsi tugas, dan meninggalkan semua kerja keras untuk Solver.

Contoh 1: pajak

Dalam model keputusan nyata pertama kami, kami akan menunjukkan contoh penentuan tarif pajak yang optimal. Tidak ada yang suka pajak, tetapi dalam hal ini kami tidak akan membayar, tetapi menerima pajak; Saya harap ini akan mengurangi siksaan Anda.

Bayangkan kita menciptakan strategi 4X mirip dengan Peradaban Sid Meier . Kami sedang dalam proses menciptakan kota dengan tingkat ketidakpuasan tertentu, tergantung pada ukurannya. Penduduk yang “tidak puas” pada dasarnya tidak cenderung bekerja sama, dan kami tidak menerima penghasilan dari mereka. Kita juga dapat mencoba mendapatkan uang dari kota-kota dengan mengubah tarif pajak setiap kota, tetapi dengan kenaikan tarif pajak, tingkat ketidakpuasan akan tumbuh secara eksponensial, sehingga pajak yang sangat tinggi menjadi kontraproduktif.

Misalkan kita dapat menunjukkan tarif pajak dengan kenaikan 10% dalam kisaran nilai dari 0% hingga 50%. Berikut adalah tangkapan layar yang menunjukkan sistem serupa dari strategi 4X klasik Master of Orion 2 :


Sebagai desainer, kami ingin mengajukan pertanyaan sederhana: apa yang akan menjadi tarif pajak optimal dalam kasus umum?

Ini harus menjadi tugas yang sederhana, karena hanya ada 6 nilai tarif pajak yang dapat diterima. Kita cukup menguji masing-masing dari 6 nilai secara manual, menemukan nilai yang memberi kita penghasilan terbesar, dan dalam hal ini masalah tersebut dipecahkan!

(Bahkan, Anda mungkin dapat menemukan persamaan matematika untuk menyelesaikan masalah ini, seperti dalam contoh dengan Tootsie Pop, tetapi itu akan menjadi kontraproduktif, karena kami sedang mempersiapkan model ini sehingga tumbuh menjadi yang lebih kompleks, yang tidak dapat diselesaikan dengan menggunakan persamaan Selain itu, dalam seri artikel ini kami menghindari matematika.)

Mari kita mulai dengan menjelaskan tugas sebagai berikut:

• Kami memiliki kota ukuran 12 (yang berarti 12 juta orang). Orang-orang ini diwakili sebagai 12 "warga negara" yang terpisah.
• Setiap warga negara pada waktu tertentu dapat merasa puas atau tidak puas.
• Warga negara yang puas membayar dalam bentuk pajak (tarif pajak x 10) (yaitu, misalnya, tarif pajak 20% memberi kita 2 unit mata uang dalam pendapatan pajak untuk setiap warga negara yang puas).
• Warga yang tidak puas tidak membayar pajak.
• Ada 3 warga yang tidak puas di kota yang tetap tidak puas terlepas dari tarif pajak.
• Jumlah tambahan warga menjadi tidak bahagia berdasarkan rumus berikut: (Populasi) x ((tarif pajak) x (tarif pajak)) x 3,5, nilainya dibulatkan ke angka keseluruhan terdekat. Untuk kota kami dengan ukuran 12, ini akan memberi kami 0 warga negara tambahan yang tidak puas dengan tingkat 0% dan 10%, 1 warga negara tambahan yang tidak puas pada tingkat 20%, 3 warga negara tambahan yang tidak puas pada tingkat 30%, 6 pada tingkat 40%, dan 10 pada tingkat 50%.

Sederhana bukan?

Kami akan menjelaskan ini dalam spreadsheet yang terlampir pada artikel sebagai berikut:


Anda mungkin memperhatikan bahwa kami menetapkan kotak keputusan kuning (Tingkat Pajak (0-5)) sebagai cara tidak langsung untuk menunjukkan tarif pajak. Alih-alih menetapkan tarif pajak langsung di sel keputusan, sel penghitungan Tarif Pajak mengambil nomor Tingkat Pajak dari sel keputusan dan mengalikannya dengan 10%. Ada alasan logis untuk melakukan ini secara tidak langsung, dan kami akan segera melihatnya.

Sekarang kita dapat bereksperimen dan mengganti semua nilai yang mungkin dari tingkat pajak. Anda cukup memasukkan masing-masing angka dari 0 hingga 5 di sel Tingkat Pajak, dan mendapatkan yang berikut ini:


Seperti yang Anda lihat, ada tarif pajak optimal: 30%, yang memaksimalkan pendapatan pajak, memberikan 18 unit mata uang.

Mari kita mengotomatisasi sistem!

Ini memang hebat, tetapi bagaimana jika kita memiliki lebih dari enam opsi? Bagaimana jika ada ratusan kemungkinan tarif pajak atau jika kita perlu mengubah variabel keputusan lainnya? Semuanya akan menjadi terlalu rumit untuk menguji nilai secara manual.

Seperti yang akan kita lihat, inilah tepatnya yang digunakan Solver.

Pertama, kami akan mengatur ulang nilai sel Tingkat Pajak ke nol. Kemudian kita akan pergi ke tab Data Excel dan lihat di sisi kanan rekaman, di bagian Analisis, tombol Solver ("Cari solusi").


Jika Anda tidak melihatnya, buka Opsi Excel, pilih kategori Add-in, pastikan Add-in Excel dipilih di daftar turun bawah Kelola. ), klik Go dan pastikan Solver Add-in dicentang.

Setelah mengklik tombol Solver, Anda akan melihat kotak dialog serupa.


Sekarang mari kita lihat semua langkah yang terlibat dalam mengatur kotak dialog Solver.

Di bidang "Tetapkan Tujuan" ("Optimalkan fungsi tujuan") kami menunjukkan apa yang perlu kami optimalkan. Dalam hal ini, kami mencoba untuk mendapatkan sebanyak mungkin penerimaan pajak, jadi kami akan memilih kotak oranye untuk sasaran, yang mewakili pendapatan pajak, dan kemudian klik "Kepada: Maks" di daftar tombol radio.

Di bagian "Dengan Mengubah Sel Variabel", kami memilih sel yang harus "Dihitung oleh Pencarian Solusi". Kita perlu menentukan tarif pajak yang optimal, jadi pilih kotak solusi kuning (Tingkat Pajak (0-5)). Jika semuanya berjalan dengan baik, maka sebagai hasilnya sel ini akan diberi nilai 3 sesuai dengan tarif pajak 30%, optimalitas yang telah kita tentukan dalam perhitungan manual.

Akhirnya, kita perlu menambahkan beberapa batasan . Bahkan, kendala adalah prasyarat untuk setiap sel dalam model solusi kami, dan Excel Solver hanya akan fokus pada solusi yang memenuhi batasan yang ditentukan. Pembatasan tersebut dapat membatasi sel tertentu (biasanya sel keputusan dan sel perhitungan) ke nilai minimum dan / atau maksimum yang ditentukan, dan / atau menyebabkan Solver memprosesnya sebagai variabel integer atau biner (0 atau 1). Kendala sangat berguna untuk membuat model yang benar, yang akan dibatasi.

Solver membutuhkan setidaknya beberapa batasan yang memungkinkannya untuk menentukan batas sel keputusan - dengan kata lain, nilai minimum dan maksimum untuk setiap sel. Untuk menambahkan batasan, Anda perlu mengklik tombol Add di sebelah kanan, dan kemudian kotak dialog berikut akan terbuka:


Kami akan menambahkan dua kendala, satu sehingga sel solusi Tingkat Pajak memenuhi kondisi> = 0, dan satu lagi sehingga sel solusi adalah <= 5. Kemudian, dalam daftar Metode Pemecahan, pilih Evolutionary (“Evolutionary” cari solusi ") dan klik Solve (" Temukan solusi ").

Setelah bekerja sekitar 30 detik, Solver akan memberi kita jawaban yang sama:


Oh, ada masalah. Solver menerima jumlah pendapatan yang benar, tetapi tarif pajaknya tidak benar. Pemain dapat menetapkan pajak hanya dengan kenaikan 10%, tetapi Solver jelas menetapkan tarif pajak fraksional, yang tidak dapat dilakukan oleh pemain.

Anda dapat memecahkan masalah dengan membatasi nilai sel tarif pajak ke seluruh angka. Itu bisa sama dengan 0, 1, 2, 3, 4 atau 5, tetapi tanpa nilai menengah.

Untungnya, dalam Solver ini bisa sangat mudah dicapai. Buka Pemecah Masalah, klik tombol Tambah, pilih sel solusi Tingkat Pajak, lalu pilih batasan int dalam daftar turun bawah di tengah:


Sekarang jalankan Solver lagi dan dapatkan yang berikut:


Sempurna! Dengan sedikit usaha, kami mendapat jawaban yang benar di Solver. Seperti yang akan segera kita lihat, dengan peningkatan skala tugas, volume pekerjaan yang dilakukan oleh alat untuk kita secara signifikan melebihi waktu yang dihabiskan untuk menyiapkannya.

Kota berkembang

Mari kita memperluas tugas sekarang dengan sedikit menyulitkan model kota.

Dalam setiap strategi 4X, kota (atau planet, atau koloni, atau unit penghuni lainnya) tumbuh seiring waktu. Kami akan berasumsi bahwa kota ini memiliki peningkatan konstan 8% per putaran, mulai dari 1.500 ribu (1,5 juta) warga, dan meningkat hingga ukuran 12 juta jiwa. Sekarang spreadsheet kita akan terlihat seperti ini:


Setiap baris tabel baru menggambarkan satu arah permainan.

Kami juga mengubah perhitungan tingkat dasar ketidakpuasan. Sekarang dihitung sebagai satu detik dari tingkat populasi dasar (dalam jutaan), dibulatkan ke bawah. Karena ini, ketidakpuasan dasar akan 0 sampai kota tumbuh ke ukuran 4, setelah itu akan tumbuh secara linear dengan ukuran kota.

Seperti sebelumnya, kita dapat bereksperimen dengan level pajak secara manual dengan mengubah nilai Level Pajak. Kami akan menerima 0, 102, 190, 222, 144 dan 65 unit mata uang dalam penerimaan pajak, dengan setiap tingkat pajak dari 0% hingga 50%.

Dan lagi kita bisa mendapatkan Solver untuk menyelesaikan masalah ini; dia akan dengan cepat menentukan bahwa tarif pajak optimal adalah 30% seperti sebelumnya, yang memberi kita penghasilan 222 unit mata uang. Seperti inilah tampilan dialog Solver:

Tarif pajak variabel

Tapi, tentu saja, pemain tidak akan bermain dengan cara ini. "Kota" kami yang disimulasikan menetapkan satu tarif pajak dan tetap sama untuk setiap gerakan game. Tetapi pemain sungguhan dapat memiliki tarif pajak kapan saja, dan dia sering perlu menyesuaikannya karena kotanya tumbuh dan keadaan berubah.

Bukankah lebih bagus jika kita tidak hanya dapat menentukan tarif pajak tunggal yang optimal, tetapi juga menghitung nilai optimal dalam setiap langkah?

Dia akan segera memberi tahu kami bagaimana pemain dapat menyesuaikan pajak.

Dan ternyata ini bisa dilakukan! Setelah menyiapkan model solusi dengan cara yang benar, kami dapat mengimplementasikannya dengan sangat sederhana.

Perbedaan terbesar adalah bahwa kita perlu menghapus sel keputusan Tingkat Pajak (0-5) dan menggantinya dengan seluruh kolom sel tingkat pajak, seperti yang ditunjukkan di bawah ini.


Sekarang, alih-alih memaksa Solver untuk mengoptimalkan sel tunggal, kami memerintahkannya untuk mengoptimalkan seluruh kolom Tingkat Pajak. Seperti inilah kotak dialog Solver akan terlihat - Anda dapat melihat bahwa hampir sama dengan sebelumnya, hanya alih-alih satu sel variabel dan batasan sekarang mewakili seluruh rentang sel di kolom Tingkat Pajak.


Solver benar-benar membuktikan bahwa perubahan dalam tarif pajak mengubah hasilnya - pendapatan kumulatif sekarang mencapai 232 unit mata uang. Dibandingkan dengan tarif pajak yang sama, pertumbuhan hanya 5% (222 terhadap 232 unit), tetapi masih signifikan karena kita tahu bahwa beberapa pemain akan dapat mencapainya.

Melihat lebih dekat pada solusi yang diterima Solver, Anda dapat melihat bahwa itu dimulai dengan tarif pajak 50%, karena kota ukuran 1 tidak mengandung cukup banyak orang untuk menimbulkan ketidakpuasan. Dalam proses pertumbuhan kota, alat mengubah tarif pajak di setiap belokan dalam kisaran dari 20% menjadi 30%, tergantung mana yang akan menghasilkan lebih banyak pendapatan.

Spreadsheet untuk contoh ini dapat diunduh di sini ; di dalamnya, tiga tahap dari contoh ini dibagi menjadi beberapa lembar spreadsheet yang terpisah (pajak yang sama untuk kota dengan populasi permanen, pajak yang sama untuk kota yang tumbuh, dan tarif pajak variabel untuk kota yang tumbuh).

Kesimpulan

Solusi yang kami temukan menunjukkan sesuatu yang menarik: sifat diskrit dari simulator permainan kami, yang mewakili pengelompokan jutaan orang secara sewenang-wenang sebagai "warga negara" diskrit yang dapat memiliki satu atau dua tingkat kepuasan tersendiri, memperkenalkan fitur karakteristik ke dalam model. Meskipun permainan itu sendiri pada tingkat tertentu akan memerlukan diskritisasi semacam itu demi aksesibilitas dan kemampuan bermain, pemain yang cerdas dan licik akan dapat mengeksploitasi fragmentasi buatan ini untuk mendapatkan keunggulan dibandingkan pemain yang tidak ingin repot dengan tingkat pajak di setiap belokan.

Situasi ini mengarah pada pertanyaan yang menarik: apakah ini yang kita inginkan? Apakah mekanisme para pemain membuatnya perlu bagi mereka untuk terlibat dalam manajemen mikro tingkat pajak di setiap belokan? Dan apakah kita ingin memungkinkan gamer yang berorientasi daya mengalahkan sistem dengan cara ini; Apakah trik semacam itu cocok dengan keuntungan mereka sebesar 5%?

Saya tidak bisa menjawab pertanyaan-pertanyaan ini. Pada akhirnya, Anda adalah seorang desainer yang menetapkan tujuan desain, jadi terserah Anda untuk memutuskan apakah tingkat operasi sistem ini memenuhi tujuan yang Anda tetapkan untuk game.

Tentu saja, model ini hanya bingkai telanjang. Dalam strategi 4X yang nyata, pemain dapat membuat segala macam keputusan tentang cara mengembangkan kota, membangun gedung, dan membuat perubahan lain yang memengaruhi pertumbuhan kota, kepuasan, pendapatan pajak, dan produktivitas.

Dalam artikel yang akan datang dalam seri ini, kita akan membangun model yang mirip, tetapi jauh lebih kompleks dari seluruh koloni planet dalam permainan yang mengingatkan pada Master of Orion 2 . Contoh ini akan jauh lebih canggih, karena kita akan dapat membuat keputusan di setiap belokan yang selanjutnya akan mempengaruhi semua parameter ini, seperti pertumbuhan dan produktivitas, yaitu setiap keputusan akan memiliki konsekuensi yang mempengaruhi keputusan selanjutnya. Namun, kami masih yakin bahwa pengoptimal evolusi alat Solver mampu mengatasi tugas ini.

Pada artikel selanjutnya, kami akan memenuhi janji kami dan mengoptimalkan pembelian senjata untuk SuperTank dalam contoh dari artikel pengantar.