Get best of the week

Menguji mesin game Amazon Lumberyard. Pendekatan dan Alat

Amazon Permainan. Kedengarannya tidak biasa? Bagaimana cara menguji produk untuk pengembang dan gamer? Di bawah pengujian singkat dari mesin permainan Amazon Lumberyard, pendekatan dalam pengujian manual dan otomatisasi, serta alat yang digunakan pada proyek.



Lumberyard adalah mesin game lintas platform tempat Anda dapat membuat game gratis untuk sebagian besar platform modern: PC, Mac, iOS / Android, semua konsol, termasuk kacamata realitas virtual. Ini juga sangat terintegrasi dengan Amazon Web Services dan layanan siaran permainan Twitch.

Di bawah potongan video dan transkrip dari laporan Artem Nesiolovsky dari konferensi Heisenbug .




Tentang pembicara: lulus dari Institut Teknik Fisika Moskow, Fakultas Sibernetika, lebih dari 8 tahun dalam pengembangan dan pengujian. Dia bekerja baik pada proyek desktop, seperti GeForce Experience, MMORPG Lineage II online, dan di ponsel - game Cut the Rope, serta di proyek web Yandex.Images web. Dia saat ini seorang insinyur otomatisasi di Amazon pada proyek Amazon Lumberyard.

Struktur pos


  • Mesin permainan: fitur, serta perbedaan antara pengujian mesin dan pengujian game.
  • Pengujian manual: bagaimana kami mencoba mencari tahu cakupan fitur proyek dengan tes fungsional.
  • Otomasi: kesalahan dan benjolan yang kami isi dan perlakukan setelahnya.
  • Alat yang kami gunakan untuk mengotomatisasi mesin kami.
  • Bug menarik dari proyek kami yang mungkin Anda temui saat Anda bermain game sendiri.


Narasi lebih lanjut atas nama pembicara.



Mengapa Amazon melakukan permainan sama sekali? Pada 2014, Amazon, seperti banyak raksasa teknologi, mencatat bahwa game menjadi bentuk hiburan terpopuler kedua bagi umat manusia. Yang pertama, anehnya, adalah televisi, atau lebih tepatnya, segala sesuatu yang berkaitan dengan streaming video (YouTube, Netflix, dan lainnya). Pengembang game juga mulai menggunakan layanan AWS lebih aktif untuk game online mereka.

Amazon memutuskan untuk membangun ekosistem di tiga pilar: buka studio game-nya untuk membuat game yang kemudian akan ditonton orang dan ditonton di Twitch. Game-game ini juga akan menunjukkan ide-ide gameplay menarik apa yang dapat diimplementasikan menggunakan AWS Cloud.

Bagaimana semuanya dimulai?


Pada 2004, perusahaan Jerman Crytek merilis game bernama "FarCry". Setelah beberapa waktu, Crytek mulai melisensikan mesinnya, di mana game itu dibuat, sehingga perusahaan pihak ketiga dapat mengambil mesin yang sudah jadi dan mulai membuat game, gameplay, mengisinya dengan konten tanpa investasi besar dalam teknologi. Ketika Amazon mulai bermain game, ia juga segera membuka beberapa studio dan mulai mengembangkan beberapa game.

Agar setiap studio tidak menciptakan sepeda - mesin rendernya sendiri, sistem animasinya, fisika, dan sebagainya, Amazon melisensi CryEngine versi 3 dan meluncurkan pengembangan beberapa game sekaligus. Grand Tour telah dirilis di Xbox dan PlayStation. Dua lagi sedang dalam pengembangan: MMORPG "Dunia Baru" dan penembak online "Crucible". Setelah pengembangan game-game ini telah dimulai, Amazon mulai menyediakan secara gratis mesin di mana game-game ini dikembangkan. Karena sangat terintegrasi dengan layanan cloud Amazon, Anda dapat menarik lebih banyak orang untuk menggunakan AWS.



Mesin gim adalah seperangkat API, mesin gim untuk membangun gim masa depan. Agar pengembang tidak perlu menulis sistem permainan mereka sendiri, Anda bisa mengambil satu set API, yaitu engine, dan mulai menulis logika game Anda sendiri, tambahkan konten di sana dan terlibat dalam kreativitas, alih-alih mengembangkan teknologi dari awal. Juga, beberapa mesin memiliki editor. Ini adalah program desktop tempat Anda dapat membuat level, yaitu membuka level Anda dan menambahkan konten dan logika permainan di sana.

Daripada berbicara lama, terkadang lebih mudah untuk menampilkan satu video:

Tautan ke video 8: 33-9: 53

Inilah editor kami dan antarmuka-nya. Sebuah game diluncurkan di dalamnya, yang kami sediakan bersama dengan mesinnya. "Starter Game" ada sehingga orang dapat masuk, bermain, mengubah sesuatu dan mencari cara kerjanya.

Secara umum, game 3D dapat dibayangkan sebagai satu set objek tiga dimensi yang bergerak dalam dunia tiga dimensi dan entah bagaimana berinteraksi satu sama lain. Dalam video ini Anda dapat melihat:

  • geometri statis dengan tekstur: bumi, batu, rumput, pohon;
  • geometri dinamis - karakter dianimasikan, bereaksi terhadap tindakan pemain;
  • antarmuka pengguna: tampilan tugas di sudut kiri atas.

