Membuat game itu tidak sulit. Melihat kembali proyek ponsel kecil di Unity3D

Ketika Anda memiliki gagasan tentang mekanik permainan baru, atau bahkan flash konsep menarik - segera Anda akan terobsesi dengan keinginan besar untuk mulai melakukan sesuatu. Kadang-kadang Anda menuliskan ide-ide semacam itu di suatu tempat dan membawa mereka kesempatan untuk menyalakan siklus pengembangan penuh nanti. Tapi saya menemukan tindakan sebaliknya. Game saya saat ini menjadi monster raksasa ini memakan waktu dan keuangan, dan tumbuh jauh lebih besar dari yang pernah saya pikirkan. Jadi, saya perlu mengembalikannya sebentar. Tetapi saya tidak bisa duduk tanpa pengembangan game, dan di waktu senggang saya sudah mulai mengerjakan proyek baru saya! Plus yang satu sangat berbeda dari yang sebelumnya, karena saya telah memutuskan untuk menargetkan ponsel. Jika Anda tertarik pada bagaimana proyek ini dilakukan, dari ide kecil hingga rilis final, maka mari selami itu!



Jelas, saya menceritakan tentang pengalaman dan visi saya, tetapi banyak hal akan umum untuk setiap proyek, dan mungkin Anda akan menemukan beberapa tips yang berguna untuk diri Anda sendiri.

Memahat pada fondasi ide

Gagasan utamanya cukup sederhana - mari membuat labirin, labirin! Meskipun Anda dapat menemukan beberapa game sederhana dalam genre seperti itu di toko, tetapi saya yakin Anda harus membawa sesuatu yang lebih ke dalam game daripada sekadar mengikuti genre klise. Saya memiliki kepedulian yang mendalam tentang desain game secara umum, menyukai cerita dan pengalaman petualangan penuh dengan awal yang berbeda dan akhir yang menonjol. Di sini saya tidak bisa membuat pengecualian untuk cita-cita saya. Selain itu saya ingin beberapa mekanik gameplay yang menarik. Pendekatan saya adalah menambahkan variabel lain ke seluruh pelarian konsep labirin. Dan setelah beberapa brainstorming, ide baru lahir. Itu adalah rantai dan sistem rantai-switch. Jadi pergerakan karakter utama dibatasi oleh panjang rantai dan jalur yang dipilih pemain. Dengan mengingat hal itu, Anda tidak hanya perlu menemukan pintu keluar tetapi juga untuk menemukan cara sesingkat mungkin! Dan bagaimana jika saya memberi tahu Anda bahwa rantai Anda cukup pendek dan Anda dapat melangkah lebih jauh hanya setelah saklar-rantai yang akan memberikan titik jangkar baru dan rantai baru dengan panjang yang berbeda. Sekarang, permainan mulai menjadi lebih sulit, karena Anda harus menemukan urutan sakelar-sakelar yang tepat di dalam labirin. Dan jika itu tidak cukup bagi Anda - maka mari kita tambahkan pintu, bahwa Anda perlu membuka dengan aktivator khusus di suatu tempat di dalam labirin dan kemudian untuk kembali masih berpikir tentang sakelar dan rantai.

Memahami batasan

Tentu saja, tidak mudah untuk merencanakan semua fitur di depan. Beberapa dari mereka dibuat karena keterbatasan teknis dan manajemen waktu yang ketat. Tujuannya adalah untuk membuatnya secepat yang saya bisa dan tidak untuk secara dramatis meningkatkan kompleksitas semua aspek permainan dalam proses pengembangan. Rantai dibuat menggunakan sambungan, dan tidak dapat diproses oleh fisika mesin game setelah beberapa lama, benar-benar pecah berkeping-keping. Jadi saya harus membatasi panjangnya dan masih bisa melanjutkan jalan. Memang, ada solusi untuk menulis skrip berantai kustom sepenuhnya memalsukan fisika nyata, tapi itu adalah tugas yang menghabiskan waktu yang tidak mampu saya lakukan.
Tetap saja, saya sudah berhasil menjaga panjang rantai, dan pemikiran awalnya adalah membuat ruang labirin kecil di mana Anda perlu menemukan jalan terpendek, tetapi itu tidak cukup. Jika seluruh permainan seperti itu, maka itu akan sangat membosankan karena Anda hanya memiliki satu tugas yang berulang tanpa mengubah pengalaman, atau bahkan kesulitan. Namun, gagasan-gagasan itu memainkan peran dalam pertandingan final.

