STL untuk game, ya atau tidak? [Tutup]

Setiap bahasa pemrograman memiliki pustaka standar tentang wadah, algoritme, dan hal-hal bermanfaat lainnya. Dengan bahasa seperti C #, Java, dan Python, praktis tidak terbayangkan untuk menggunakan bahasa tanpa lib standar.

Namun, pada banyak game C ++ yang telah saya kerjakan, kami tidak menggunakan STL sama sekali, menggunakan sebagian kecil darinya, atau menggunakan implementasi kami sendiri. Sulit untuk mengatakan apakah itu keputusan yang tepat untuk game kami, atau hanya karena ketidaktahuan STL.

Jadi ... apakah STL cocok atau tidak?

Kembali ketika saya bekerja dalam pengembangan game profesional, STL terlalu tidak matang dan kembung. Tapi itu> 10 tahun yang lalu.

Sekarang saya bekerja dalam simulasi militer, yang bahkan memiliki persyaratan kinerja yang lebih keras (seperti framerate tidak pernah bisa di bawah beberapa FPS). Dalam simulasi militer, STL digunakan di semua tempat.

Beberapa orang yang mengatakan kepada Anda untuk tidak menggunakan STL menggunakan argumen bahwa itu tidak selalu merupakan solusi sempurna atau bahkan terbaik untuk masalah tersebut. Tapi itu bukan jawaban untuk pertanyaan itu. Pertanyaannya seharusnya: Apakah ada sesuatu yang salah dengan menggunakan STL dalam game? Saya akan mengatakan tidak, STL sebagian besar waktu implementasi yang lebih baik daripada apa yang pengguna akan buat sendiri.

Pastikan Anda tahu cara menggunakan STL, dan gunakan di gim Anda. Baca beberapa buku dan lihat kode implementasi di STL yang Anda gunakan.

Saya akan mengatakan bahwa, dari atas kepala saya, itu adalah ide yang lebih baik untuk menggunakan STL kecuali Anda tahu persis mengapa Anda tidak ingin menggunakannya.

Inilah hal tentang STL: ini dikembangkan oleh orang-orang yang lebih pintar dari Anda. Itu tidak dimaksudkan untuk menyinggung atau apa pun, hanya saja STL dikembangkan oleh orang-orang yang pekerjaannya benar-benar membangun STL. Ini akan menjadi hampir secepat yang dimungkinkan oleh platform dan umumnya akan jauh lebih kuat daripada solusi rumahan (dan ini harus menjadi perhatian jika tidak lebih dari mengkhawatirkan kecepatan mentah - karena permainan Anda membutuhkan ketahanan sedikit lebih baik daripada yang Anda butuhkan kecepatan; yang terakhir tidak ada artinya tanpa yang pertama).

Keluhan bahwa STL menegakkan "pandangan sempit tentang dunia" menurut saya agak konyol. Mereka wadah. Mereka memiliki rangkaian operasi terbatas karena kontainer memiliki rangkaian operasi terbatas. Apa yang kamu lakukan yang tidak sesuai dengan ini?

Saya telah melihat sangat sedikit alasan untuk tidak menggunakan STL untuk game.

Untuk masalah alokasi memori, banyak orang tidak mengetahui hal ini tetapi Anda dapat menulis pengalokasi khusus untuk kelas wadah STL Anda. Allocator pada dasarnya adalah kelas kebijakan yang Anda berikan ke templat untuk menentukan bagaimana alokasi dilakukan. Dengan menggunakan ini, Anda biasanya dapat mengatasi masalah memori apa pun yang bermasalah pada platform pilihan Anda.

Tentu saja, jika Anda menggunakan STL dan melakukan hal-hal bodoh seperti peta string ke tipe non-pointer besar, maka Anda memiliki masalah yang lebih besar di tangan Anda.

STL default memiliki sejumlah masalah yang membuatnya sulit untuk digunakan dengan game, terutama ketika menyangkut penyelarasan memori.

Varian khusus seperti EA STL dirancang khusus untuk permainan dan dapat membuat Anda mendapatkan kinerja memori yang lebih baik dan kegunaan konsol. Itu menjadi open source pada tahun 2016, di bawah klausa BSD-3, dengan repositori di GitHub .

