Hari baik untuk semua, nama saya Sergey Noskov. Hari ini saya ingin berbicara tentang pembuatan proyek indie penuh pertama saya yang disebut 35MM, dirilis di Steam pada tahun 2016. Ceritanya tentu saja panjang, dan sejak itu beberapa artikel dan wawancara tentang topik proyek telah diterbitkan, namun, tidak ada deskripsi rinci tentang proses pengembangan. Juga, aspek teknis implementasi hampir tidak tersentuh. Sebenarnya, kita akan membicarakan ini.
Mari kita mulai dengan sedikit latar belakang. 35MM adalah sebuah petualangan dengan pandangan orang pertama dalam pengaturan pasca-kiamat di Rusia. Orang-orang - simulator berjalan. Gim ini menceritakan kisah perjalanan dua pengembara melintasi tanah-tanah sepi yang ditinggalkan oleh peradaban. Sebagian besar populasi mati setelah penyakit yang mengerikan, dan sekarang alam memenangkan kembali poinnya dari kemanusiaan. Sayangnya, saya tidak ingat persis bagaimana ide proyek ini lahir, tetapi saya benar-benar ingat bahwa pada waktu itu saya adalah penggemar berat dari topik penguntit, permainan Metro, dan lingkungan yang umumnya atmosfer seperti itu. Bentang alam kota-kota terlantar, zona industri dan desa selalu membangkitkan kegelisahan dan kegembiraan saya. Saya tidak tahu jenis penyakit apa itu dan bagaimana menjelaskan cinta seperti itu, tetapi ada banyak dari kita. Secara umum, hasrat seperti itu pada topik ini sudah cukup untuk mulai menciptakan dunia game kecil Anda sendiri.
Karena saya sudah memiliki dua proyek kecil (Cahaya dan Kereta), serta pengalaman di mesin Unity, saya mulai mengembangkan game baru di dalamnya. Jika saya tidak salah, pada saat itu versi kelima dari mesin sudah tersedia, tetapi sampai batas tertentu saya konservatif (bukan sifat profesional terbaik saya), jadi saya memutuskan untuk tetap menggunakan versi 4.7. Untuk pemahaman umum, ada banyak perbedaan signifikan antara versi 4 dan 5 dari mesin, terutama dalam hal rendering, pencahayaan, dan material. Unity 5 memperkenalkan shader fisik yang akurat yang dapat memantulkan cahaya dan menampilkan refleks dengan benar. Dengan kata sederhana - silau dan pantulan pada material dengan shader seperti itu terlihat lebih alami dan menarik. Pada versi 4, shader dasar jauh lebih sederhana, namun, menulis shader Anda sendiri dapat secara signifikan meningkatkan kualitas gambar. Kami akan membicarakannya nanti. Jelas bahwa pengembangan game mencakup banyak aspek, selain bekerja di mesin itu sendiri. Agar mesin memiliki sesuatu untuk dijejalkan, konten diperlukan: model, tekstur, suara, skrip, dll. Semua itu pada akhirnya kita lihat di monitor dan dengar di kolom. Dan tentu saja, setiap jenis konten memerlukan perangkat lunaknya sendiri. Untuk membuat model 3D saya menggunakan 3D max, untuk bekerja dengan grafik 2D dan membuat tekstur - Photoshop, untuk bekerja dengan suara - Adobe Audition, saya menulis kode dalam program Monodevelop yang menyertai Unity. Saya terutama menyarankan agar Anda menutup mata atau melompat ke bab berikutnya - gim ini ditulis dalam Javascript. Hanya sst, jangan bilang siapa-siapa. Saya hanya tahu bahwa bagi sebagian orang ini rasanya tidak enak dan tidak ada yang menulis di Javascript. Secara umum, alat utama dipilih dan alur kerja perlahan-lahan menjauh.
Bagaimana semuanya dimulai
Dalam beberapa wawancara, saya sudah menyebutkan bahwa biasanya saya tidak memiliki rencana pengembangan yang jelas, tetapi hanya gambaran besarnya. Oleh karena itu, seringkali, penciptaan lokasi terjadi secara spontan dan desain dipikirkan saat bepergian. Ini, tentu saja, lebih dari minus daripada plus, tetapi ada sisi positif - sangat menghibur dan Anda tidak pernah tahu persis apa yang akan terjadi selanjutnya. Ternyata permainan sampai batas tertentu menjalani hidupnya sendiri sudah pada tahap awal. Pengembangan 35MM dimulai dengan penciptaan lokasi pertama - rumah hutan yang ditinggalkan dan sebidang tanah luas dengan ladang dan hutan jenis konifer.
Untuk membangun permukaan bumi digunakan terrane dengan 5-6 tekstur rumput dan bumi. Shader terrane standar mengecat permukaan dengan tekstur berbeda menggunakan topeng RGBA, yang kami buat dengan kuas di mesin itu sendiri, dan hasilnya sering terlihat sangat buram, transisi antara tekstur terlalu halus dan tidak tampak alami. Untuk memperbaiki titik ini, shader terrane telah diubah dan masker offset ditambahkan. Tekstur hitam-putih “menggeser” topeng yang digambar di terrane dan menciptakan tepian yang sobek dan lebih tajam, yang secara visual sedikit mempersulit penampilan permukaan.
Permukaan tanah kami dilengkapi dengan beberapa jenis rumput dalam bentuk pleins yang tersebar secara acak. Unit ini juga memiliki mode papan iklan (ketika dataran rumput selalu melihat pemain), tetapi sangat tidak cocok untuk bermain dengan tampilan orang pertama, karena terlalu mencolok bagaimana rumput “mengawasi” kamera kita. Anda harus selalu berhati-hati dengan rumput dan menambahkannya dalam batas yang wajar, karena kesenangan ini melemparkan cukup banyak drawcall, dan ini pada gilirannya mempengaruhi kinerja. Semakin banyak drawcall, semakin tinggi beban pada sistem komputer. Namun jangan lupa bahwa tantangan tidak hanya menambah beban. Ada banyak cara untuk mematikan kinerja dalam game. Selain rumput di tanah, untuk perubahan, jerat dengan cabang dan batu berserakan, serta serangkaian decals dengan kotoran dan bekas roda mobil.
Setelah menciptakan permukaan, pergi ke vegetasi, pohon, dan semak-semak. Saya lebih suka menanam bagian utama hutan (pohon jenis konifera) menggunakan alat-alat dari terran itu sendiri - yaitu, dengan kuas. Keuntungan dari metode ini adalah bahwa hal itu dilakukan dengan cepat dan mudah, apalagi, pada jarak yang sangat jauh, hutan seperti itu ditransformasikan dari jerat menjadi papan reklame, yang mempengaruhi optimalisasi dengan sangat baik. Namun, di dekat beban sangat meningkat, karena, seperti yang saya mengerti, pohon-pohon seperti itu tidak menggelinding. Mungkin saya salah, dan seseorang akan memperbaiki saya. Mentega adalah alat yang sangat penting untuk optimasi. Secara kasar, ini adalah kombinasi dari jerat dengan satu bahan dalam satu mesh yang sama, yang secara signifikan mengurangi jumlah drawcall, masing-masing, mengurangi beban. Kekurangan lain dari tempat duduk di medan adalah posisi pohon-pohon yang sama, yaitu, mereka semua diciptakan pada sudut yang sama dan kesamaan ini mencolok. Dalam hal ini, saya memasang beberapa pohon pinus, cemara dan gugur secara manual pada sudut yang berbeda dan dengan ukuran yang berbeda, yang menambahkan variasi pada lanskap. Semak diatur dengan cara yang sama.
Untuk kelengkapan, masih harus berurusan dengan langit. Untuk tugas ini, bahan skybox biasa dengan enam tekstur digunakan. Ada upaya untuk memodifikasi shader sehingga langit terlihat dinamis, tetapi hasilnya tidak membenarkan dirinya sendiri dan ide ini harus ditinggalkan. Alternatifnya adalah penggunaan sistem partikel dengan tekstur awan dan papan iklan horisontal dengan gerakan tweens. Sejauh yang saya ingat, opsi serupa digunakan dalam game Stalker, dan memang ada banyak lagi di tempat lain.
Pencahayaan
Di versi 4 dari mesin Unity, ada mode yang sangat nyaman untuk memanggang lightmaps - dual lightmapping. Ada opsi serupa di versi saat ini, tetapi saya belum mempelajarinya secara rinci. Mode ganda memungkinkan kami untuk menggambar bayangan dan menyilaukan secara realtime dari jarak dekat, tetapi ketika kami menjauh dari kamera, semua ini dengan lancar berubah menjadi lightmaps yang dipanggang, yang sangat memudahkan tugas untuk perangkat keras kami. Secara umum, saya menggunakan metode ini di semua lokasi permainan. Akibatnya, untuk setiap lokasi tengah, satu set sekitar 5-10 peta cahaya untuk rencana dekat dipanggang, dan jumlah yang sama untuk yang jauh (peta cahaya dalam rencana dekat juga, tetapi hanya dengan ambient yang dipanggang ambient).
Secara umum, di banyak daerah saya mencoba menggunakan cahaya yang dipanggang sepenuhnya, kecuali sinar matahari. Lampu titik ditempatkan di tempat-tempat untuk menekankan aksen dan lebih banyak cahaya. Ini terutama dilakukan di kamar-kamar di mana sedikit cahaya eksternal menembus. Di sejumlah tempat, tentu saja, lampu rilttime dengan bayangan juga digunakan: cahaya dari api, lampu meja, langit-langit atau lampu dinding. Ngomong-ngomong, ketika bekerja dengan pencahayaan, saya harus berurusan dengan masalah besar yang terkait dengan lampu Point dan bayangan waktu nyata. Di beberapa daerah, pandangan kamera pada sumber cahaya dengan bayangan memberi friez dan rem yang menakutkan. Tidak sepenuhnya jelas mengapa bebannya sangat tinggi, tetapi profiler pada saat itu menunjukkan drawcall skala off untuk sepersekian detik. Untuk memperbaiki situasi, penggunaan dua luminer Spot yang diarahkan dengan arah yang berlawanan dari satu sama lain membantu. Opsi ini ternyata tidak terlalu berat.
Model
Sebagian besar model 3D untuk gim ini dibuat secara independen. Sesuatu dilakukan dengan sangat hati-hati, dengan memanggang peta normal dan seluk-beluk lainnya, dan sesuatu dibuat dengan tergesa-gesa untuk menghemat waktu. Sebagian besar objek dibuat dalam kelompok dan menggunakan tekstur atlas tunggal. Yaitu, dalam satu tekstur ada bagian, misalnya, untuk blok beton, tanda jalan, puing-puing bata, selokan, dan sebagainya. Ini memungkinkan satu bahan untuk digunakan untuk semua benda-benda ini, dan, karenanya, memungkinkan benda-benda itu bergemerincing. Seingat kami, ini cukup bagus. Beberapa model dengan setia saya unduh dari Internet, dari perpustakaan gratis. Pada dasarnya, ini adalah alat peraga kecil untuk mengisi ruangan, namun, saya mencoba memodifikasi semua model ini sedikit sehingga kesamaannya tidak terlalu jelas. Seringkali saya memperhatikan aset identik dalam game indie, yang agak memengaruhi persepsi saya bukan dengan cara terbaik. Yang paling bermasalah dalam hal penciptaan adalah transportasi. Memodelkan kendaraan roda dari awal sangat memakan waktu dan membutuhkan banyak waktu. Oleh karena itu, beberapa salinan mobil dibeli oleh saya di Asset Store.
"Lagu" yang terpisah adalah penciptaan karakter. Ini masih percobaan. Bagi mereka yang tidak memiliki ide bagus tentang berapa banyak pekerjaan yang diperlukan agar karakter muncul yang entah bagaimana bisa ada dalam permainan, saya akan menjelaskan. Model poli tinggi dibuat dengan semua detail, kancing di lengan baju, kerutan di wajah, dll. Model low-poly dengan karakter yang sama dibuat dengan pemindaian tekstur (dalam game saya, jumlah poligon per karakter rata-rata sekitar 5-8 ribu). Selanjutnya, peta normal, peta ambient (soft shading) dihilangkan dari model poli tinggi untuk model poli rendah dengan manipulasi yang licik atau tidak rumit. Saya biasanya dari ambient kemudian membuat peta difus di Photoshop. Di peta difus di saluran alfa, buat peta specular untuk membuat kecemerlangan.
Untuk 2019, tentu saja, itu sudah terlalu primitif, tetapi selama 16 tahun dan untuk proyek indie itu cukup cocok.
Lebih jauh lagi, orang Persia kita perlu digoda - untuk menempatkan tulang di dalamnya, yang dengannya dia dapat menggerakkan anggota tubuhnya, menggerakkan rahangnya, menekuk dan melenturkan jari-jarinya, dll. Nah, pada akhirnya, semuanya perlu dianimasikan. Biasanya satu set animasi dengan status berbeda dibuat untuk karakter: berjalan, berlari, posisi berdiri atau duduk. Tetapi fragmen unik juga diperlukan, misalnya, dalam kasus saya, untuk mitra pahlawan kami Petrovich, sejumlah besar variasi aksi diperlukan: membuka pintu, memeriksa peta, berkelahi dengan bandit, melemparkan bom ringan di level Bor, dll. Semua ini harus dianimasikan dengan tangan, yang tentu saja sangat mencolok dalam kecanggungannya. Secara umum, animasi manual gerakan manusia adalah tugas yang sangat sulit dan sangat sulit untuk mencapai hasil yang masuk akal. Oleh karena itu, tutup gerak adalah solusi yang paling cocok untuk tugas ini. Sejauh yang saya tahu, sekarang opsi ini lebih murah dan lebih cepat daripada karya animator, meskipun data yang diterima perlu diproses dan "dibersihkan" secara manual.
Shader
Saya akan segera mengklarifikasi bahwa saya memahami penulisan shader pada waktu itu dengan sangat dangkal. Pelatihan saya terutama dalam analisis contoh-contoh yang sudah jadi dan penyempurnaannya. Saya mengambil berbagai opsi dari jaringan, mengubah parameter, menambahkan yang baru atau menghapus yang lama dan memeriksa bagaimana ini mempengaruhi hasilnya. Ternyata ini adalah kegiatan yang sangat menarik. Yang menarik bagi saya adalah penanganan saluran tekstur yang berbeda sebagai topeng. Dalam beberapa kasus, saya mencoba menyesuaikan jumlah informasi maksimum menjadi satu tekstur dan menggunakannya. Pada awal artikel, saya menyebutkan perbedaan antara versi Unity ke-4 dan yang lebih baru, dan secara khusus, kehadiran bayangan yang benar secara fisik di versi terbaru. Saya mencoba menghilangkan kekurangan ini sendiri, dan efek fresnel ditambahkan ke shader standar dengan peta specular, cubmap dan normal. Ini adalah fitur bahan reflektif, di mana permukaan pada sudut relatif terhadap pandangan kita mencerminkan lingkungan (atau cubmap dalam kasus ini) lebih kuat dan biasanya terlihat lebih ringan dan lebih kontras. Ini sangat mencolok pada bola yang mengkilap, ujung-ujungnya tampak lebih cerah daripada bagian tengah. Saya bisa mengulangi efek ini, serta menambahkan kemampuan untuk melukis cubmap dalam materi, yang biasanya bisa kita lihat pada permukaan reflektif tetapi kasar. Shader ini benar-benar cocok untuk saya dan diterapkan pada sebagian besar materi dalam game.
Pengalaman menarik kedua adalah penciptaan shader untuk kulit karakter. Dasarnya adalah kode yang ditemukan di Internet yang memungkinkan Anda untuk menggunakan tekstur gradien, yang bertanggung jawab atas kekuatan dan warna pencahayaan yang mempengaruhi model. Tekstur yang serupa dengan warna kemerahan di tengah memungkinkan untuk meniru kulit manusia, yang, seolah-olah, sedikit tembus cahaya, yaitu, memiliki ketebalan sendiri, di mana cahaya tersebar dengan lancar. Efeknya tidak sempurna, tetapi terlihat lebih baik daripada Bumped Specular plastik standar.
Selain shader di atas, banyak opsi sekunder dengan efek individual dibuat dalam proses. Misalnya, shader genangan air dengan cubmap dan deformasi peta difus. Karena terlalu mahal untuk menerapkan refleksi nyata ke genangan air, dan saya tidak ingin menggunakan render dalam tekstur (ini adalah ketika bingkai disimpan dalam tekstur dan digunakan dalam material, di mana, misalnya, distorsi udara hangat dapat dibuat), saya memutuskan untuk membuat distorsi sederhana dari tekstur bumi, membentang di atas genangan air. Efeknya cukup bagus dan tidak menyengat setrika sama sekali. Kebetulan, shader dengan tekstur membuat digunakan untuk mengubah udara lampu minyak tanah dan api unggun. Sepertinya itu adalah distorsi panas dari aset Detonator. Juga, untuk mensimulasi sinar cahaya volumetrik, vertex shader dibuat dengan efek Partikel Lunak dan efek cahaya rim (ketika kita melihat poligon pada suatu sudut, mesh masuk ke alfa). Ini adalah cara implementasi klasik dan sudah berjanggut. Sekarang, untuk Unity baru ada opsi keren yang bekerja berdasarkan efek pasca dan memungkinkan Anda untuk menggambar sinar cahaya nyata bahkan dengan mempertimbangkan bayangannya.
Hal lain yang patut diperhatikan adalah set shader yang dibuat untuk mensimulasikan permukaan basah. Permainan ini memiliki episode di mana pada titik tertentu hujan deras dimulai dan beberapa bahan dengan lancar mendapatkan kilau yang khas. Efek utama diterapkan ke medan, di mana, seperti dalam kasus genangan air, tekstur difus mulai berubah. Kebocoran air juga muncul di jendela rumah. Nah, chip yang paling "basah" itu jatuh jatuh pada lensa. Di sini, pada kenyataannya, saya tersiksa oleh keraguan, karena sang pahlawan tidak memiliki kacamata atau helm, dan bagaimana tetesan yang begitu obsesif dipamerkan di layar tidak jelas. Namun, secara visual saya sangat menyukai efeknya sehingga saya tidak bisa menolaknya.
Jadi kami dengan lancar beralih ke efek pasca. Berbicara tentang tetes pada layar, semuanya sederhana: beberapa tetes dari tekstur berlipat ganda dan bergerak turun dengan kecepatan yang berbeda. Secara paralel, gelombang (tekstur gradien) bergerak ke bawah, yang dikalikan, masing-masing dengan kelompok tetesannya sendiri. Kemudian semuanya dirangkum, sedikit ditampilkan dalam "difusi", sehingga untuk berbicara, tetapi terutama digunakan sebagai topeng untuk menggeser koordinat. Akibatnya, gambar kita terdistorsi oleh pembiasan tetesan air. Set utama efek pasca yang selalu atau opsional pada kamera (jika pemain menghidupkan atau mematikannya) adalah antialiasing, SSAO, Bloom, Aberration, Vignette, Sun Shafts. Ini semua adalah efek Unity standar, tetapi SSAO telah dimodifikasi sehingga rendering bayangan di kejauhan dikurangi menjadi nol, karena di kejauhan dalam kabut bintik-bintik gelap bayangan tampak aneh. Efek penyimpangan juga berubah (ini adalah distorsi warna gambar ketika menggunakan lensa, sesuatu seperti kontur warna di tepi benda) .Efek standar dari Unity melukis tepi benda hijau-burgundy (solusi yang agak aneh menurut saya). Bahkan, paling sering warnanya lebih dekat ke kuning-merah-biru, yang saya sadari. Efek permanen lainnya adalah koreksi warna buatan sendiri. Bagi saya efek standar Unity tampaknya terlalu intensif sumber daya, sehingga efeknya sendiri yang disederhanakan terwujud. Pada dasarnya, ia menciptakan efek tonmapping dan sedikit mengubah skema warna menjadi lebih dingin. Memilih palet warna untuk gambar selalu merupakan tugas yang sulit, yang sulit ditentukan. Kebetulan Anda mungkin suka opsi yang sepenuhnya berlawanan dan membuat keputusan sangat sulit. Dalam proyek ini, saya memilih warna kusam dan dingin. Bagi banyak orang, dia tampak terlalu pudar, tetapi, bagi saya, dia sangat akurat menyampaikan suasana yang saya coba renungkan dalam permainan saya, suasana kesedihan, kesedihan dan kesepian.
Bagaimana dengan kodenya?
Saya berulang kali menyebutkan dalam sebuah wawancara bahwa saya selalu jauh dari topik pemrograman dan lebih fokus pada komponen visual. Saya mulai menulis kode lengkap pertama saat mengerjakan permainan "Melatih", jadi pada saat mengembangkan 35MM saya sudah memiliki beberapa keterampilan. Secara umum, genre pencarian menurut saya sangat cocok untuk memahami pemrograman pada tingkat awal saya. Sebagian besar aksi dalam game didasarkan pada pemicu. Objek memasuki pelatuk (kubus dengan collider) dan sesuatu mulai terjadi, misalnya, adegan cut dimulai. Dalam skrip, seperti pada skrip untuk pertunjukan teater, dijelaskan baris demi baris kapan dan apa yang terjadi - sekarang kamera pemain mati, kamera cut-scene menyala, karakter muncul di bingkai, animasi percakapan dimulai, dll. Saya percaya bahwa ada alat yang membuat seluruh proses ini lebih mudah (saya percayakarena itu tidak masuk jauh), tetapi opsi ini menurut saya masih yang paling dimengerti, karena Anda sendiri yang mengendalikan semua acara.Pergerakan mitra kami dalam game diimplementasikan menggunakan pemicu, yang merupakan titik pemeriksaan dari rutenya. Jika Anda menekan pelatuknya, beberapa animasi baru mungkin hidup, atau karakternya bisa mengatakan sesuatu.
Metode ini digunakan di semua tingkatan kecuali yang terakhir. Di lokasi terakhir di kota, jika kami sampai padanya dengan seorang mitra, dia tidak lagi memimpin kami di sepanjang rute, melainkan berlari mengejar kami. Di sana, pengontrol berbasis NavMesh (sistem yang memungkinkan objek mencari jalur ke target dan pindah ke sana) telah digunakan.
Segalanya menjadi lebih sulit dengan beruang di lokasi kedua permainan. Dulu ada pengontrol yang bekerja hanya dengan tubuh yang kaku (tubuh fisik), sehingga binatang itu bodoh dan sering menabrak pohon dan benda lainnya. Materi fisik dengan gesekan nol memungkinkan kami menghindari kemacetan serius, dan beruang akhirnya tergelincir dan terus mengejar kami. Di sini, dan secara umum di daerah di mana Anda bisa mati, saya mengalami masalah paling serius bagi saya - peluncuran kematian dan mulai lagi. Pada saat kematian, perlu untuk memperhitungkan semua status karakter saat ini: apakah senter dinyalakan, apakah kartu terbuka, apakah pisau diaktifkan, dll. Itu juga diperlukan untuk menjaga nilai-nilai kesehatan dan semua sumber daya dan kemudian, segala sesuatu yang diaktifkan, diperlukan untuk menonaktifkan dan memulai animasi dari kamera yang jatuh. Setelah gelap layar, itu perlu untuk mengembalikan semuanya dan membaca nilai yang disimpan.Sebenarnya, tidak ada kesulitan besar dengan pendekatan yang tepat, tetapi dalam kasus saya banyak bug muncul: apakah pisau tetap di tangan saya di depan mata saya ketika beruang menyerang, maka kartu tidak dilepas - semuanya seperti itu. Selain itu, Anda tidak pernah tahu bagaimana seorang pemain dapat memimpin dirinya sendiri pada saat ini, di mana ia akan berlari dan dalam kondisi apa beruang dapat memimpin, yang dapat terjebak di suatu tempat atau, misalnya, menyerang kami melalui dinding. Secara umum, ada banyak nuansa yang tidak akan Anda sadari segera.serang kami melalui dinding. Secara umum, ada banyak nuansa yang tidak akan Anda sadari segera.serang kami melalui dinding. Secara umum, ada banyak nuansa yang tidak akan Anda sadari segera.Interaksi karakter kita dengan objek direalisasikan menggunakan sinar Raycast. Semua objek interaktif diberi tag dengan tag Subjek, dan ketika balok mengenai mereka, itu mengaktifkan lampu latar (mesh adalah indikator dengan tepi yang disorot) dan termasuk skrip yang sudah bertanggung jawab atas tindakan apa yang dapat kita ambil dengan objek ini, misalnya, mengambil objek, membaca catatan atau buka pintu.Untuk interaksi, awalnya ada rencana untuk membuat tangan penuh yang akan meraih benda, ini akan menciptakan efek kehadiran yang lebih jelas. Tetapi opsi ini mewakili bagi saya kesulitan implementasi yang besar dan prospek memiliki "bundel" bug di masa depan, jadi hanya ada tangan yang membawa barang-barang yang sudah dipilih. Ada cetakan dengan pegangan kecil di depan kamera, di mana semua benda sudah ada (kamera, pisau, kapak, dll.). Saat memilih objek selama pertandingan, yang diinginkan menyala, dan yang tidak perlu mati.
Suatu hal yang menarik terkait dengan animasi karakter yang berbicara. Tekniknya primitif, tetapi saya memikirkannya sendiri, bangga, ya. Pada awalnya, saya berpikir bahwa ketika mengkomunikasikan karakter, saya harus memulai animasi pembukaan rahang secara acak dengan setiap frasa. Tetapi kemudian terpikir oleh saya bahwa sebuah skrip dapat membaca level volume soundtrack pada saat pemutaran dan mentransfer level ini ke nilai float, yang sudah bertanggung jawab atas posisi rahang sang pahlawan. Pada akhirnya, rahang otomatis terbuka ketika mengucapkan kata-kata dengan ketukan file suara. Ini sangat menyederhanakan tugas, meskipun tampak terlalu "mesin".Optimasi
Optimalisasi adalah bagian yang sangat penting dari pengembangan, di mana seberapa lancar permainan akan bekerja pada perangkat keras yang berbeda tergantung. Saya akan menyentuh pada optimalisasi komponen visual proyek. Ada beberapa metode yang berguna untuk ini: kelompok pondok, pemusnahan tersumbat, kliping objek di kejauhan. Grup LOD harus digunakan dalam kasus benda-benda poli-tinggi "berat". Untuk melakukan ini, buat beberapa jerat dengan jumlah poligon yang berbeda. Semakin jauh kameranya dari subjek, semakin sederhana model ditarik dalam bingkai. Misalnya, untuk 35MM, pondok digunakan dalam model mobil, karakter, dan beberapa pohon. Biasanya 2-3 pondok dibuat, di antaranya setiap jaring berikutnya memiliki poligon hampir 2 kali lebih sedikit. Untuk kejelasan: model mobil asli terdiri dari 15 ribu poligon, LOD pertama sudah memiliki sekitar 9 ton.(jumlah tulang rusuk berkurang, bagian-bagian kecil seperti engsel, bagian interior dihilangkan), LOD kedua sudah mencapai 5 ton (pegangan pintu, cermin di dalam kabin dilepas, geometri menjadi lebih sederhana). Lebih lanjut dalam nada yang sama. Untuk penginapan, omong-omong, satu trik menarik digunakan. Ketika kita membuat lightmap untuk objek dengan pondok, kita harus memanggang untuk kedua objek. Untuk mengurangi waktu pembakaran dan menghemat memori sistem, saya menggunakan skrip yang secara otomatis mentransfer lightmap yang ditetapkan dengan semua koordinat dari objek induk (nol LOD) ke semua pondok lainnya.satu trik menarik digunakan. Ketika kita memanggang lightmap untuk objek dengan pondok, kita harus memanggang untuk kedua objek. Untuk mengurangi waktu memanggang dan menghemat memori sistem, saya menggunakan skrip yang secara otomatis mentransfer lightmap yang ditetapkan dengan semua koordinat dari objek induk (nol LOD) ke semua pondok lainnya.satu trik menarik digunakan. Ketika kita memanggang lightmap untuk objek dengan pondok, kita harus memanggang untuk kedua objek. Untuk mengurangi waktu memanggang dan menghemat memori sistem, saya menggunakan skrip yang secara otomatis mentransfer lightmap yang ditetapkan dengan semua koordinat dari objek induk (nol LOD) ke semua pondok lainnya.Metode optimasi kedua adalah Occlusion Culling. Ini adalah mekanisme di mana segala sesuatu yang tidak ada dalam bidang pandang kamera atau ditutup oleh objek lain terputus. Misalnya, ketika kita masuk ke ruangan, di belakang tembok kita tidak lagi melihat banyak benda di jalan, dan oleh karena itu tidak perlu menghabiskan sumber daya untuk merendernya.
Cara lain yang berguna untuk menyederhanakan rendering adalah dengan memotong objek di kejauhan. Ini adalah opsi pertama yang saya temui sejak proyek "Ringan". Sebuah skrip digantung pada kamera yang menyesuaikan jarak renderingnya untuk setiap lapisan. Dalam kasus saya, tiga kategori lapisan dibuat secara khusus, dengan benda-benda kecil (barang-barang rumah tangga, palu, batu bata dan puing-puing kecil), dengan ukuran sedang dan sedikit lebih tinggi dari rata-rata (teko, semak, pot bunga, tiang lampu kecil, dll.). Tiga kategori diberi jarak: 40, 80 dan 120 meter. Setelah melampaui jarak yang ditentukan, kamera berhenti merender objek yang sesuai. Opsi ini sangat nyaman dan efektif, karena alat peraga kecil tidak lagi dapat dilihat dari jauh, dan karenanya, menjadikannya tidak masuk akal.Suara
Sebagian besar suara untuk permainan diambil dari perpustakaan gratis dari Internet. Biasanya saya mengunduh opsi yang diperlukan, dan kemudian menggabungkan dan mencampurnya dalam Adobe Audition. Secara umum, tidak ada banyak yang bisa dikatakan tentang bagian pekerjaan ini, karena ini adalah proses yang agak rutin dan membosankan dan tidak terlalu menarik bagi saya. Ngomong-ngomong, pekerjaan memperkenalkan suara, mencetak adegan cut, menyesuaikan file suara sehingga suara yang diinginkan diputar pada waktu yang tepat - semua ini mungkin membutuhkan seperempat dari total waktu yang digunakan untuk mengerjakan game. Satu-satunya momen yang menyenangkan adalah pengenalan musik, di mana komposer Dmitry Nikolaev yang keren dan sangat berbakat bekerja. Saya sangat senang dengan apa yang dia lakukan, karena pada umumnya, saya tidak tahu persis apa yang ingin saya dengar. Tapi Dmitry merasakan suasana dengan sangat baik,yang diletakkan dalam proyek dan mengimplementasikannya dalam bentuk atmosfer atmosfer. Ternyata sesuatu yang fantastis, misterius dan melodi.Langkah lain yang menarik adalah bekerja dengan karakter akting suara. Meskipun ada kritik dari luar, saya masih senang dengan hasilnya dan saya percaya bahwa para aktor melakukan pekerjaan mereka dengan sangat baik. By the way, karakter utama disuarakan oleh Vsevolod Petrykin dan Alexander Bragi, yang banyak terima kasih kepada mereka.Secara umum, tidak ada masalah serius dengan suara, meskipun, setelah rilis, bug langka ditemukan bahwa saya masih tidak bisa mengatasinya, karena saya masih tidak mengerti sifatnya. Kadang-kadang sebagian dari suara berhenti dimainkan, atau terdengar dengan efek gema yang kuat. Ketika berbicara dengan seorang pahlawan, sebuah suara tiba-tiba bisa menghilang dan, dengan cara yang sama, tiba-tiba pulih. Ada dugaan yang terkait dengan beban besar dan sejumlah besar suara yang diputar pada saat yang sama. Ada juga asumsi tentang koneksi bug dengan zona reverb, tetapi ini tidak akurat.Itu mungkin saja. Banyak waktu telah berlalu sejak pengembangan, beberapa hal telah dilupakan, dan beberapa telah menjadi sama sekali tidak relevan, tetapi saya berharap artikel itu akan bermanfaat bagi seseorang dan dapat memberikan jawaban atas beberapa pertanyaan. Terima kasih semua dan semoga berhasil!