Inspirasi dan pemikiran: Pengalaman prototipe

Setelah beberapa prototyping, jelas bahwa labirin, di mana Anda harus tersesat dari rute terpendek dan bahkan memiliki beberapa jalur mundur, adalah yang paling menarik. Jadi keputusan terakhir adalah menambahkan bagian gameplay terpisah satu demi satu - labirin besar dengan banyak sakelar dan labirin kecil dengan cara sesingkat mungkin. Semua dari mereka terhubung dengan beberapa koridor kosong untuk membebaskan pikiran pemain dari rasa tantangan yang konstan. Namun tepat pada saat pengujian muncul ide lain yang memberikan pemikiran kritis baru - kita membutuhkan lebih banyak mekanisme permainan. Karena berada di dinding yang sama labirin ini satu demi satu, bahkan dengan beberapa kurva kesulitan, masih belum cukup untuk menjaga perhatian pemain.

Untuk menambah rentang perhatian, jangan lupa bahwa game ini ditargetkan untuk platform Seluler. Jangan pernah mendesainnya untuk sesi permainan yang panjang tanpa istirahat. Saya telah memutuskan untuk melakukan penghematan pada setiap pergantian rantai, sehingga pemain dapat pergi kapan saja dan tidak pernah jauh dari sesi permainan sebelumnya. Tentu saja, saya memiliki beberapa niat tentang bagaimana permainan harus dimainkan, tetapi sesi tanpa gangguan maksimum yang saya maksudkan adalah sekitar 5 menit. Itu hanya termasuk adegan di mana musik disajikan.

Kembali ke variasi mekanika, saya telah menambahkan teka-teki yang melibatkan rantai sebagai alat untuk menyelesaikannya. Ini adalah solusi desain game yang bagus - untuk menggunakan kembali objek dunia yang sudah Anda kenal sebagai alat tujuan baru.



Ada berbagai ide dari banyak teka-teki yang berbeda dengan alat baru ini, tetapi keputusan akhirnya adalah menerapkan hanya satu jenis dengan variasi dalam kesulitannya. Jika Anda berpikir bahwa gim Anda membutuhkan semua gagasan baru dan variasinya, tetapi Anda tidak punya waktu untuk menerapkannya, maka berhentilah! Tujuan Anda di sini adalah untuk menyelesaikan permainan. Dalam hal ini, Anda tidak akan mengimplementasikan fitur-fitur itu sekarang, atau bahkan sampai akhir siklus pengembangan - satu solusi adalah memperbarui game nanti, dan yang kedua dan lebih radikal - untuk membuat game yang sama sekali baru nanti dengan semua yang kurang. fitur. Jika Anda memiliki produk inti di tangan Anda, maka akan lebih mudah untuk melanjutkan. Hanya saja, jangan sampai fitur untuk menghentikan rilis. Lakukan hanya jika mereka adalah bagian penting dari produk lengkap yang menambah pengalaman unik dan Anda tidak dapat membayangkan permainan tanpa fitur-fitur tersebut.

Menyingkirkan hal-hal teknis: Bagaimana dunia dibangun

Rantai dibuat dengan sambungan yang dapat dikonfigurasi dengan gerakan terkunci pada semua sumbu. Kemudian dipakai sebagai segmen rantai, dengan 4 batang kaku dihubungkan bersama oleh 4 sambungan dalam satu segmen. Sumber rantai mirip dengan sumur. Agar berfungsi dengan baik, saya baru saja menghapus segmen yang berada di bawah permukaan dan membuat yang baru ketika sambungan terakhir dari segmen tersebut mendekati permukaan. Juga, benda tegar sendi terakhir dibatasi untuk memiliki gerakan vertikal hanya untuk berdiri sebagai jangkar. Selain itu, tali memiliki bahan tabrakan khusus tanpa banyak gesekan.