Inilah yang dikatakan Mike Acton (Direktur Mesin Insomniac Games dari Spyro the Dragon, Ratchet & Clank, dan Resistance) tentang hal ini ketika ditanya di sini . Perhatikan bahwa ia ditanya tentang STL dan Boost secara umum terkait dengan penggunaan di game dev.

STL / Boost, apakah itu termasuk dalam gamedev? Kalau hanya sebagian saja, yang mana?

Anda bertanya tentang dua hal berbeda di sini, bukan? STL dan Boost, secara terpisah. Tapi sungguh, jawaban saya sama: Tidak ada yang salah dengan keduanya, tapi saya tidak menganjurkan penggunaannya. Penggunaan salah satu mendorong orang untuk mencocokkan solusi untuk suatu masalah daripada menemukan solusi untuk suatu masalah. Solusinya harus selalu sesuai untuk data yang ada dan kendala perangkat keras, dll. Baik STL dan Boost memiliki pandangan yang sangat sempit tentang "dunia" dan penggunaannya yang tepat terbatas. Sungguh, saya mengecilkan hati mereka karena mereka langsung mengarahkan programmer ke arah yang salah, saya sering mengatakan jika Anda merasa Anda membutuhkan salah satu dari mereka, Anda mungkin tidak benar-benar memahami masalah yang Anda alami.

Saya juga memperhatikan bahwa sebagian besar pengembang game pro berusaha lebih keras ke arah C daripada C ++.

Jika Anda menemukan diri Anda menulis ulang sesuatu yang sudah ada di STL, untuk alasan apa pun, berhenti . Gunakan STL.

STL telah dioptimalkan selama bertahun-tahun analisis dan waktu, dan ini adalah taruhan yang aman Anda mungkin tidak akan menulis sesuatu yang lebih efisien. Itu bukan untuk mengatakan Anda harus menggunakan STL di mana solusi yang lebih sederhana mungkin (yaitu menggunakan array ketika Anda memiliki jumlah hal yang diketahui, bukan stl :: daftar), tetapi jika Anda menulis implementasi peta Anda sendiri ( struktur data dasar, bukan peta dunia game), Anda salah melakukannya.

Apakah STL cocok untuk gim? Pastinya. Game adalah perangkat lunak yang kompleks, STL menyediakan fitur yang membantu mengelola kompleksitas, jadi itu bagus.

Apakah ini cocok untuk platform Anda? Belum tentu. Jika Anda menulis untuk konsol, maka Anda harus sangat berhati-hati tentang penggunaan memori dan cache. STL tidak membuat ini sangat mudah.

Saya pikir bahwa terlalu sering kita keliru "game" untuk "game real-time berkinerja tinggi yang berjalan pada perangkat keras tertanam atau dipesan lebih dahulu", tetapi penting untuk membuat perbedaan. Jika Anda menulis gim Windows yang tidak mencoba berjalan dalam layar penuh dengan 60fps konstan, maka tidak ada alasan untuk menghindari alat yang diberikan pustaka standar kepada Anda.

Saya tahu ini sangat terlambat untuk pesta, tetapi waktu berubah dan jawaban tetap ada. C ++ 11 memiliki perubahan besar, banyak di antaranya adalah untuk meningkatkan kinerja C ++ dan pustaka standar. Tampaknya mereka yang tidak menggunakan STL atau Boost, cenderung tidak mengikuti standar baru juga, meninggalkan solusi home spun yang tidak memiliki peningkatan penting, tentu saja hal ini tidak selalu terjadi.

Saya telah menggunakan STL pada setiap proyek dari pertengahan 90-an hingga hari ini, dengan pengecualian waktu yang singkat di EA. Saya pikir sisi anti STL memiliki beberapa alasan yang sedikit rasional untuk tidak menggunakannya. Sebagian besar sudah hilang. Alokasi kustom adalah salah satu solusi, menggunakan cadangan adalah solusi lain, dan tidak melewatkan nilai berdasarkan nilai adalah solusi ketiga, tetapi ini cukup sederhana dan setiap programmer harus mengetahuinya. Lebih penting lagi adalah penggunaan algoritma. Penulis kompiler tahu persis apa yang for_each () lakukan dan dapat mengoptimalkan kode. Itu tidak dapat terjadi dengan loop digulung rumah. for_each () pada objek const bahkan lebih baik. Microsoft mengoptimalkan for_each dalam banyak cara termasuk membuat serial. Mereka juga memiliki perpustakaan AMP yang memiliki parallel_for_each (). Jika Anda mendapat kesempatan, bicarakan dengan insinyur penyusun tentang ini. Kompiler konsol akan mengoptimalkan apa yang akan digunakan, jadi sa sedikit masalah ayam dan telur. Microsoft akan sangat berat dengan C ++ 11 dan XBox berikutnya tidak akan berbeda. Saya tidak tahu tentang PS4, kami belum mendapatkannya.