Pemain dapat bertemu dengan karakter yang bermusuhan, logika permainan akan muncul, itu akan memungkinkan untuk menembak - robot menembak sebagai tanggapan. Tentang fisika: karakter akan mulai menembaki barel, mereka akan bergerak dari tabrakan dengan tembakan dan dari berinteraksi dengan karakter. Di editor kapan saja Anda dapat keluar dari mode permainan dan kembali ke mode pengeditan, di mana Anda dapat segera mengubah properti objek, memindahkannya, dan ini akan segera muncul di gameplay. Bayangkan kira-kira jumlah tempat di mana ada yang salah, rusak dan berhenti bekerja dengan baik?

Bagaimana cara menguji mesin?


Pengujian mesin didasarkan pada tiga poin utama. Yang pertama adalah menguji editor dan alat: operasi yang benar, alat harus terbuka, tidak ada kerusakan, semuanya harus ditampilkan dengan benar, skrip pengguna harus dieksekusi tanpa kesalahan, proses pembuatan game tanpa disertai bug. Hanya pembuat game yang akan menggunakan editor. Yang kedua adalah menguji mesin itu sendiri atau API mesin. Mesin permainan, pada gilirannya, adalah bagian dari kode yang akan bekerja termasuk di komputer pemain. Bagian dari proyek ini diuji melalui pembuatan level dan permainan sebelumnya. Selanjutnya, level yang dibuat dapat diuji pada setiap build engine yang baru untuk memastikan bahwa semua elemen gim yang digunakan pada level satu atau lainnya berfungsi sebagaimana mestinya.Dan komponen ketiga adalah pengujian infrastruktur dan kompatibilitas: mesin dapat dikonfigurasi dan dibangun dengan parameter yang berbeda, permainan dapat digunakan untuk berbagai perangkat, dan itu akan terlihat dan bekerja hampir sama di mana-mana.
Fitur proyek

Fitur pertama - kami mendukung sebagian besar platform game yang ada. Terlepas dari kenyataan bahwa editor itu sendiri hanya berfungsi di PC, runtime, mis. Gim ini dapat dibangun di atas Mac, smartphone, konsol, dan bahkan kacamata realitas virtual.

Fitur kedua - pengguna kami - ini adalah dua jenis orang dengan permintaan yang sama sekali berbeda. Di satu sisi, ini adalah pengembang, programmer, artis, dan desainer yang akan bekerja untuk membuat game. Dan di sisi lain, ini adalah gamer, di mesin-mesin di mana gim tersebut kemudian akan bekerja. Persyaratan untuk kedua kelompok ini sangat berbeda.

Fitur ketiga - dalam program semacam itu yang memungkinkan Anda membuat sesuatu yang baru, berbagai kemungkinan produk dari aplikasi ini seluas mungkin tersirat di muka. Di mesin kami, Anda dapat membangun game apa saja, mulai dari sesuatu yang sederhana, seperti Tetris, dan berakhir dengan proyek online yang kompleks, yang dimainkan oleh ribuan orang pada saat yang bersamaan.

Ketiga fitur ini sangat memengaruhi jumlah skrip khusus, yang masing-masing harus diuji.



Lihat screenshot ini dan bayangkan berapa banyak test case yang dapat Anda tulis hanya untuk bagian fungsionalitas ini? Secara total, kami memiliki lebih dari 11 ribu kasus uji pada proyek dan basis data ini bertambah sekitar 3-4 ribu kasus uji setiap tahun.

Tautan ke video 13: 20-13: 54

Kami menemukan sebagian besar bug selama interaksi beberapa komponen satu sama lain. Dalam video ini, salju dalam keadaan normal ditampilkan di kubus sebagaimana mestinya, tetapi segera setelah karakter mulai berinteraksi dengannya, salju mulai menghilang. Sebagian besar bug yang kami temukan ada di tempat-tempat di mana beberapa komponen bergabung.

Tautan ke video 14: 08-14: 41

Namun, bug tidak selalu terjadi ketika hanya ada dua kondisi. Seringkali bug muncul ketika beberapa komponen berkumpul sekaligus. Dalam hal ini, kami mempertimbangkan bug di mana, dalam situasi normal, karakternya hanya berdiri di tanah. Layak menambahkan tingkat kebebasan lain - untuk meningkatkan karakter di atas tanah: ketika dia jatuh, animasi mulai diputar dan kamera mendekati / bergerak menjauh - teksturnya mulai menghilang. Di sini, tiga komponen berinteraksi sekaligus: tinggi, animasi karakter, dan jarak kamera. Tidak mungkin untuk memikirkan semua opsi ini sebelumnya, dan seringkali kami menemukan bug seperti itu hanya selama pengujian sementara.

Tautan ke video 15: 02-15: 49

Ada fitur lain - kami memiliki banyak sistem non-deterministik. Ini adalah sistem di mana, dengan input yang sama, hasil akhirnya mungkin berbeda. Contoh sederhana adalah bahwa ada variabel acak dalam sistem. Dalam kasus kami, ini adalah sistem fisika di mana ada banyak perhitungan dengan angka floating point. Operasi floating point pada prosesor atau kompiler yang berbeda dapat dilakukan sedikit berbeda. Karena itu, fungsionalitas yang dihasilkan akan selalu sedikit berbeda. Akibatnya, sistem seperti itu cukup sulit untuk diotomatisasi, karena sulit untuk menjelaskan kepada mesin dalam hal ini bug, dan dalam hal ini perbedaan yang dapat diterima.