Pemain itu dibuat dengan benda tegar yang memiliki ikuti sederhana untuk skrip target untuk memindahkannya. Dan target memiliki agen navigasi di atasnya. Jadi ketika kita memindahkan joystick kita, maka kita memindahkan target hanya dengan sistem navigasi, dan benda tegar pemain berusaha mencapai target dengan kekuatan fisik. Jika kita hanya memiliki sistem navigasi, maka rantai tidak dapat menghentikannya, dan pemain bertindak seperti orang tegar kinematik dengan kontrol posisi absolut. Satu-satunya masalah dengan aplikasi gaya adalah bahwa dengan jumlah variabel segmen rantai, kami juga memiliki variabel dalam massa yang melekat pada pemain. Maka jika Anda harus banyak massa di batas akhir rantai, itu akan meledak. Dan jika tidak, pemain akan terseret ke belakang oleh rantai atau tidak bergerak sama sekali. Jadi saya menerapkan perubahan massa relatif terhadap panjang rantai yang sebenarnya. Tetapi solusi yang paling menarik terhadap ledakan rantai - destabilisasi fisika-nya, adalah membatasi kecepatan maksimum pada bagian-bagiannya yang tunggal dengan skrip khusus.

Labirin itu sendiri terbuat dari labirin yang lebih kecil, teka-teki, dan koridor yang menghubungkan mereka semua. Ketika saya pertama kali mulai mendesain labirin itu - saya hanya mengambil pena dan kertas kuadrat dan mulai membuat sketsa dari dinding ke dinding. Tetapi setelah banyak perubahan karena prototipe yang sebenarnya, dan bagaimana itu dipengaruhi oleh rantai, saya yakin itu adalah cara paling tidak efektif dalam melakukan sesuatu. Jadi, saya telah membuat jendela editor khusus untuk labirin saya. Itu seperti pulpen dan kertas tetapi dengan keadaan selamat yang bisa menghasilkan labirin lengkap dari dinding, lantai, dan cetakan rantai-sumber. Saya juga menambahkan kontrol atas panjang rantai-sumber, dan itu adalah solusi lengkap untuk masalah merancang labirin.



Hanya perlu diingat bahwa untuk instantiasi waktu editor Anda harus menggunakan metode PrefabUtility dan bukan Instantiate umum karena jika tidak, Anda akan mendapatkan klon objek prefab Anda terlepas dari prefab asli.

Pemrosesan pos

Ini adalah pilihan pribadi tetapi saya suka pasca pemrosesan dan tidak bisa membayangkan permainan saya tanpanya. Bloom adalah opsi yang harus dimiliki, tetapi saya juga menyukai Depth-of-Field dan solusi FXAA sederhana. Dengan tumpukan pasca pemrosesan baru, langkah-langkah untuk mengimplementasikannya dengan benar cukup sederhana. Saya juga menambahkan bola pemicu di atas pemain, yang memiliki profil lain dengan efek Aberasi Kromatik , yang pindah ke pemain pada waktu sakelar. Plus, profil terpisah untuk sinematik akhir. Tetapi setelah salah satu pembaruan, semuanya berhenti berfungsi , dan setelah pengujian pada perangkat, saya menemukan masalah lain . Dengan sedikit RenderDoc , alasannya jelas dan segera diperbaiki, tetapi saya berharap bahwa kita akan melihat perbaikan resmi dari tim Unity.

Mulai dari jalan optimasi

Ketika game hampir siap, dan playthrough awal pada perangkat saya selesai, saya sudah mencoba untuk meluncurkan game pada perangkat yang tidak begitu kuat yang saya miliki sebelumnya dalam pengembangan. Itu menyedihkan. Saya telah memperhatikan penurunan kecil pada perangkat saya sebelumnya, tetapi setelah langkah-langkah awal dengan menyelesaikan masalah overheating, saya berpikir bahwa saya tidak akan pernah melihat kegagapan yang dramatis.

