Beberapa tahun yang lalu, tim kami merasa terhormat untuk membuat "Almaty" seluler. Mengikuti aturan "kami membuat game, bukan teknologi" , kami membuat prototipe tentang apa yang sudah ada di mesin. Itu UE 4.9, berdasarkan pada model fisik - PhysX Vehicle, dan banyak rasa sakit (baik dengan dan tanpa).

Selanjutnya, tim kami menciptakan plugin open source PsRealVehicle , tersedia di bawah lisensi MIT . Plugin ini disesuaikan dengan fisika tank dan kendaraan roda untuk penembak jaringan yang sarat muatan, dan Anda dapat mengamati kerjanya kapan saja di proyek kami Armored Warfare: Assault .

Nama, penampilan, kata sandi.

Jelas. Saya melihat. Dan hanya untuk bisnis.

Repositori plugin

Dokumentasi Konfigurasi Utama

Digunakan dalam proyek: Perang Lapis Baja: Serangan

Sedikit sejarah, atau Kembali ke akarnya

Kami mulai mengerjakan proyek di Unreal Engine 4.9 . Pada waktu itu, fisika mesin "out of the box" hanya mendukung kendaraan roda empat, dan untuk "bangku" roda enam (LAV-400, kendaraan prototipe "tempur" pertama kami), kami harus segera menggunakan perakitan mesin khusus. Dengan fisika built-in tank itu bahkan lebih buruk: data tentang bagaimana semuanya bekerja dan dikonfigurasi, harus sedikit demi sedikit untuk memancing keluar dari kode.

Mengikuti aturan "prototipe" , kami telah membentuk persyaratan berikut untuk diri kami sendiri:

• Fisika harus mensimulasikan pergerakan tank (program minimum) dan kendaraan roda (sangat diinginkan - ini adalah fitur dari seri game AW).
• Server khusus harus menahan hingga 20 mesin per sesi online , dan klien harus menanganinya.
• Semua roda dan trek harus mengikuti penyimpangan permukaan, suspensi harus bekerja , dan tangki harus berayun.
• Pengaturan fisika harus ditentukan oleh nilai-nilai nyata (massa mesin, tenaga mesin) dan mengarah pada perilaku realistis (kemampuan untuk mengatasi jenis medan tertentu).
• Semakin sedikit kode teknis yang kami tulis, semakin baik: Epic Games harus membuat mesin, bukan kami .

Jadi, persyaratannya kurang lebih jelas, turun ke bisnis. Cukup cepat, kami merakit prototipe pertama, tank pergi, mobil melaju, tapi kami punya dua masalah:

1. Semua ini ditenggelamkan prosesor dengan sangat ceria.
2. Gambaran dunia yang diciptakan tidak ingin masuk ke dalam kerangka perilaku realistis alat berat. Tangki tiga puluh ton di bawah pengaturan apa pun tidak dapat naik 15 derajat (dan ini adalah salah satu opsi termudah). Kami menghabiskan banyak waktu untuk mengutak-atik pengaturan untuk simulasi dan gesekan lanskap, tetapi ini menyebabkan daya menarik ke nilai-nilai kosmik (20+ kali lebih banyak dari nilai sebenarnya, dan sebagai hasilnya, mobil berperilaku tidak stabil dan tidak dapat diprediksi), atau massa mainan peralatan (PhysX) bekerja dengan baik dengan massa kendaraan di wilayah satu setengah ton).