Tautan ke video 16: 03-17: 14

Ada beberapa interaksi non-sepele dalam mesin dan editor itu sendiri. Pengguna sering berinteraksi dalam ruang tiga dimensi menggunakan mouse dan keyboard. Video ini akan menampilkan fitur yang disebut objek Simulasi. Benda-benda yang dikenakan pada karakter harus bergerak sesuai dengan hukum fisika saat memindahkan karakter yang digunakannya. Misalnya pakaian atau tas kerja. Seperti elemen dalam video - tangan karakter. Ketika karakter bergerak, tangan juga mulai merespons. Seringkali, untuk menguji fungsionalitas tersebut, Anda perlu melakukan tindakan non-sepele: mengalihkan sesuatu di UI, memindahkan objek dalam ruang tiga dimensi, melakukan drag-and-drop, juga melihat grafik animasi yang terletak di bawah, dan melakukan semuanya secara real time. Fitur ini mempengaruhi kompleksitas otomatisasi.

Bagaimana cara menentukan cakupan?


Pada titik tertentu, kami menyadari bahwa kami menulis banyak kasus uji, tetapi sulit untuk menentukan cakupan apa yang kami miliki. Kami menemukan bug paling kritis tidak selama uji regresi penuh kami, tetapi selama pengujian ad-hoc, yang dilakukan pada akhir siklus rilis. Kami mulai berpikir: kami memiliki mesin dengan banyak fungsionalitas, kami memiliki repositori di mana 12.000 kasus - bagaimana memahami di tempat mana ada cakupan yang cukup dan di mana akan layak untuk menambahkan kasus uji?

Kami beralih ke teori pengujian, mulai membaca tentang bagaimana orang mendefinisikan cakupan pengujian. Salah satu caranya adalah menentukan melalui kode sumber. Dalam kasus kami, itu sulit dilakukan. Kami memiliki beberapa juta baris kode dan tidak mungkin menyelesaikan pemeriksaan ini dalam waktu singkat. Metode kedua adalah mengevaluasi cakupan melalui penilaian persyaratan. Dalam proses gesit, persyaratan sering disimpan hanya di kepala orang, dan tidak dalam dokumentasi, sehingga melalui persyaratan untuk membuat penilaian cakupan juga tidak realistis. Akibatnya, kami beralih ke satu-satunya cara yang mungkin bagi kami - definisi cakupan melalui penulisan model.



Kami memilih model yang disebut ACC - Atribut, Komponen, Kemampuan. ACC adalah salah satu model paling sederhana, yang cukup umum di Amazon untuk perangkat lunak pemodelan. Model ini dibangun di atas tiga pilar utama. Pertama, ini adalah komponen, kata benda adalah bagian kerja utama dari sistem. Bagi kami, ini viewport, tekstur, esensi game. Berikut ini adalah kapabilitas - kata kerja - apa yang dapat dilakukan komponen ini. Misalnya, mereka dapat ditampilkan di layar, menghitung sesuatu, memindahkan sesuatu, dan sebagainya. Dan bagian ketiga adalah atribut - kata sifat atau kata keterangan yang terkait dengan komponen dan kemampuan mereka. Atribut menggambarkan parameter kemampuan: cepat, keamanan, terukur, aman, dan sebagainya. Semua ini dapat direduksi menjadi tiga pertanyaan: siapa? apa yang dia lakukan? Dan bagaimana?

Kami akan menganalisis model ini dengan contoh kecil. Di bawah ini adalah demo sebagian kecil fungsi:

Tautan ke video 19: 59-21: 02

Viewport adalah bagian dari editor di mana level terlihat. Video menunjukkan bahwa dimungkinkan untuk memutar kamera, bergerak di sekitar level, dimungkinkan untuk menambahkan karakter dari konduktor lokal objek permainan. Anda dapat memindahkan karakter, atau membuat entitas game baru dengan mengklik kanan, Anda dapat memilih semua entitas saat ini di level dan memindahkan semuanya. Anda juga dapat menambahkan elemen geometris lain dan (seperti dalam semua editor tiga dimensi) tidak hanya mengubah posisinya di ruang angkasa, tetapi juga mengubah sudutnya dan mengubah ukurannya. Jendela bernama "Viewport" memiliki mode render yang berbeda. Misalnya, bayangan dimatikan, atau beberapa efek grafis dari pasca pemrosesan dimatikan. Anda dapat memasuki mode permainan untuk segera menguji perubahan yang baru saja dibuat.



Mari kita lihat model ACC itu sendiri. Kami dengan cepat menyadari bahwa model-model ini sangat nyaman untuk dilakukan menggunakan Mindmaps, dan kemudian menerjemahkannya ke dalam tablet atau langsung ke struktur di TestRail atau di repositori lain untuk kasus uji. Komponen utama itu sendiri terlihat dalam diagram di tengah - Viewport - dan lebih jauh dari atas cabang merah adalah fitur Viewport yang memungkinkan Anda untuk bergerak di sekitar level: Anda dapat memutar kamera, Anda dapat terbang menggunakan tombol "W", "A", "A", "S", "D".

Peluang kedua (cabang oranye) adalah membuat entitas game baik melalui Viewport atau melalui drag-n-drop dari game explorer.