Untuk overheating - langkah-langkahnya mudah, saya tidak perlu 60fps, jadi kuncinya sampai 30. Ditambah scaler resolusi khusus yang membatasi ukuran layar pendek menjadi 720p. Satu trik lain dengan mengubah langkah-langkah waktu di Time Manager tidak berhasil bagi saya, karena ketergantungan pada perhitungan fisika yang berat. Ketika saya sudah mencoba untuk meningkatkan langkah waktu, rantai itu cukup sering meledak mencapai batasnya.

Semua pekerjaan itu dilakukan sebelum pengujian perangkat yang lemah. Jadi saya sudah mulai melihat lebih dekat ke profiler.

Satu hal yang menarik adalah saya memiliki terlalu banyak sumber audio yang diaktifkan sepanjang waktu. Tapi saya tidak pernah membutuhkan semuanya secara bersamaan, dan peristiwa memainkannya cukup deterministik. Saya telah berakhir dengan hampir semua sumber dinonaktifkan secara default, dan mengaktifkannya hanya untuk aktivasi suara yang diperlukan dan kemudian menonaktifkannya tepat setelah akhir suara.

Beberapa skrip mendapat manfaat dari pembaruan manual alih-alih yang eksklusif, terutama ketika saya memiliki banyak objek serupa dengan skrip yang sama dan metode Pembaruan di dalamnya. Cukup ganti nama metode Pembaruan Anda ke ManualUpdate dan panggil dari luar. Dalam kasus saya, semua teka-teki saya ada di tempat kejadian, dan mereka menyebut metode pembaruan mereka, juga setiap pilar di setiap puzzle memiliki metode pembaruan sendiri, dan bahkan pemicu pilar memiliki metode pembaruan mereka sendiri. Tanpa beberapa pembaruan otomatis dan metode pembaruan panggilan secara manual pada setiap objek dari satu tempat, saya telah berhasil secara signifikan mengurangi overhead panggilan metode internal Unity.

Yang terakhir tetapi salah satu hal terpenting dalam optimasi adalah bagian rendering. Jika Anda ingin mengirimkan game seluler Anda dengan Standard shader - maka Anda gila! Mungkin dalam beberapa kasus yang jarang terjadi dengan jumlah bahan yang kecil dan kompleksitas varian shader yang kecil, karena shader standar memiliki banyak sekali, Anda dapat mencapainya dengan hanya menargetkan perangkat tingkat atas. Namun dalam kasus saya, saya telah berakhir dengan hampir semua shader diubah untuk menggunakan yang khusus, berdasarkan varian permukaan ponsel. Tapi saya belum menemukan cara yang baik untuk mensimulasikan logam / kehalusan dengan model pencahayaan khusus, jadi hanya bahan logam mengkilap yang berakhir dengan shader standar. Namun, jika Anda melihat versi yang dikompilasi, maka tidak ada pilihan untuk memilih yang benar ketika Anda memiliki lebih dari 190 operasi di shader standar versus kurang dari 70 di custom. Ingat bahwa pendekatan PBR , yang mencakup shader standar standar, benar-benar intensif GPU dan terlalu rumit untuk seluler. Anda harus menggunakan shader yang dioptimalkan khusus untuk seluler sejak awal pengembangan. Buat mereka untuk dirimu sendiri, atau gunakan yang dibangun dalam Unity.

Perhentian berikutnya: Frame debugger

Tip kinerja berikutnya adalah untuk memeriksa debugger frame untuk istirahat batching yang tidak biasa. Atau hanya untuk melihat berapa banyak drawcall yang Anda butuhkan untuk membuat seluruh adegan.

Saya memiliki perilaku aneh ketika debugger mengungkapkan bahwa beberapa objek yang diberikan secara berurutan memecah batch meskipun memiliki materi yang sama. Bahkan pesannya tidak jelas karena dikatakan bahwa saya memiliki sumber cahaya yang berbeda untuk mereka. Tetapi seluruh adegan menggunakan satu-satunya sumber cahaya directional! Benda-benda itu memiliki bahan yang sama, dan semua propertinya sama! Tapi tidak semuanya karena saya hanya melihat ke material dan rendering properti. Alasan sebenarnya adalah bahwa saya mengubah sumber cahaya saya menjadi pemusnahan kustom oleh lapisan. Dan objek urutan melanggar berada di lapisan tertentu yang tidak menyala.