Desainer game dari ini jauh dari antusias. Programmer menangis, menusuk, tetapi terus makan kaktus (pesta membutuhkan solusi yang berhasil!). Prototipe disetujui oleh pimpinan dan dikirim untuk membuat versi alfa (omong-omong, video dari prototipe ada di Youtube . Tetapi waktu berlalu, dan harapan untuk masa depan yang lebih cerah untuk fisika seperti itu menjadi semakin berkurang. Pengaturan tidak cukup, perilaku mereka terlihat seperti ilmu hitam. Dan posisinya "Game, bukan teknologi" mengikat tangannya dengan caranya sendiri, setidaknya dengan keraguan apakah kita bisa menariknya.

Berbekal diam-diam dengan Wikipedia, pengetahuan sekolah sisa dan pengalaman bekerja pada fisika "pada ponton" ala Assassin's Creed, dalam beberapa hari saya membuat prototipe fisika tangki baru, yang membentuk dasar plugin PsRealVehicle. Dalam seminggu, pembuktian konsep diterapkan, tim-tim CTO ditunjukkan dan dilindungi oleh pengujian beban. Angka-angka mengatakan: menjadi fisika Anda.

...-..., dan dalam produksi

Jalan dari prototipe ke penjualan telah berjalan jauh lebih lama. Jika seminggu sudah cukup untuk pemeriksaan konseptual, maka butuh satu setengah bulan untuk versi beta yang memadai . Penciptaan rilis "prod" lengkap membutuhkan waktu sekitar enam bulan, penyempurnaan dan koreksi terus menerus - sepanjang seluruh waktu pengerjaan proyek. Dalam banyak hal, kami berutang kecepatan tinggi untuk pengembangan dan implementasi fisika dalam proyek kepada perancang permainan teknis Igor, yang datang ke tim kami pada waktu itu, yang ketelitiannya dalam aspek model matematika dan persepsi subjektifnya oleh para pemain menyebabkan hasil saat ini. Saya harus mengakui, dalam pengertian teknologi, saya adalah orang barbar : adalah tugas saya untuk membuat kapak untuk menebangi hutan. Setelah Igor memproses dan menyempurnakan model dengan orang lain, kami mendapat solusi terbuka siap-produksi yang dapat diskalakan dan sangat dioptimalkan untuk kebutuhan multipemain . Ada sesuatu yang bisa dibanggakan: dari banyak plug-in yang tersedia di pasaran (termasuk kendaraan PhysX bawaan), pengaturan tercepat dan paling transparan kami.

Ngomong-ngomong, ada beberapa kasus lucu. Ketika kami bekerja dengan PhysX Vehicle dan kendaraan roda dua kami yang sangat licin tidak dapat memanjat bukit kecil, saya mendengar celaan lebih dari sekali, mengatakan bahwa tim kami tidak dapat mengaturnya sehingga orang-orang memilikinya. Keputusan untuk menggunakan pengaya dibuat, termasuk di bawah pengaruh bingkai ini:

Perkembangan terbaru dari tentara Soviet! Tangki laba-laba yang bisa memanjat dinding 89 derajat . Tidak ada yang perlu dibahas: D

Fitur dari solusi kami

Sebelum saya beralih ke menggambarkan konfigurasi tank dan kendaraan di PsRealVehicle sebagai contoh AW kami: Assault, saya ingin menyebutkan beberapa hal yang membentuk dasar dari model fisik yang digunakan.

Pertama, kita dengan jelas mematuhi fakta bahwa kita tidak membuat simulator fisika tank, tetapi sebuah game yang cukup arcade. Menyedihkan, tetapi hanya sedikit orang yang membutuhkan tangki nyata dalam perilaku mereka - ini keren hanya pada video presentasi, dan tidak dalam kontrol, dan bahkan lebih dalam penembak. Pemain membutuhkan tank yang berperilaku seperti tank dalam arti bahwa blockbuster lainnya telah dibuat. Dan untuk bekerja pada perangkat biasa, dan bukan Titan.

Poin pertama memiliki konsekuensi: beberapa hal dalam permainan bekerja sangat palsu. Jika sesuatu terlihat seperti sebuah tank dan berperilaku seperti sebuah tank, maka itu adalah sebuah tank , dan tidak masalah bahwa di dalamnya adalah fregat kecil, atau bagian dari fisika diatur dengan sihir gesekan bersyarat. Salah satu konvensi ini adalah untuk mengontrol putaran alat berat dengan mengubah kecepatan sudut, dan bukan oleh gaya yang diterapkan pada roda dan suspensi. Secara konvensional, tangki berputar dengan X derajat per detik, karena kami memutuskan ini berdasarkan pertimbangan gameplay, dan bukan karena treknya berputar pada kecepatan ini dan itu.

Omong-omong, ini tidak meniadakan fakta bahwa "di bawah tenda" Anda dapat mengaktifkan fisika "nyata" rotasi, itu digunakan dalam prototipe pertama . Dalam cara yang baik, ada baiknya untuk mengencangkan pekerjaan suspensi sudut, pangkal roda dan sebagainya. Jika kita mulai membuat simulasi balapan, kita pasti akan kembali ke ini, tetapi untuk saat ini ini adalah salah satu item dalam daftar kemungkinan peningkatan

Struktur Tangki di AW: Assault

Hirarki kelas

AAwmVehicle adalah kelas C ++ utama yang bertanggung jawab untuk mesin dalam game, dibagi menjadi banyak komponen (gerakan - UPsRealVehicleMovementComponent , suara, VFX, statistik, baju besi, dan lainnya). BP_DefaultVehicle diwarisi darinya, yang merupakan lapisan tambahan untuk pengaturan default untuk semua mesin. Yang lainnya adalah cetak biru pengaturan untuk setiap peralatan dalam game.

Setiap mesin adalah sekumpulan data seperti itu:

• Cetak biru, di mana semua aset eksternal terdaftar, suara, properti a "kendaraan beroda / dilacak" ditetapkan, dan fisika diatur.
• Kerangka dan aset jaring yang terikat dengannya:
  - Aset fisik (tidak ada sihir, semuanya standar).
  - Pohon animasi.
• Tekstur (difus, peta normal, RMM).
• Bahan turunan (lambung, trek + kondisi hancur).
• Seperangkat selubung pelindung untuk sistem penetrasi.
• Kamera, pemeriksa ketinggian air, dan benturan tambahan lainnya.

Animasi tangki

Menyiapkan satu tangki adalah hal yang sepele, tidak peduli betapa rumitnya pohon animasi. Mengkonfigurasi lusinan tangki seperti itu dan tetap mengikuti perkembangan terbaru saat mengganti tulang, jaring, dan sebagainya adalah jumlah yang sama sekali tidak memadai untuk pekerjaan manual . Untungnya, dalam kasus kami, kami berbicara tentang "karakter" yang cukup terstandarisasi: tank dapat dibedah menjadi entitas dan menyebutnya stereotip. Ini, tentu saja, tentang penamaan tulang.

Pendekatan ini memungkinkan kami untuk menggunakan dasarnya pohon animasi yang sama, yang santo Ctrl + C / Ctrl + V dikalikan dengan sejumlah tangki dan tidak memerlukan dukungan apa pun kecuali pemeriksaan QA awal.

Semua keajaiban terjadi di dalam simpul-sipy khusus. Hal ini memungkinkan tidak hanya menstandarkan pohon, tetapi juga sangat mengurangi jumlah perhitungan per animasi (node ​​standar suka menggerakkan sistem koordinat bolak-balik).

Bahan tangki

Untuk semua bagian tangki, satu material master digunakan , disesuaikan oleh sepasang node Switch.

Selanjutnya kita mendapatkan pohon seperti ini:

  - M_Vehicles
  - - MI_Vehicles_Clean_Body
  - - - MI_Leopard2
  - - - - MI_Leopard2_LOD
  - - MI_Vehicles_Clean_Treads (dicentang "Treads")
  - - - MI_Leopard2_Treads
  - - - - MI_Leopard2_Treads_LOD 

"Bobot" yang sebenarnya di sini hanya M_Vehicles dan MI_Vehicles_Clean_Treads , semua instance lainnya hanya set parameter dan mengkonsumsi memori minimum dan ruang disk.

Secara umum, set aset grafis untuk tangki sangat standar untuk game apa pun.

Pekerjaan baju besi

Beberapa kali ketika berkomunikasi dengan kolega, muncul pertanyaan, mengapa masing-masing baju besi memiliki jala yang terpisah, dan mengapa kita tidak menggunakan sistem tabrakan Anrilov?

Sebenarnya, kita menggunakan tabrakan Anrilov yang biasa, tetapi hanya untuk "menangkap" peluru . Setelah proyektil telah mendorong dirinya ke dalam tangki, kerusakan dihitung secara poligon di seluruh lembar baju besi, dengan mempertimbangkan sifat masing-masing bagian, multilayer, refleksi ulang dari proyektil, corong kumulatif dan mekanika menarik lainnya.

Yang paling nyaman untuk kasus ini adalah membaca data mesh "telanjang", yang tidak kami hapus untuk server khusus.

Jaringan dan Optimalisasi Ekstra

Beberapa "near-tank" poin yang saya juga ingin sebutkan secara singkat.

• Semua pergerakan tank dilakukan hanya di server , klien hanya menginterpolasi nilai yang diterima. Tidak ada ekstrapolasi yang digunakan. Frekuensi sinkronisasi adalah 10 kali per detik .

  
  

• Bergantung pada ScreenSize dari tangki, kami melewatkan satu atau beberapa jumlah tick dari skeleton mesh, yang mencakup perhitungan semua animasi dan beberapa interaksi fisik. Jika tangki tidak terlihat di layar, itu adalah kotak bodoh dan non-animasi yang melayang di angkasa . Optimalisasi Tingkat Pembaruan bawaan, meskipun memiliki ide bagus, memiliki implementasi yang sangat kasar yang tidak memberikan peningkatan kinerja yang nyata. Terutama ketika datang ke ponsel.

  
  

• Untuk semua tangki, kecuali komponennya sendiri, semua komponen kecuali komponen yang paling dasar terpotong pada klien: kamera, checker, dan hal-hal lain yang membentuk tangki. Sebenarnya, mereka tidak memiliki apa-apa selain penampilan .

  
  

• Tangki LOD1 khusus dikemudikan di server khusus. Lebih sedikit puncak - lebih sedikit penggunaan CPU. Selain itu, pembaruan posisi potongan baju pelindung kustom terjadi hanya pada saat tembakan proyektil: tidak masuk akal untuk memperbarui keadaan setiap bagian tick.

Aku, Diriku & Tank

Di Pushkin Studio, kami percaya bahwa pertukaran pengalaman pengembangan sangat penting, termasuk untuk pertumbuhan tingkat profesional dalam tim. Proyek Open Source adalah komponen penting dari pendekatan ini, dan saya senang bahwa saya dapat memperkenalkan kepada komunitas teknologi seperti PsRealVehicle .

Menurut pendapat saya, sangat penting bahwa kita sendiri menggunakan semua plugin dan utilitas yang diterbitkan oleh kami setiap hari. Setelah semua, jalan yang jelas ditunjukkan oleh Epic Games sendiri adalah bahwa keberhasilan teknologi yang baik adalah menggunakannya oleh para pengembang sendiri dalam produk mereka sendiri. Sekarang kami sudah bekerja pada versi UE 4.20 , plugin kami telah berjalan sejauh ini dengan kami, dan kami tidak akan berhenti!