Dan entitas game ketiga dapat dimanipulasi: mereka dapat dibedakan, lokasi mereka diubah, diputar, dan sebagainya. Cabang hijau di sebelah kiri adalah konfigurasi Viewport saat beralih mode render. Atribut disorot di cabang biru, yang menunjukkan bahwa Viewport juga harus memenuhi parameter kinerja tertentu. Jika melambat, maka akan sulit bagi pengembang untuk melakukan apa pun.

Seluruh struktur pohon kemudian ditransfer ke TestRail. Ketika kami mentransfer kasus uji dari sistem kami sebelumnya ke struktur baru, segera menjadi jelas di mana kasus uji hilang - di beberapa tempat folder kosong muncul.



Tautan ke video 23: 01-24: 10

Struktur ini tumbuh cukup cepat. Viewport sebenarnya mengacu pada editor, yang hanya bagian dari mesin. Dua bagian utama: editor itu sendiri dan mesin game itu sendiri. Di sebelah kanan dalam gambar di atas Anda dapat melihat beberapa komponen yang tidak terkait dengan pohon. Misalnya, sistem rendering atau skrip, animasi terpisah, karena mereka berhubungan langsung dengan editor dan mesin. Yaitu, sistem rendering akan bekerja dalam runtime pada perangkat akhir, tetapi dalam editor itu sendiri akan mungkin untuk mengubah beberapa parameter: waktu siang dan malam, materi pengeditan, sistem partikel.

Hasil dan Kesimpulan


Pemodelan ACC membantu menyoroti bidang-bidang di mana pasien yang diliput tes. Mengisi celah dalam cakupan, jumlah bug yang ditemukan setelah lulus regresi penuh kami berkurang sekitar 70%. Model ACC yang mudah dibangun juga telah terbukti menjadi sumber dokumentasi yang bagus. Orang-orang baru yang datang ke proyek mempelajari mereka dan dengan cepat bisa mendapatkan beberapa ide tentang mesin. Pembuatan / pemutakhiran model-model ACC termasuk erat dalam proses kami mengembangkan fitur-fitur baru.



Kami mulai mengotomatiskan mesin melalui otomatisasi antarmuka pengguna. Antarmuka editor ditulis di perpustakaan QT. Ini adalah perpustakaan untuk menulis UI lintas-platform untuk aplikasi desktop, yang dapat bekerja pada Mac dan Windows. Kami menggunakan alat yang disebut Squish from Froglogic, yang bekerja pada sistem yang serupa dengan WebDriver, disesuaikan dengan lingkungan desktop. Dalam alat ini, pendekatan yang mirip dengan Page Object (dari dunia WebDriver) digunakan, itu disebut berbeda - Arsitektur Elemen Komposit. Selektor dibuat pada komponen utama (seperti "jendela" atau "tombol") dan fungsi yang dapat dilakukan dengan elemen-elemen ini terdaftar. Misalnya, "klik kanan", "klik kiri", "simpan", "tutup", "keluar". Kemudian elemen-elemen ini digabungkan menjadi satu struktur,Anda dapat mengaksesnya di dalam skrip Anda, menggunakannya, mengambil tangkapan layar dan membandingkan.

Masalah dan Solusi


Masalah pertama adalah stabilitas. Kami menulis tes yang menguji logika bisnis melalui antarmuka pengguna - apa masalahnya? Ketika logika bisnis tidak berubah, tetapi antarmuka berubah - tes jatuh, Anda perlu mengunggah tangkapan layar baru.

Masalah selanjutnya adalah kurangnya fungsionalitas. Banyak kasus pengguna tidak hanya dalam menekan tombol, tetapi dalam interaksi dengan dunia tiga dimensi. Perpustakaan ini tidak mengizinkan ini, solusi baru diperlukan.

Masalah ketiga adalah kecepatan. Untuk tes UI apa pun, Anda perlu merender seluruh mesin secara penuh. Butuh waktu, mesin untuk pengujian ini harus cukup kuat.



Solusinya datang dalam bentuk perpustakaan Shiboken. Pustaka ini menyediakan binder dari kode C ++ dalam Python, yang memungkinkan untuk secara langsung memanggil fungsi yang disediakan oleh editor atau mesin tanpa merender editor UI. Sebuah analog dari dunia web - Otomatisasi tanpa kepala (sesuatu yang mirip dengan PhantomJS) - Anda dapat mengotomatiskan aplikasi web tanpa meluncurkan browser. Dalam hal ini, sistem yang serupa, hanya untuk aplikasi desktop yang ditulis dalam C ++.

Setelah mulai berinvestasi dalam kerangka kerja ini, kami menyadari bahwa itu dapat digunakan tidak hanya untuk mengotomatisasi pengujian, tetapi juga untuk mengotomatisasi proses apa pun di dalam mesin. Sebagai contoh, seorang desainer perlu meletakkan 100 sumber cahaya berturut-turut (misalnya, ia membuat jalan dan Anda perlu meletakkan lampu). Alih-alih mewakili secara manual semua sumber cahaya ini, Anda cukup menulis skrip yang membuat entitas permainan, menambahkan sumber cahaya titik di sana dan menetapkan bahwa setiap 10 meter Anda perlu menyalin cahaya lampu yang dibuat sebelumnya. Bonus untuk pengguna kami dalam bentuk alat untuk mengotomatisasi tugas-tugas rutin.