Alokasi kustom adalah salah satu cara untuk menangani masalah memori, tetapi opsi lain (yang sering diabaikan) adalah menggunakan kelas baru dan menghapus. Peningkatan kinerja besar bisa didapat dengan cara ini.

Gagasan bahwa Boost dan STL memiliki pandangan sempit dalam memecahkan masalah adalah kegilaan murni. Saya kagum pada berapa banyak hal dalam STL dan Boost yang dapat disesuaikan melalui sifat dan kebijakan. Cari perbandingan independent case case sebagai contoh.

Mengenai waktu tautan yang lama dan kode mengasapi, templat eksternal yang baru akan membantu dalam hal ini. Secara umum saya menemukan waktu kompilasi yang panjang berasal dari kopling berlebih dan penyalahgunaan pch.

Alasan paling kuat untuk menggunakan STL di atas tenunan sendiri adalah ada jutaan orang yang dapat membantu Anda dengan STL. Seperti biasa, jangan optimalkan secara prematur dan uji, uji, uji.

Ini adalah topik hangat dalam pengembangan game. Saya pribadi tidak merekomendasikannya, kecuali mungkin untuk EASTL sebagaimana disebutkan di atas. Saya memiliki dua masalah utama dengan STL (secara teknis "The C ++ Standard Library", karena STL tidak lagi namanya) dalam permainan. 1) Alokasi memori dinamis sering membuang banyak runtime dalam gim ketika STL digunakan. 2) Penggunaan STL mendorong pendekatan array-of-struct untuk arsitektur game, sedangkan pendekatan struct-of-array jauh lebih ramah terhadap cache.

Tergantung. Seberapa besar proyek, platform apa, dan apa jadwal waktunya?

Jika Anda bekerja pada proyek besar, pada platform dengan sumber daya terbatas, dengan timeline dan anggaran yang signifikan, maka Anda dapat menyelamatkan diri sendiri dari banyak masalah dengan menghindari neraka yang tak terhindarkan yang akan mencari setengah juta basis kode baris yang berserakan dengan STL, tidak bisa menyimpan framerate di atas 30, makan cukup RAM agar sesuai dengan beberapa aset lebih, dan membutuhkan 2 jam untuk membangun.

Namun dalam situasi lain, STL dan bahkan Boost bisa sangat berguna ketika diterapkan dengan tepat. Saya telah mengerjakan judul yang menggunakan pilihan STL / Boost, dan merupakan impian mutlak untuk kode: lebih sedikit bug / kebocoran dan mudah mempertahankan kode berarti lebih banyak waktu mengkodekan fitur baru yang menyenangkan! Khusus untuk proyek hobi, itu adalah kemenangan besar di departemen motivasi.

Ketahui kapan harus berdagang kinerja untuk kenyamanan!

IMHO saya akan mengatakan itu cocok karena STL sudah bekerja dengan baik dan dioptimalkan untuk tugas-tugas yang dibuat untuknya. Selain itu, Anda sedang mengerjakan game, jadi, gunakan alat yang Anda miliki yang membuat hidup Anda lebih mudah dan kode Anda kurang rentan terhadap bug.

Mengapa repot-repot menciptakan kembali roda ketika Anda bisa mengerjakan sesuatu yang lain seperti AI game, pengalaman pengguna, atau lebih baik lagi; pengujian dan debugging?

STL benar-benar baik untuk digunakan dalam game, selama Anda memahaminya dengan baik. Mesin kami memanfaatkannya secara luas dan itu tidak pernah menjadi masalah. Saya tidak punya pengalaman dengan pengembangan konsol, yang mungkin cerita yang sama sekali berbeda, tetapi didukung dengan baik pada semua platform PC (Windows / Mac / Linux).