Bagaimanapun, kadang-kadang frame debugger menunjukkan urutan rendering yang aneh yang merusak batching. Beberapa kejadian itu konyol, dan koreksi material manual membuat-antrian membantu untuk menyelesaikannya.

Juga, frame debugger menunjukkan bahwa meskipun memiliki hampir semua objek yang diberikan sebagai statis, saya punya banyak batch yang tidak masuk akal. Hanya karena saya memiliki begitu banyak dari mereka, sehingga batcher membuat banyak jerat batch statis, dan tidak pernah mencoba mengelompokkan mereka berdasarkan posisi. Dalam hal ini, saya memiliki dinding labirin di satu layar yang terdiri dari 5 atau 6 kumpulan yang berbeda. Tapi itu terbuat dari bahan yang sama! Saya akhirnya hanya menambahkan objek lantai sebagai statis karena semuanya membuatnya dalam satu jala satu batch. Dan sisanya dibiarkan dengan dinding yang ditumpuk secara dinamis tanpa masalah, dengan antrean material mereka dikoreksi menjadi yang unik. Batch dinamis membuat beberapa hit pada CPU , tetapi dalam kasus saya, perbedaan bahkan pada perangkat yang lemah hanya marjinal dibandingkan dengan batch statis kustom melalui StaticBatchingUtility . Dan batching dinamis masih lebih efektif bagi saya untuk menyimpan drawcall daripada custom static di case edge.

Hal-hal lain yang ditunjukkan oleh frame debugger adalah bayangan dan kaskade. Jika Anda penasaran, maka setiap bayangan bayang-bayang adalah bayangan lain untuk seluruh layar. Jadi, jika Anda memiliki beberapa batch di dalam shadowpass maka gandakan jumlah itu dengan jumlah kaskade yang Anda miliki. Saya baru saja menonaktifkan kaskade setelah penemuan ini. Tapi saya masih membutuhkan bayangan real-time yang layak dan berakhir dengan menyesuaikan jarak kliping kamera dan beralih ke bayangan close-fit dengan kualitas sedang. Saya tahu bahwa mereka bukan yang tercantik, tapi itu jauh lebih baik daripada yang stabil dengan resolusi lebih rendah atau tidak ada bayangan sama sekali.

Yang terakhir di dalam frame debugger dan kinerja adalah pemrosesan pos. Bahkan dengan hanya beberapa efek diaktifkan, itu hampir yang paling berat - Bloom dan Depth of Field. Keduanya menggunakan pengambilan sampel frame ke resolusi rendah tetapi memiliki tekstur input yang berbeda dan filter shader yang berbeda. Saya sudah mengubah Bloom untuk menggunakan fast-Mode - filter persegi di dalam shader daripada lingkaran yang lebih kompleks. Sayangnya itu tidak cukup. Jadi saya berakhir dengan mengubah faktor skala resolusi di dalam frame buffer awal efek. Ini menggunakan setengah-Res secara default, tetapi saya telah melihat peningkatan besar ketika digunakan bukan setengah resolusi tetapi hanya sepertiga darinya. Mengecilkannya menjadi seperempat hampir tidak berpengaruh dengan visual yang semakin merendahkan. Jadi solusi saya untuk memposting pemrosesan di ponsel adalah sepertiga! Atau menggunakan solusi yang sepenuhnya khusus.

Hampir sampai: Polandia!

Secara alami, setiap proyek itu unik, dan Anda harus memikirkan proyek Anda secara khusus, tetapi di sini saya hanya ingin menunjukkan bagian mana yang telah saya putuskan untuk dimasukkan ke dalam proses pemolesan saya dan mengapa.
Langkah pertama pemolesan dilakukan tepat setelah uji alfa pertama dan sebelum optimalisasi kinerja. Dengan umpan balik awal, saya telah menambahkan fitur kecil yang hampir ada, tetapi belum cukup menonjol.