Bagian kedua dari solusi untuk masalah tersebut. Kami dengan cepat menyadari bahwa untuk mengotomatisasi berbagai bagian mesin kami - misalnya, gambar dan bagian jaringan - kami membutuhkan kerangka kerja yang sama sekali berbeda. Tidak mungkin untuk membuat kerangka tunggal, mengerikan yang akan membantu mengotomatiskan semuanya sekaligus. Oleh karena itu, kami mulai mengembangkan kerangka kerja yang disebut Alat Uji Lumberyard (singkatnya - LyTestTools). Ini didasarkan pada Pytest (cukup banyak hal ditulis dalam mesin dengan Python). Kami memutuskan untuk menggunakan apa yang disebut arsitektur Plug-and-play - kelompok pusat insinyur otomatisasi menulis bagian utama kerangka kerja, yang dapat mengunduh, mengonfigurasi mesin, menyebarkannya ke berbagai platform, menjalankan tes dan mengumpulkan log, mengunggah laporan ke database kami atau S3 dan menggambar grafis dalam Quicksight. Plug-and-play dicapai melalui Test Helper's,yang akan ditulis oleh tim di bidang yang mengembangkan fitur.

Yaitu, tim pengembang grafis akan menguji dengan tangkapan layar, dan tim interaksi jaringan akan memeriksa paket yang diteruskan. Pada saat yang sama, mereka semua akan terhubung ke kerangka kerja bersama kami (karena kedua tim mengembangkan dan menguji modul dari satu mesin) sehingga mereka semua memiliki antarmuka yang sama untuk menjalankan tes dan menghasilkan laporan, sehingga semuanya bekerja lebih atau kurang secara standar dan benar bekerja dengan CI kami. / Cd.

Interaksi dengan Lumberyard


Apa yang bisa menjadi cara interaksi / otomatisasi aplikasi desktop? Jenis interaksi pertama antara kerangka dan mesin - langsung dari Python, proses diluncurkan menggunakan fungsi Subprocess, jika aplikasi menyiratkan peluncuran melalui baris perintah. Anda dapat membaca input / output dari input / output output standar dan dengan demikian membuat pernyataan. Jenis selanjutnya - interaksi ini melalui analisis log - Anda dapat membaca dan menganalisis log yang ditinggalkan oleh aplikasi. Yang ketiga adalah melalui jaringan. Di peluncur gim, ada modul bernama Remote console. Ketika port tertentu terbuka pada perangkat, kerangka kerja kami dapat mengirim paket / perintah khusus. Misalnya, ambil tangkapan layar atau buka level tertentu. Metode lain adalah interaksi melalui perbandingan informasi visual, mis. tangkapan layar.Juga disebutkan sebelumnya adalah metode memanggil fungsionalitas aplikasi secara langsung melalui API produk (dalam kasus kami, ini adalah panggilan melalui pengikatan Python ke fungsi editor C ++ / fungsi mesin).

Mari kita beralih ke contoh penggunaan kerangka kerja kami untuk mengotomatisasi mesin.

Lihatlah screenshot ini.



Detail di situs ini cukup tinggi - sejumlah besar vegetasi. Dalam gim modern, level bisa memakan beberapa hingga ratusan kilometer gim. Tentu saja, masing-masing semak permainan ini tidak diletakkan secara manual, jika tidak para pengembang hanya akan menjadi gila. Bagi mereka, mesin kami memiliki alat khusus.

Salah satunya disebut Alat Vegetasi. Demo kecil:

Tautan ke video 32: 18-34: 06

Kami melihat awal standar level. Ada terrane dan Anda dapat dengan cepat membuat relief: di latar belakang buat gunung, di bagian tengah juga menyorot sebuah bukit kecil. Anda bisa mengecat tanah itu sendiri hijau dengan tekstur rumput. Proses penambahan vegetasi, dalam hal ini, pohon, diperagakan lebih lanjut. Geometri - pohon, ditambahkan ke alat - sebagiannya disorot, dan gambar apa pun yang diperlukan dapat digambar dengan pohon-pohon ini. Ini adalah contoh yang cukup sederhana, alat ini memiliki banyak parameter yang dapat disesuaikan. Misalnya, Anda dapat memilih bukan satu pohon, tetapi beberapa pohon sekaligus dan menetapkan parameter untuk mereka, berdiri pada jarak tertentu dari satu sama lain, atau mengatur parameter acak untuk ukuran atau rotasi pohon-pohon ini. Anda dapat menambahkan karakter game dan langsung berlari di level, tes,apa yang baru saja Anda tumbuh di taman bermain Anda sendiri.

Sekarang mari kita lihat bagaimana kita mengotomatisasi fitur ini dengan kerangka kerja kita menggunakan beberapa tes sebagai contoh.

Tautan ke video 34: 20-34: 58

Ada terran standar dan banyak jenis rumput yang sama ditanam di sana. Jenis rendering ini sangat intensif pada prosesor. Jika ada banyak elemen seperti itu, Anda dapat melakukan uji beban. Sebuah skrip permainan telah ditambahkan di sini, yang ketika memulai mode permainan hanya akan membuat penerbangan melalui level ini. Tugasnya adalah untuk menguji fungsi ini dan memverifikasi bahwa peluncur game stabil dan tidak akan crash.