Yang paling penting adalah memahami apa kelebihan dan kekurangan dari masing-masing jenis wadah dan pilih wadah yang tepat untuk pekerjaan yang Anda lakukan.

Mantan majikan saya bergeser dari menggunakan seperangkat kelas peti kemas khusus ke STL. Waktu build naik dan kemudahan debugging turun, keduanya cukup signifikan. Jika kita mulai dari awal, STL (mungkin lebih baik digunakan) mungkin akan masuk akal, tetapi tidak pernah jelas bagi saya bahwa kita memperoleh apa pun dalam beralih ke STL yang akan membenarkan membuang kode yang berfungsi, cepat, dan dapat di-debuggable.

Untuk proyek pribadi saya, apakah STL cocok atau tidak tergantung pada proyek. Jika saya mencoba melakukan pekerjaan yang dioptimalkan oleh data Mike Acton, memori-dan-cache-dioptimalkan, setidaknya saya akan berpikir tentang menggulung struktur data kustom saya sendiri. Jika saya membuat prototip beberapa algoritma atau gameplay dan tidak peduli dengan kinerja, skalabilitas, platform target, dll. Saya akan secara otomatis meraih STL.

2 sen saya pada ini adalah bahwa STL berfungsi dengan baik. Saya telah mengembangkan mesin game 3D (bukan kualitas AAA, tetapi cukup canggih - tipe entitas yang ditulis, penyaji tangguhan, fisika Bullet terintegrasi) untuk PC dan saya belum melihat kontainer menjadi hambatan utama. Penggunaan API 3D yang salah dan algoritme yang buruk telah menjadi target terbaik (ditentukan oleh profiling!) Setiap kali saya masuk dan mencoba menghasilkan kinerja yang sedikit lebih tinggi.

Saya telah membuat game menggunakan STL dan saya menyukainya, dan sepertinya kinerjanya bagus.

Pertanyaan bagus! Pertanyaan yang lebih spesifik adalah apa saja persyaratan umum yang dimiliki sebuah game yang tidak dapat dipenuhi dengan STL dan Boost.

Dalam pengalaman saya, keterbatasan memori perangkat keras konsol yang ketat membuat segala jenis wadah berukuran dinamis menjadi ide buruk terlepas dari seberapa pintar pengalokasi kustom Anda. Kontainer yang tidak memiliki batasan yang disengaja mendorong programmer untuk menulis kode yang tidak membatasi batasan dari kumpulan data mereka. Bergantung pada variabel yang tak terhitung jumlahnya yang sulit dilacak, Anda mungkin melebihi batasan memori Anda. Saya punya firasat bahwa ini adalah salah satu penyebab utama ketidakstabilan dalam game modern.

Selain itu, terlalu sering menggunakan template dapat menyebabkan waktu kompilasi yang sangat lama dalam basis kode besar, dan akan menggembungkan ukuran executable Anda sehingga tidak lagi sesuai dengan cache, katakanlah, inti tambahan pada ps3.

Namun, untuk pengembangan PC saja saya pikir STL dan Boost sangat bagus. Sementara solusi kasus umum tidak selalu ideal, mereka seringkali cukup baik. Solusi pertama Anda untuk suatu masalah hampir tidak pernah ideal, dan Anda memperbaiki atau mengganti kekurangan sampai cukup baik.

STL cocok untuk gim Anda jika STL cocok untuk gim Anda.

Seperti dengan semua pilihan teknologi yang dibuat selama pengembangan, Anda perlu mempertimbangkan pro dan kontra - akankah perpustakaan saya sendiri memberi saya penggunaan memori, kinerja, dan produktivitas yang lebih menguntungkan daripada hanya menggunakan STL? Mungkin; meskipun mudah untuk membuat vectorimplementasi yang menggunakan lebih banyak memori, lebih lambat, dan membutuhkan sejumlah besar perawatan untuk tetap berfungsi dibandingkan dengan apa yang sudah ada.

Orang tidak boleh menghindari menggunakan STL dalam game mereka karena orang lain menghindari menggunakan STL dalam game; mereka harus menghindari menggunakannya jika mereka telah menimbang semua pilihan mereka dan mereka benar - benar percaya bahwa implementasi lain akan meningkatkan kualitas produk mereka.

