Kami telah bekerja dengan Unity untuk waktu yang lama dan mau tidak mau mengundang orang-orang mereka ke Pixonic DevGAMM Talks, yang diadakan pada bulan September. Insinyur Lapangan Valentin Simonov mengatakan bagaimana merencanakan arsitektur game dengan mempertimbangkan keunggulan teknologi baru. Unity telah mengusahakannya selama beberapa tahun untuk mencapai tingkat kinerja yang sebelumnya tidak dapat dicapai. Anda dapat mendengarkan presentasi di YouTube, dan membaca transkrip dengan slide tepat di bawah potongan.
Bagaimana jika saya mengatakan bahwa Anda dapat meningkatkan produktivitas game Anda hingga 10 kali lipat? Sebenarnya, ini tidak sepenuhnya benar, tetapi ada beberapa kebenaran dalam setiap lelucon. Saya ingin berbicara tentang apa yang sedang kami kerjakan sekarang, apa yang akan menjadi masa depan Persatuan dan apa yang dapat Anda gunakan sekarang.
Unity membuat game yang sama sekali berbeda. Berikut adalah beberapa contoh yang saya mainkan sendiri. Mereka menggunakan fitur yang berbeda dan mereka membutuhkan kinerja yang berbeda, pendekatan pengembangan yang berbeda.
Dan kami sedang mengerjakan proyek yang kami sebut Kinerja secara Default. Ini adalah beberapa fitur khusus yang, jika digunakan dengan benar, akan mencapai peningkatan kinerja yang signifikan. Dalam beberapa tugas, kami mengukur x10 dan bahkan x11. Terutama dalam masalah mensimulasikan sejumlah besar objek yang saling berinteraksi.
Tetapi ketika kita berbicara tentang Perfomance secara Default, kami berarti bahwa Anda harus mengubah pendekatan untuk pengembangan, sangat mengubah pendekatan untuk arsitektur permainan. Dan, pada kenyataannya, tidak semua orang membutuhkan ini.
Sebuah pertanyaan populer: "Apa yang Anda lakukan di ECS Anda? Anda menghapus semua GameObject, menghapus semua Transform, hierarki dan komponen? " Tidak, kita semua meninggalkannya. Anda dapat bekerja dengan Unity persis sama seperti sekarang, tetapi jika Anda ingin lebih banyak kinerja, Anda perlu tahu tentang teknologi yang ingin saya bicarakan secara singkat.
Dan saya ingin menyebutkan teknologi lain yang disebut Scriptable Render Pipelines (SRP) - memungkinkan Anda untuk secara lebih efisien menulis saluran render untuk gim Anda. Anda mungkin melihat demo yang kami perlihatkan di salah satu Unite. Di sini, di PC secara real time, sejumlah besar unit disimulasikan, sekitar 60 ribu (mencapai 100 ribu dan mulai sedikit melambat):
Dan fitur-fitur baru yang ingin saya bicarakan adalah: Entity Component System (ECS), Sistem Kerja C #, superkompiler Burst baru kami, dan Scriptable Render Pipelines (SRP).
Saya ulangi: terserah Anda untuk memilih apakah Anda ingin melanjutkan bersama kami, mempelajari teknologi baru, atau Anda OK untuk mengembangkan game yang menghasilkan uang dengan baik dan hanya dibuat.
Untuk memahami apa yang kami coba selesaikan, penting untuk memahami keadaan besi pada tahun 2018.
Perhatikan bagaimana kinerja dan jumlah core CPU meningkat. Dari satu titik, Kinerja Single-thread bahkan turun. Artinya, kita sekarang memiliki banyak inti, tetapi produktivitas mereka tidak tumbuh begitu cepat. Karena itu, kami ingin menggunakan kekuatan semua inti.
Ponsel saya memiliki 8 core: 4 kuat dan 4 lemah. Dan telepon modern dapat bekerja secepat komputer modern (tetapi tidak terlalu lama karena terlalu panas). Anda juga perlu memahami bahwa peningkatan kinerja tidak hanya menggunakan semua inti, tetapi juga mengoptimalkan kinerja inti tunggal.
Dan gambar terakhir, yang selalu kami berikan sebagai contoh bagaimana kinerja proses naik dan kecepatan akses memori tidak meningkat banyak:
Dapat dilihat bahwa sekarang akses ke memori sangat lambat. Pabrik prosesor melakukan banyak hal untuk meratakan perbedaan ini - tambahkan cache, CPU terlibat dalam perhitungan spekulatif, mencoba memprediksi kode mana yang akan dieksekusi selanjutnya. Dan jika Anda tidak memikirkannya saat membuat game (atau saat kami membuat mesin untuk Anda), maka kami tidak dapat memanfaatkan sepenuhnya prosesor modern.
Banyak dari Anda cenderung menghabiskan waktu berjam-jam untuk melihat gambar yang sama di Unity:
Di sini Anda dapat melihat bahwa ada multithreading, tetapi inti dan utas yang tersisa sebagian besar tidak sibuk. Sesuatu sedang dilakukan, tetapi saya ingin menempati mereka sepenuhnya.
Sekarang kita punya rendering, ini kotak hitam. Anda punya pilihan: Maju atau Ditangguhkan, ditambah berbagai pengaturan untuk material, shader, Command Buffers, dan sebagainya. Anda dapat membuat gambar yang indah, tetapi banyak algoritma yang sangat sulit diimplementasikan.
Dan kita semua tahu tentang arsitektur di Unity: komponen, GameObjects, hierarki Transforms, semua kode, semua data di MonoBehaviour dan setiap komponen memproses datanya.
Tetapi ada masalah dengan keadaan saat ini. Cepat atau lambat Anda menemukan ini dan memahami bagaimana Anda perlu dan tidak perlu melakukannya. Hirarki objek itu sendiri memiliki overhead tertentu, dan beberapa entitas tidak harus menjadi GameObjects sama sekali. Dan jika Anda memiliki sejumlah besar komponen dan pembaruan dari mereka, maka semuanya menjadi jauh lebih lambat. Saya pernah menulis
artikel ini , yang masih relevan jika Anda ingin tahu bagaimana tidak melakukannya.
Dan yang paling penting dalam konteks prosesor adalah bahwa semua komponen, semua data tersebar di memori, yang memecah penggunaan cache prosesor.
Sekarang saya ingin cepat melalui fitur baru.
Saya tidak akan terlalu fokus pada apa itu ECS dan bagaimana cara kerjanya. Intinya adalah bahwa kita memiliki Entitas, yang hanya merupakan ID entitas tertentu dalam game - mereka menyimpan data dalam bentuk komponen, mis. hanya data, tidak ada kode. Dan sistem memproses Entity dengan komponen tertentu dan entah bagaimana mengubah data ini.
Mengapa kita melakukan ECS kita dan bagaimana hal itu lebih baik daripada pesaing? Ada beberapa poin. Pertama, tidak cukup resmi, tetapi kami berpikir bahwa kami akan melakukan mesin sekarang. Jelas bahwa kita tidak ingin menyingkirkan GameObjects, komponen Unity saat ini, sepenuhnya membuang semuanya dan menginstal ECS. Tapi kami ingin pindah ke mesin yang lebih baik.
Kami mengandalkan kinerja tinggi. Belum lama ini, Mike Acton bergabung dengan kami (jika Anda berada dalam pengembangan C ++, Anda tahu bahwa dia adalah salah satu penginjil Pemrograman Berorientasi Data). Dan kami ingin seluruh sistem bekerja secepat mungkin - lebih cepat dari C ++.
Kami juga memikirkan bagaimana mengintegrasikan berbagai hal secara berbeda ke dalam ECS. Beberapa waktu yang lalu, kami mengumumkan bahwa kami membuat jaringan baru dan juga berdasarkan ECS - dimungkinkan untuk membuat game multipemain pada ECS dan membagikan kode antara klien dan server.
Bekerja pada alat debugging di Unity. Yaitu sementara ECS ada, seolah-olah, terpisah dari GameObjects dan komponen, dan ini sangat merepotkan. Kami ingin menyederhanakan banyak hal.
Sekarang ada DebugView yang terlihat seperti ini:
Di sini Anda dapat melihat Entitas seperti apa yang Anda miliki, sistem apa berapa banyak waktu yang diperlukan untuk memproses, sistem mana yang bekerja dengan komponen mana dan untuk setiap komponen yang dapat Anda lihat di inspektur, data apa yang dimiliki masing-masing Entitas dalam komponen (Saya perhatikan bahwa API sering berubah dan banyak Tutorial mungkin sudah usang).
Juga, jika Anda mendengar tentang pengembangan baru Unity for Small Things (ini adalah runtime yang sangat kecil yang memungkinkan Anda membuat game untuk pengirim pesan instan) - semuanya juga dibangun di atas ECS di sana.
Baru-baru ini, ledakan perkembangan dan transisi ke ECS adalah teknologi yang sangat populer dan semua orang perlu mengetahuinya.
Kami memiliki konferensi untuk pemrogram, sehingga sulit dilakukan tanpa slide kode. Ada banyak kode di sana, jadi sulit untuk mengeluarkan beberapa jenis yang dapat dipahami untuk membuat sesuatu menjadi jelas.
Bahkan, saya mengambil satu sistem dari contoh yang bekerja dengan C # Job System (lebih lanjut tentang itu nanti), dan kami melakukan banyak hal untuk mengurangi jumlah kode, menambahkan sintaks shugar.
Ada sistem yang bekerja dengan komponen RotationData dan juga membutuhkan transformasi GameObject, yang diwakili oleh TransformAccessArray khusus. Dan setiap pembaruan dari sistem yang kita buat Pekerjaan, jalankan Pekerjaan ini, pembaruan di suatu tempat, dapat dibagi menjadi beberapa kelompok dan dieksekusi di utas yang berbeda.
Bagaimana cara menggunakannya dalam proyek? Sama seperti implementasi ECS lainnya, Anda perlu memahami bahwa Anda harus berpikir dengan cara yang sama sekali berbeda (tidak seperti GameObjects dan Transforms). Dan biasakanlah ide ini. Jelas bahwa Anda harus mulai dari awal proyek, karena saya sangat sering mendapatkan pertanyaan seperti "kami membuat game dan ingin beralih ke ECS - bagaimana?". Dalam permainan yang sudah selesai, ini sangat sulit dilakukan.
Kita perlu memikirkan interaksi dengan Unity, karena ECS hidup secara terpisah, di dunianya yang kecil. Kami memberikan beberapa peluang untuk berinteraksi dengan GameObjects dan Transforms, tetapi fisika, rendering, dll., Ini semakin rumit. Dan sementara Anda perlu memasang dengan fakta bahwa banyak antarmuka yang akrab tidak akan tersedia, tetapi kami juga sedang mengerjakan ini.
Dan segera Anda perlu memikirkan fakta bahwa Anda akan menulis sistem dalam Sistem Pekerjaan, yang jauh lebih efisien.
Beberapa kata tentang Sistem Kerja. Kami ingin membuat cara yang sangat sederhana untuk menulis kode multi-utas. Pada saat yang sama, tulis dalam C #, periksa semuanya untuk Anda, jangan berikan kesempatan untuk membuat kesalahan atau tunjukkan mengapa, di mana dan bagaimana Anda membuatnya. Kami membatasi fitur bahasa yang dapat Anda gunakan dalam Pekerjaan dan memanggil subset ini C # Kinerja Tinggi C #. Anda tidak memiliki referensi dalam kode Pekerjaan Anda, tidak ada garis, semua data perlu disalin - Anda tidak dapat menggunakan sejumlah besar fitur bahasa, membuatnya jauh lebih sulit untuk memotret multi-threading di kaki Anda.
Kami juga menghadirkan koleksi dan integrasi yang sangat cepat dengan ECS. Struktur ECS dan Sistem Sistem Pekerjaan ini memungkinkan untuk eksekusi kode yang sangat cepat.
Pada saat yang sama, kami tidak hanya memberi Anda kesempatan untuk menggunakan teknologi ini - kami bekerja dengan sistem ini sendiri dan membuat API baru sehingga dapat digunakan di Jobs.
Kami membuat Async Raycasts untuk fisika, dengan mana Anda dapat mengatakan, "Saya ingin 600 rakecast, lakukan kepada saya suatu hari nanti, tolong." Kami berupaya memastikan bahwa, dengan menggunakan teknologi ini, dimungkinkan untuk memperluas sistem saat ini, misalnya, animasi melalui Playbles API. Dan kami berpikir untuk membuat sistem baru di Unity yang tidak akan ditutup di C ++, dan yang kodenya akan berada di C # dan tersedia untuk Anda.
Jika Anda mengambil kode Ayub, itu sangat sederhana. Pekerjaan adalah struktur di mana ada metode Jalankan, di mana kita melakukan pekerjaan dengan menjalankan Pekerjaan ini. Dengan demikian, Penjadwal internal kita suatu hari nanti akan mengerti di mana lebih baik untuk menjalankannya, akan menyelesaikan semua dependensi. Di sini kita mendapatkan JobHandle, yang dapat kita gunakan sebagai ketergantungan untuk beberapa Pekerjaan lain.
Bagaimana cara menggunakannya dalam proyek? Baik jika Anda akan menggunakan Pekerjaan sejak awal, tetapi ini tidak perlu di sini. Jika Anda memiliki beberapa jenis sistem yang kritis Performa, misalnya, simulasi, pathfinding, jaringan atau yang lainnya - Anda dapat mengetahui cara mengoptimalkannya dengan alat ini.
Tetapi untuk ini, Anda perlu mengambil beberapa langkah besar, pahami cara menyimpan data dengan benar. ECS, pada kenyataannya, memungkinkan kita untuk menyimpan data dengan benar, karena kita memisahkan data dari kode dan implementasi ECS kita menyimpan data komponen secara linear dalam memori, dan, berjalan melalui komponen-komponen ini oleh beberapa sistem, Anda menggunakan semua kemampuan prosesor, semuanya disimpan dalam cache dan dll. Kami berusaha melakukannya dengan sangat cepat.
Kemudian Anda memecah pekerjaan ini menjadi tugas paralel, menulis kode Pekerjaan dan menjalankannya. Dan (mungkin) semuanya bekerja untuk Anda. Tentu saja, Anda perlu menguji dan, yang paling penting, uji pada platform target, tergantung pada jumlah core, dll. Tetapi penggunaan Sistem Pekerjaan dan ECS, seperti yang saya katakan, juga sangat mempengaruhi bagaimana Anda merencanakan arsitektur game Anda.
Maka semuanya jauh lebih sederhana. Burst Compiler adalah teknologi unik kami, kompiler khusus dari subnet C # (Kinerja Tinggi C #) ini ke dalam kode mesin platform saat ini, yang akan Anda terbitkan ke proyek Anda.
Orang-orang melakukan sihir yang mungkin tidak ada yang mengerti kecuali mereka, tetapi hal ini mempercepat kode Pekerjaan 10 kali, yang sangat keren. Dan yang paling keren adalah itu tidak memerlukan tindakan apa pun dari Anda - jika Anda memiliki kode Pekerjaan, Anda cukup menambahkan atribut [BurstCompile], Burst mengkompilasi kode Anda, dan Anda mendapatkan kinerja "bebas". Ini adalah teknologi baru kami dan Anda dapat mencobanya sekarang.
Dan hal terakhir yang ingin saya sebutkan secara singkat adalah Scriptable Render Pipeline (SRP), yang telah kami kerjakan untuk waktu yang sangat lama dan yang dirancang untuk memberi Anda kesempatan untuk menulis rendering yang sangat khusus untuk game spesifik Anda.
Render Pipeline adalah beberapa algoritma yang melakukan Culling (objek mana yang akan digambar), Rendering dan Post-processing. Sekarang kami memiliki kotak hitam, yang Teruskan atau Ditangguhkan - mereka sudah bagus, kami mendapatkan grafik yang sangat keren di ponsel, di PC, di konsol. Tetapi mereka memiliki banyak batasan, karena mereka tidak dapat diperluas. Menggunakan fitur baru ini, SRP, Anda dapat menulis Pipeline Anda, Anda dapat menghapus sesuatu dari sana, menambahkan, melakukan apa pun yang Anda inginkan.
Kami saat ini sedang mengerjakan dua contoh jaringan pipa. Satu LWRP, yang kami targetkan pada ponsel dan perangkat yang lemah, dan HDRP, yang kami targetkan pada PC, konsol, dan di mana orang-orang yang sangat terkenal di dunia industri bekerja. Sebelum itu, mereka membuat game AAA. Tentunya, Anda melihat demo kami Book of the Dead.
Di sini kami menggunakan HDRP untuk menunjukkan kekuatan penuh dari teknologi ini.
Untuk menggunakan ini, Anda juga perlu mengambil langkah heroik yang cukup besar, karena dengan Pipeline baru, hampir tidak ada yang kompatibel dengan apa yang kita miliki sekarang. Yaitu jika Anda memutakhirkan dengan Legacy, maka kami memberikan utilitas yang akan memutakhirkan sebagian besar materi untuk Anda, tetapi Anda harus menulis ulang shaders Anda, mis. tekstur kemungkinan besar akan terlihat berbeda.
Sangat keren jika Anda bisa mulai dari awal dan bereksperimen dengan Pipeline Anda. Jika Anda ingin melakukan sesuatu di Pipeline Anda, silakan hubungi kami.
Sekali lagi, pahami apa yang Anda butuhkan, karena sekarang Anda memiliki lebih banyak peluang untuk melakukan sesuatu, tetapi Anda akan membutuhkan orang-orang yang dapat melakukannya atau Anda perlu belajar bagaimana melakukannya.
Menurut saya, ini keren, karena mereka yang maju bersama kami dengan teknologi baru ini akan lebih laris di pasar. Itu saja, saya harap seseorang akan pergi dan melihat teknologi ini, membuat game yang indah dan keren.
Pertanyaan dari audiens
- Kapan saya bisa mendapatkan ECS dan mengembangkannya?- Anda dapat menggunakan ECS, masalahnya adalah bahwa dalam bentuk saat ini lebih ditargetkan untuk orang yang berfokus pada kinerja, mis. semacam proyek AAA. Dan tugas Unity adalah membuat Performance by Default tersedia untuk semua orang. Oleh karena itu, kita memerlukan sistem tertentu, tambahan untuk ECS, yang akan memungkinkan kita untuk menggunakan ECS dengan kemudahan yang sama seperti kita menggunakan MonoBehavior sekarang. Meskipun tidak ada add-on seperti itu, saya tidak berpikir bahwa ECS akan dirilis dalam rilis penuh. Dan ternyata kami membuat fitur yang akan digunakan 1% dari pengguna kami. Dan ini bukan tugas Persatuan. Saya tahu orang-orang yang sudah menggunakan ECS dalam produksi, hanya perlu diingat bahwa fitur ini masih dalam pengembangan dan sekarang kami sedang memecahkan pertanyaan tentang bagaimana membuat antarmuka yang paling nyaman. Dan tugas selanjutnya (yang tidak kalah sulit) adalah bagaimana membuat semacam API yang hidup di atas ECS ini dan memungkinkan Anda untuk menggunakannya dengan kemudahan yang sama seperti MonoBehaviour. Yaitu tidak ada jawaban untuk pertanyaan "kapan tepatnya".
- ECS dan item lainnya difokuskan untuk mengambil satu GameObject dasar dan membuat 150 ribu klonnya dan mengelolanya. Tetapi bagaimana jika saya memiliki beberapa objek, tetapi mereka memiliki entitas yang berbeda?- Anda dapat, pada prinsipnya, tidak melakukan apa-apa, teknologi ini tidak mengharuskan Anda untuk menggunakannya. Jika Anda bisa mendapatkan peningkatan kinerja menggunakan teknologi ini, Anda harus menggunakannya. Jika ini tidak relevan untuk Anda, maka Anda terus menggunakan Unity apa adanya. Karena itu, tolong jangan panik.
- Kami memiliki klien di Unity, server di .NET, kami mencoba server di Unity, tidak ada hasilnya. Tetapi pada saat yang sama, saya ingin menggunakan teknologi yang ada di Unity di server juga.
- Kami sedang mengerjakan ini dan memahami bahwa sekarang kami tidak dapat memberikan solusi server yang efektif. Kami membeli perusahaan Multiplay beberapa waktu lalu untuk membuat hosting berkualitas tinggi untuk game Unity. Kami melakukan jejaring secara terpisah dan secara terpisah berkomitmen untuk mengoptimalkan mesin sehingga lebih banyak hal yang dapat dibuang. Oleh karena itu, ketika semuanya datang bersama, kami akan memiliki solusi multipemain yang sangat baik.
Lebih banyak pembicaraan dengan Pixonic DevGAMM Talks