Ini adalah contoh bagaimana tim yang mengembangkan fitur untuk menanam vegetasi menulis Test Helper, yang memungkinkan Anda bekerja dengan fitur-fitur ini. Ini adalah contoh penggunaan kerangka kerja kami. Kelas peluncur disorot dalam warna hijau. Ketika tes dimulai, peluncur dikerahkan, dimulai dengan parameter batas waktu, dan kami menegaskan untuk memverifikasi bahwa peluncur tidak mogok setelah beberapa saat. Lalu kita mematikannya.



Kode parameterisasi di atas menunjukkan bahwa kita dapat menggunakan kembali kode yang sama pada platform yang berbeda. Selain itu, kami dapat menggunakan kembali kode yang sama di berbagai level atau proyek. Misalnya, platform disorot dengan warna merah: dalam satu kasus itu adalah Windows, dalam kasus lain adalah Mac; proyek disorot dengan warna kuning; level nama disorot dalam warna kuning muda.

Tautan ke video 36: 07-36: 47

Sekarang tentang tes - dalam hal ini, jalankan melalui baris perintah. Sebuah program terbuka bernama Asset Processor, salah satu bagian utama dari mesin. Program ini memproses sumber aset (misalnya, model dan tekstur yang dibuat oleh seniman) ke dalam format yang dapat dimengerti untuk mesin dan menulis semuanya ke database (SQLite) sehingga mesin dapat dengan cepat menavigasi dan memuat data yang diperlukan selama permainan. Selanjutnya, peluncur dimulai, mode permainan dimulai, kamera terbang di atas level selama beberapa detik dan tes berakhir. Kami melihat bahwa satu tes berhasil dan dua tes dilewati. Ini terjadi karena selama perekaman video tes dikejar pada Windows, dan dalam parameterisasi ada dua platform yang masing-masing dilewati selama peluncuran ini.



Ada opsi yang lebih sulit. Kami tidak hanya meluncurkan peluncur dengan tingkat selesai, tetapi skrip berinteraksi langsung dengan editor. Biru menunjukkan nama skrip terpisah yang akan bekerja dengan editor dan menarik berbagai perintah melalui API.



Di atas adalah level tes. Dalam hal ini, senyum digambar di medan standar menggunakan tekstur yang sudah disiapkan sebelumnya (topeng). Perlu untuk memverifikasi bahwa ketika menggunakan topeng, lukisan hanya akan dilakukan di sepanjang kontur yang dipilih sebelumnya dan tidak akan melampaui itu.



Tim yang bekerja dengan dunia game menulis ekstensi untuk bekerja dengan terrane, yang kemudian dimasukkan ke dalam kerangka kerja kami. Sikat baru dibuat, yang akan menggambar pada topeng "Batu besar", sikat diatur ke merah dan lapisan yang dipilih dicat.



Dalam kelanjutan, sikat baru dibuat, intensitas yang berbeda diatur untuk itu. Topeng tidak lagi digunakan, dan dalam siklus, sudah di bagian lain dari level, elemen baru ditarik.

Mari kita lihat bagaimana skrip ini bekerja.

Tautan ke video 38: 42-39: 35

Pertama, Prosesor Aset akan dimulai, yang akan memeriksa status basis data aset dan memproses item yang baru ditambahkan jika perlu. Selanjutnya, editor dimulai. Level akan terbuka dengan senyuman, dan skrip akan mulai berjalan dengan editor. Dia melukis lapisan di atas topeng, lalu membuat lingkaran biru dan mulai mengambil tangkapan layar. Selanjutnya, tangkapan layar akan dibandingkan dengan yang referensi, dan, jika semuanya beres, tes akan selesai.

Tes ini mengambil tangkapan layar tersebut untuk dibandingkan dengan standar. Di sini Anda dapat melihat bahwa gambar berjalan dengan jelas di sepanjang perbatasan.

Seni grafis


Kami juga menggunakan kerangka kerja kami untuk menguji grafik.

Tautan ke video 40: 04-40: 56

Grafik - salah satu bagian mesin yang paling sulit, yang menghabiskan sebagian besar kode. Anda dapat dan harus memeriksa semuanya - dimulai dengan hal-hal sederhana, seperti geometri dan tekstur, dan fitur yang lebih kompleks - bayangan dinamis, pencahayaan, efek pasca-pemrosesan. Pada video di sudut kanan Anda dapat melihat pantulan di genangan air - semuanya bekerja secara real time di mesin kami. Saat kamera terbang di dalam, Anda dapat melihat elemen rendering yang lebih canggih, misalnya, silau, elemen transparan, seperti kaca, serta tampilan elemen seperti permukaan logam. Bagaimana fungsi ini diuji dengan tangkapan layar?



Ini karakter kita, Rin. Dengan itu, kami sering menguji jalur pipa artis. Artis membuat sesuatu di editor mereka (misalnya, karakter), dan kemudian menggambar tekstur di atasnya. Asset Processor memproses data asli untuk digunakan pada berbagai platform, dan mesin grafis akan menangani tampilan.



Tentunya Anda sering menemukan bug ketika "tekstur tidak dimuat." Bahkan, ada banyak masalah ketika terjadi sesuatu untuk menampilkan tekstur.