Seperti kebanyakan pertanyaan, jawabannya tidak pernah "ya atau tidak", hitam atau putih. STL cocok untuk beberapa masalah, menggunakannya untuk masalah-masalah itu harus baik-baik saja. Adalah kesalahan untuk menganggap itu tidak berguna, namun itu juga merupakan kesalahan untuk menganggap bahwa itu layak untuk digunakan dalam setiap situasi.

Masalah terbesar yang harus diperhatikan ketika menggunakan STL dalam pengembangan game adalah alokasi memori. Alokasi default STL tampaknya tidak cocok dengan strategi alokasi yang disukai untuk pengembangan game. Tentu saja pengalokasi khusus dapat digunakan, tetapi ini membuat keseluruhan gagasan kurang menarik jika Anda mempertimbangkan apakah akan menambahkan STL ke basis kode non-STL.

Tambahkan ke ini bahwa jika basis kode Anda adalah non-STL, Anda mungkin tidak memiliki orang yang cukup akrab dengan konsep STL atau templat untuk mengimplementasikan pengalokasi kustom dengan benar.

Saya pikir diskusi ini dapat diringkas sebagai berikut:

kode aplikasi-specfic yang ditulis dengan biasa-biasa saja <kode tujuan umum yang ditulis dengan baik <kode aplikasi khusus yang ditulis dengan baik

Siapa pun yang memiliki solusi buatan sendiri akan masuk dalam kategori 3 pasti tahu jawaban atas pertanyaan awal untuk masalah khusus mereka. STL masuk dalam kategori 2. Jadi bagi seseorang yang perlu mengajukan pertanyaan, "haruskah saya menggunakan STL", jawabannya mungkin ya.

STL baik-baik saja untuk digunakan pada PC, karena sistem memori virtualnya yang canggih membuat kebutuhan untuk alokasi memori yang hati-hati sedikit kurang penting (walaupun kita masih harus sangat berhati-hati). Pada konsol, dengan fasilitas memori virtual terbatas atau tidak ada dan biaya kesalahan cache terlalu tinggi, Anda mungkin lebih baik menulis struktur data khusus yang memiliki pola alokasi memori yang dapat diprediksi dan / atau terbatas. (Dan Anda tentu tidak akan melakukan kesalahan yang sama pada proyek game PC baik.)

Saya pikir pertanyaan ini benar-benar sebuah pertanyaan yang tidak diminta yang lebih besar - haruskah saya menggunakan X di Y saya ? Dan satu-satunya cara untuk benar-benar menjawabnya adalah dengan mencobanya sendiri. Untuk setiap orang yang Anda temukan mengatakan bahwa X bekerja dengan baik, Anda akan menemukan seseorang yang mengatakan itu mengerikan. Dan keduanya benar - untuk proyek mereka.

Hal yang hebat tentang perangkat lunak, tidak seperti kebanyakan disiplin ilmu lain, adalah bahwa Anda selalu dapat mengubah hal-hal di kemudian hari jika Anda menemukan itu tidak berfungsi seperti yang Anda inginkan. Anda mengetahui kemudian bahwa STL tidak bekerja untuk Anda dalam proyek ini? Cabut, letakkan sesuatu yang lain di tempatnya. Tidak suka bagaimana Anda membagi tugas di antara benda-benda Anda? Refactor. Tidak suka bahwa Anda menggunakan benda? Ganti dengan metode C langsung. Tidak suka semua disimpan di struct dan metode untuk memanipulasi mereka? Ganti dengan objek C ++.

Saya katakan tidak kepada STL. Alasan saya cukup sederhana:

1. Anda tidak perlu STL untuk menulis game. Bahkan tidak besar.
2. STL secara dramatis meningkatkan waktu kompilasi Anda.
3. Waktu kompilasi yang besar menyebabkan lebih sedikit iterasi pada pengembangan Anda.

Saya menganggap iterasi dianggap paling penting, jadi saya tinggal jauh dari STL, dan teknik pengembangan lainnya yang memperlambat iterasi (seperti mendesain untuk itu, atau bahasa skrip yang perlu dikompilasi).

Iterasi yang mahal menyebabkan tim pengembangan besar orang berusaha menyelesaikan sesuatu dengan sangat sedikit yang sebenarnya terjadi. Saya telah melihatnya dan mendengarnya, dan salah satu penyebabnya tampaknya adalah waktu kompilasi untuk pustaka templat.