Yang pertama adalah lantai berwarna, bahwa saya memiliki visi sejak awal pengembangan, tetapi dalam proses yang sebenarnya semua palet yang saya anggap tampak tidak alami. Jadi di babak pertama, saya berakhir hanya dengan gradien warna dari terang ke gelap selama seluruh jalur permainan. Tetapi tes menunjukkan bahwa ini tidak cukup. Dengan sedikit perjuangan melalui semua kombinasi warna, yang tepat telah dibuat. Bahkan detail visual kecil ini memiliki dampak nyata pada perasaan game secara keseluruhan. Dengan perbedaan antara tahap, Anda memiliki lebih banyak rasa pencapaian dan kemajuan.

Gagasan lainnya adalah dorongan untuk memiliki lebih banyak kesenangan dan rasa dinamis dari pemain. Meskipun pada awalnya saya bukan penggemar, tetapi saya berhasil menemukan kompromi kecil yang terasa lebih baik tetapi tidak merombak nuansa tenang karakter tersebut. Itu adalah penguncian kristal di dalam pemain untuk tidak pernah berputar relatif ke dunia. Tetapi untuk pemain yang merasa seperti kristal dalam dihidupkan setiap gerakan. Sebenarnya, ketika saya masih kecil, saya memiliki bola yang memiliki satu lagi di dalamnya. Bagian dalam itu melayang dalam jumlah kecil zat cair yang tidak terlihat, dan ketika Anda menggulungnya di permukaan, itu tampak seperti melayang tanpa menggulung sama sekali. Fitur ini sedikit mengingatkan saya pada perasaan unik itu.

Setelah semua perubahan kinerja, game mulai berfungsi seperti yang dimaksudkan bahkan pada perangkat berkinerja rendah itu. Bukan yang terendah, tapi itu tidak masalah bagi saya. Dan kemudian saya punya waktu untuk memikirkan fitur-fitur lain yang akan berdampak pada perasaan game secara keseluruhan dan sangat penting untuk visi saya.

Yang pertama adalah meninggalkan goresan di lantai dan cukup cepat diimplementasikan sebagai kolam decals. Meskipun Anda mungkin tidak pernah melihatnya, tetapi jelas menambah suasana labirin.

Fitur kedua yang memengaruhi rasa keseluruhan di mata saya adalah beberapa batu di koridor yang seharusnya menambah lebih dinamis ke dunia dingin yang kosong. Itu hanya masalah visi, dan juga tanpa kesulitan diimplementasikan ke dalam pertandingan final. Itu menghadirkan perasaan yang aneh memuaskan setiap kali Anda melihat batu-batu kecil itu jatuh ke dalam kegelapan.

Titik rilis

Setelah semua pengujian selesai dan Anda puas dengan polesannya, Anda siap untuk rilis!
Bagi saya, tujuan utama sejak awal adalah untuk membuat pengalaman pemain tunggal tanpa gangguan. Jadi keputusannya jelas: tidak ada iklan, tidak ada pembelian dalam game, tidak ada kotak jarahan. Untuk fitur-fitur tersebut, Anda harus mendesain gim dari awal hingga sangat mengandalkannya untuk menjadi bagian penting dari pengalaman. Dalam kasus saya, saya tahu bahwa seluruh permainan untuk pemain rata-rata akan sekitar tiga hingga empat jam pengalaman. Jadi saya menempatkan harga tetap yang wajar dan membiarkannya pergi. Tidak cukup waktu berlalu sejak rilis untuk memikirkan penjualan besar dan juga belum ada promosi. Tapi sebagai pengembang, saya cukup puas dengan permainannya, dan jika ada orang yang menyukainya maka itu adalah kesuksesan bagi saya.

PS

Pada akhirnya, ada beberapa fitur yang tertinggal. Terutama yang masih harus dilakukan untuk menyelesaikan atmosfer permainan, tetapi itu bukan sesuatu yang mengubah pengalaman secara radikal, sehingga dapat dilakukan sebagai pembaruan pasca rilis. Sisa fitur tidak pernah bisa keluar. Sedih bagi saya, saya punya ide menarik tepat pada saat menguji rilis final. Saya pikir itu terjadi karena ada satu minggu jeda dalam pengembangan, dan saya mendapatkan tampilan baru setelah kembali. Mungkin suatu hari nanti akan ada permainan kedua, tetapi sekarang semua ide akan menunggu waktu mereka untuk dibawa kembali pada siklus pengembangan baru.