Namun semuanya tertangkap dengan baik dengan membandingkan tangkapan layar. Pada tangkapan layar pertama Anda dapat melihat bug - beberapa materi tidak dimuat dengan baik. Dalam tangkapan layar ini, tingkat yang sama di mana sepeda motor berada dan kamera terbang di dalam kafe, yang ditunjukkan dalam video sebelumnya. Mengapa semuanya terlihat sangat membosankan di sini? Karena tangkapan layar tidak diambil pada tahap rendering terakhir, ketika mesin grafis meletakkan semua efeknya, tetapi secara bertahap. Pada awalnya, hanya rendering geometri dan tekstur sederhana yang diambil: bayangan dihilangkan, elemen pencahayaan kompleks dihilangkan. Jika Anda menguji semuanya pada tahap terakhir dan melihat Diff Image, akan sulit untuk mengatakan apa yang sebenarnya rusak.



Jika Anda melakukan ini secara bertahap, Anda dapat secara kasar memahami bagian mesin grafis mana yang bermasalah. Berikut adalah algoritma yang digunakan untuk membandingkan tangkapan layar.



Dengan membandingkan tangkapan layar, Anda dapat menguji grafik, elemen tampilan, tekstur, bahan, shader.

Saya akan memberikan contoh satu bug dari versi lama dari mesin kami ketika kami tidak memiliki kerangka ini.

Tautan ke video 43: 10-43: 44

Ini terkait dengan sistem Vegetasi. Setelah menambahkan pohon, bagian grafik mulai menggambar bayangan di bawahnya. Hal ini diperlukan untuk menekan "Ctrl + Z" ("Batal"), pohon-pohon menghilang, dan bayangan tetap ada. Jika Anda mengambil tangkapan layar di awal, ketika pohon berdiri dan setelah mengklik "Batal", maka bug seperti itu mudah ditangkap dalam mode otomatis setelah membandingkan dengan tangkapan layar referensi dari Sebelum dan Setelah.

Dengan membandingkan tangkapan layar, pipa Aset juga diuji dengan sangat baik. Ketika para seniman menciptakan sesuatu dalam editor 3D (Maya, 3dsMax), Anda perlu memeriksa bahwa semuanya ditampilkan dalam permainan dengan cara yang sama dan tidak ada yang hilang: ayam memiliki bulu, semua hewan memiliki bulu, orang memiliki tekstur kulit yang benar dan hal-hal lain.

Tautan ke video 44: 16-44: 52

Di sisi kanan program adalah Asset Processor, yang memantau tampilan dalam permainan segala sesuatu yang dilukis artis. Dia akan memberi tahu kita bahwa semuanya beres dengan aset ini - mereka harus bekerja. Pada video Anda dapat melihat bahwa beberapa pohon menjadi hitam. Beberapa ditampilkan secara normal, dan beberapa tekstur hijau menghilang begitu saja. Secara alami, dalam formulir ini Anda tidak dapat melepaskan mesin atau aset.

Tidak semuanya bisa ditangkap


Tautan ke video 45: 03-45: 17

Beberapa jenis bug mulai terbentuk hanya ketika beberapa elemen berinteraksi satu sama lain. Dua model Rin ditampilkan secara normal jika mereka dilepas satu sama lain, tetapi jika Anda mendekatkannya, masalah dengan geometri dimulai. Sayangnya, bug seperti itu sulit ditangkap bahkan sebelum otomatisasi. Seringkali mereka dapat diperhatikan hanya ketika penguji mulai melakukan sesuatu dalam mode pengujian eksplorasi atau ketika mesin sudah jatuh ke tangan pelanggan.



Dengan membandingkan tangkapan layar, Anda dapat menguji antarmuka editor itu sendiri.

Komponen gim




Juga, tangkapan layar dapat menguji beberapa komponen gim sederhana. Contohnya adalah tingkat sederhana di mana ada pintu dan skrip yang, ketika Anda menekan bilah spasi, memulai pintu untuk membuka dan menutup.

Anda dapat mengambil tangkapan layar di awal dan di akhir. Jika semuanya cocok, maka skrip yang mengubah lokasi elemen berfungsi dengan benar.

MELENGKUNG


Kami dengan cepat menyadari bahwa tangkapan layar dengan fungsi yang sama sangat berbeda pada platform yang berbeda, dalam beberapa kasus mungkin ada perbedaan pada platform yang sama tergantung pada jenis kartu video. Bagaimana menghadapi ini, agar tidak menyimpan 100500 tangkapan layar? Ada alat, Windows Advanced Rasterization Platform adalah renderer perangkat lunak yang memungkinkan Anda untuk melakukan semua gambar tanpa menggunakan driver dan kartu video. Dengan menggunakan alat ini, Anda dapat menjalankan sebagian besar tes grafis fungsional tanpa bergantung pada driver dan perangkat keras.

Performa


Last but not least, mesin game harus produktif! GPU dapat diuji menggunakan berbagai profiler grafis, seperti PIX. RAM dapat diuji dalam Visual Studio itu sendiri. Selanjutnya, lebih lanjut tentang bagaimana kinerja prosesor diuji menggunakan alat RADTelemetry.

Tahu apa Input Lag?

Tautan ke video 47: 29-48: 21

Input Lag - ini adalah penundaan antara menekan tombol controller / keyboard oleh pemain dan saat ketika game mulai merespons penekanan. Input Lag terjadi karena transmisi data melalui jaringan, ketika paket pergi untuk waktu yang lama atau server merespons untuk waktu yang lama, serta dalam mesin dan tanpa menggunakan jaringan. Ketika seseorang mengacaukan dalam kode yang bertanggung jawab untuk animasi, lag Input dapat menjadi sangat tinggi sehingga karakter mulai merespons terlambat. Dalam perkiraan sederhana, ini diuji dengan cukup mudah: keyboard virtual dibuka dan video direkam, di mana saat Anda menekan tombol spasi dan saat animasi dimulai.

Kami melihat berapa banyak frame per detik yang diberikan engine. Anda dapat menghitung berapa banyak setiap frame dalam milidetik (1000 / FPS). Jika Anda memainkan video frame-by-frame, Anda dapat menghitung berapa banyak frame yang telah berlalu sejak klik sebelum karakter mulai bergerak. Mengetahui berapa milidetik yang ditempati setiap frame, dapat dihitung bahwa, misalnya, 200 milidetik dilewati antara menekan spasi dan awal animasi. Dengan respons manusia standar 100 milidetik, ini terlalu lambat dan gamer akan segera mengatakan bahwa penundaan seperti itu tidak ada gunanya. Metode pengujian ini memiliki masalah. Pertama, akan ada kesalahan. Misalnya, keyboard virtual akan mengalami penundaan. Kedua, dalam permainan, artis sering membuat animasi sehingga karakter tidak segera mulai membuat gerakan utama. Ada yang disebut antisipasi: sebelum aksi utama,misalnya, dengan melompat, karakter pertama membungkuk sedikit dan baru kemudian mulai melompat. Ini bisa memakan beberapa bingkai. Bagaimana kami melawan ini? Kami mulai menguji bagian ini dengan pendekatan yang lebih akurat.

Ada sebuah program yang disebut RADTelemetry.

Tautan ke video 49: 44-50: 47

Ini memungkinkan Anda membuat profil prosesor. Bingkai vertikal diletakkan di sini: No. 629, 630 - Anda dapat melihat berapa banyak waktu yang dibutuhkan setiap frame. Baik inti prosesor atau utas eksekusi aplikasi di-PHK jika aplikasi multi-utas. Jika Anda mengklik salah satu utas, nama semua fungsi yang ada di utas ini saat diluncurkan, berapa lama waktu yang diperlukan untuk mengeksekusi dari total, berapa kali dieksekusi, akan ditampilkan di sebelah kiri. Dengan menggunakan aplikasi ini, Anda dapat secara akurat memahami berapa banyak waktu yang telah berlalu sejak saat gim mendaftarkan keystroke sebelum meluncurkan fungsi Play Animation. Program ini dapat menempatkan log-nya ke file teks, dan kemudian menggunakannya Anda dapat menggambar grafik kinerja yang berguna dari berbagai build dalam distribusi waktu.

Dan di mana AWS di sini?


Sebagai kesimpulan, beberapa kata tentang AWS. Di satu sisi, kami menggunakannya untuk menggerakkan tes kami. Kami menjalankan tes pada EC2 dan pada perangkat dari Device Farm. Hasil ditambahkan ke database dalam S3, dan grafik ditampilkan di Quicksight. Statistik pengujian dapat dilihat di CloudWatch. Karena engine sangat terintegrasi dengan layanan AWS, kami menguji integrasi ini juga - baik secara manual maupun otomatis. Misalnya, CloudCanvas adalah layanan yang memungkinkan Anda membuat fungsionalitas untuk permainan jaringan tanpa pemrograman, yaitu di server Anda dapat dengan mudah mengkonfigurasi chip seperti Papan Skor, tabel skor, dan pencapaian. Untuk hal-hal seperti monetisasi game, Anda tidak dapat mencari programmer server Anda, tetapi segera mulai menggunakan CloudCanvas. Amazon GameLift pada dasarnya adalah sistem yang dapat diskalakan untuk server game.Integrasi dengan Twitch - ketika pengguna menonton siaran dua pemain yang bersaing di antara mereka sendiri. Jajak pendapat Twitch dibuat "Pemain mana yang Anda dukung?" - orang mulai memberikan suara dalam obrolan, permainan membaca jawaban, dan salah satu pemain (seperti di Hunger Games) dapat kehilangan bonus tambahan atau mencegahnya.

Ringkasan


Hal pertama yang kami sadari adalah bahwa dalam proyek besar seperti itu tidak ada satu peluru perak yang dengannya Anda dapat mengotomatisasi segalanya. Dalam kasus kami, kerangka kerja Plug-and-play bekerja dengan baik. Kami menulis kerangka kerja umum dan memungkinkan seluruh tim untuk dengan mudah menanamkan solusi mereka. Dengan menggunakan contoh tangkapan layar dan perbandingan vegetasi, sistem menunjukkan bagaimana kerangka kerja ini bekerja. Saya berharap bahwa beberapa aplikasi dan solusi industri (seperti Pengurai Perangkat Lunak Microsoft atau RADTelemetri). Disediakan dalam artikel ini akan berguna untuk melatih insinyur yang bekerja dalam permainan atau sistem CAD.

Kesimpulannya, tautan ke semua alat yang ditunjukkan dalam laporan:



Saya berharap bahwa saya berhasil memberi tahu bagaimana pengujian mesin berbeda dari pengujian game. Baru-baru ini, prosesnya telah melangkah jauh ke depan - pengujian mesin game sama sekali tidak sederhana, tetapi sangat menarik.

Jika topik permainan pengujian menarik perhatian Anda, kami sarankan Anda melihat laporan lain:

More articles:


All Articles