STL untuk game, ya atau tidak? [Tutup]


144

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?



1
Yup, itu yang saya maksudkan dengan "menggunakan implementasi kita sendiri". :)
munificent

3
Jika Anda memiliki kesempatan untuk mencari dan membeli Permata Pemrograman Game Terbaik, lakukanlah. Ada judul artikel "Menggunakan STL dalam Pemrograman Game" oleh James Boer, ArenaNet, di mana ia membuat kasus yang sangat baik dalam menggunakan STL.
chiguire

Sebenarnya menggunakan Java tanpa lib standarnya cukup masuk akal, itu disebut J2ME: p
Bart van Heukelom

1
Pertanyaan bagus!
Alan

Jawaban:


191

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.


49
Ini saran yang cukup solid. Meme "STL lambat" belum benar setidaknya untuk lima tahun dan mungkin jauh lebih lama. Ini akan terus hidup, seperti omong kosong "Java is slow" dan ".NET is slow", hingga menjadi jelas bagi semua orang bahwa itu tidak lagi menjadi masalah. STL membantu Anda menulis program yang lebih baik; Saya akan mengatakan bahwa tidak menggunakannya, dalam banyak kasus (selain dari 0,1% di suatu tempat), tidak bertanggung jawab. (Klaim bahwa itu tidak sesuai dengan domain masalah yang diberikan seringkali lebih merupakan dakwaan dari cara masalah itu ditangani, bukan STL itu sendiri. Perbaiki kode Anda , teman-teman.)
Ed Ropple

5
@ Ed Ropple: Saya pikir masalahnya bukan karena STL tidak cocok dengan masalah yang diberikan, masalahnya adalah terlalu banyak masalah yang membuat kode di dalamnya terlalu rumit. Menakutkan bagaimana orang menggunakan STL secara berlebihan dan saya pikir itu adalah salah satu penyebab mengapa begitu banyak (termasuk saya) tidak menggunakannya sama sekali. Seperti satu contoh yang saya lihat belum lama ini di mana pertanyaannya adalah bagaimana mendapatkan yang terbesar dari 3 angka, salah satu jawabannya adalah mendorong mereka ke dalam std :: vector dan kemudian std: sortir. Itu pasti memaksa solusi yang tidak perlu ke masalah yang sangat sederhana.
Simon

22
@Simon: dengan segala hormat, contoh terakhir adalah tanda ketidaktahuan ekstrim, dan tidak ada hubungannya dengan STL ... orang itu akan melakukan hal yang sama dalam bahasa lain dengan daftar yang dapat diurutkan. Pemikirannya yang rusak.
ggambett

@EdRopple mencoba menerapkan parser STL untuk file gambar PPM (total kurang dari 100 baris kode jika hanya menargetkan P6 atau P3). Setengah dari kode yang dihasilkan hanya untuk melewatkan baris komentar karena STL tidak menyediakan sesuatu sepertiif(stream.nextCharacter() == '#') stream.skipLine();
GameDeveloper

@DarioOO Saya tidak tahu format file itu, tapi untuk itulah stream adapter dan filter digunakan. Saya menulis komentar itu lima tahun yang lalu, mind (dan kadang-kadang terus datang kembali!), Tetapi hari ini saya menulis tentang apa pun yang tidak super, super perf-kritis dalam gaya fungsional, berbasis transformasi dan masalah seperti yang Anda sedang menggambarkan jatuh keluar dari masalah. Saya tidak benar-benar peduli semua yang banyak tentang jumlah baris (dan IMO juga tidak boleh Anda), saya peduli kebenaran pelaksanaan, maka kejelasan, maka kinerja, dan kemudian hal-hal seperti panjang kode.
Ed Ropple

63

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?


4
Saya tidak berpikir siapa pun harus membenarkan mengapa mereka tidak harus menggunakan STL. Juga jangan setuju dengan argumen keseluruhan 'gunakan karena mereka lebih pintar dari Anda'. STL telah dirancang di sekitar pandangan spesifik dari domain masalah, bukan hanya wadah yaitu algoritma, pengalokasi, iterator, sifat dll. Itu cukup adil tetapi itu bukan satu-satunya cara untuk melihat domain masalah itu
zebrabox

2
Jadi, Anda lebih suka kode yang digulirkan di rumah daripada kode yang umumnya diuji, sangat kuat? Domain masalahnya tidak jauh berbeda dari proyek ke proyek (selain dari proyek yang mungkin tertanam - bahkan konsol memiliki implementasi STL yang layak hari ini!). Terlepas dari permainan, masalah Anda tidak jauh berbeda, dan jika Anda membuat sesuatu yang ingin Anda kirim, Anda memiliki tanggung jawab implisit untuk menulis kode yang kuat. Apakah menerapkan kembali roda akan menghasilkan ketahanan dan fleksibilitas yang lebih baik ? Saya condong ke arah "tidak". Bahwa itu bukan "satu-satunya cara" tidak menyiratkan itu umumnya tidak unggul.
Ed Ropple

20
Saya akan mengatakan bahwa gamedev adalah tentang membuat game , tetapi OK. Jika asumsi Anda sangat buruk sehingga Anda dibor pada alokasi sumber daya semacam itu, maka, ya, Anda perlu mundur dan mengevaluasi kembali. Tetapi Anda dapat membuat aplikasi sangat cepat yang menggunakan STL juga - dan, tentu saja, implementasi lainnya - ketika Anda benar-benar tahu apa yang Anda lakukan . Mempelajari apa yang Anda lakukan> mengolah muatan penolakan STL. Tidak ada yang mengatakan STL selalu merupakan jawaban terbaik. Apa yang saya katakan adalah bahwa jika Anda tidak bisa menjelaskan mengapa itu bukan jalan terbaik , Anda harus menggunakan STL.
Ed Ropple

11
Saya tidak berpikir itu provokatif sama sekali - itu diutarakan dengan cara agar tetap melekat dalam ingatan seseorang, tetapi itu adalah sikap yang sangat konservatif dan langsung. Singkatnya: orang-orang yang mengembangkan STL lebih berpengetahuan dan lebih siap daripada seseorang yang menemukan bahwa mereka harus mengajukan pertanyaan ini. Jika Anda harus bertanya kepada orang lain apakah STL sesuai atau tidak, Anda hampir pasti tidak memiliki pengetahuan khusus domain untuk menyiapkan solusi yang tepat untuk rumah.
Ed Ropple

4
"Ini akan menjadi hampir secepat platform memungkinkan". Ini adalah ketidakbenaran yang pasti, karena banyak vendor kompiler tidak dapat diganggu untuk menulis ulang STL sehingga benar-benar memeras kinerja yang paling banyak dari arsitektur tertentu. STL tidak memiliki jaminan apa pun tentang karakteristik kinerja kecuali untuk O. O besar. Namun mungkin seefisien atau tidak efisien seperti yang ingin dibuat oleh vendor kompiler.
Kaj

35

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.


sebenarnya menggunakan tipe non-pointer besar di peta adalah kasus penggunaan yang baik karena stdlib map memiliki persyaratan untuk tidak membatalkan iterator yang memaksa implementasi menggunakan pointer dan elemen yang dipetakan yang dialokasikan secara individual. Solusi terbaik untuk gim adalah menggunakan google::sparse_mapatau menulis sendiri.
v.oddou

mengapa peta tidak padat?
GameDeveloper

23

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 .


19
Masalah dengan penggunaan memori STL dan game biasanya dapat diselesaikan dengan kelas pengalokasi khusus. Memang, pada pekerjaan saya sebelumnya, kelas vektor "khusus" kami hanyalah pembungkus tipis di sekitar std::vectoryang melampaui pengalokasi default.
Blair Holloway

1
@ Blair Holloway: "Alokasi pengalokasi adalah berbasis kelas, bukan berbasis instance. Alokator diharuskan untuk membangun dan menghancurkan objek serta mengalokasikannya. Hal ini memaksa pencampuran dua konsep terpisah: alokasi dan konstruksi. Ini hanyalah sebagian dari masalah dengan stl-pengalokasi, sayangnya. " EA STL memberikan beberapa alasan yang lebih valid mengapa alokasi STD buruk. Bukan hanya "apakah atau tidak mereka dapat ditimpa".
Simon

@Simon - Saya tidak akan berdebat bahwa sistem pengalokasian STL sempurna, karena tidak. Kami butuh waktu lama untuk menemukan solusi yang berhasil. Apa yang saya katakan adalah bahwa dalam beberapa kasus, adalah mungkin untuk mendapatkan yang bisa diterapkan, solusi menggunakan STL ramah-game dan sedikit kerja dengan penyalur kustom.
Blair Holloway

@Simon - Untuk menguraikan: sementara STL mungkin rumit, ini adalah kode yang sangat teruji dan bebas bug; jika Anda dapat menggunakannya, Anda akan menghemat waktu karena harus men-debug solusi khusus. Pekerjaan saya saat ini menghindari STL dan memilih pengalokasi yang diseduh sendiri, dan saya harus menghabiskan waktu debugging dan refactoring beberapa kode itu, karena tidak pada tingkat kematangan yang sama dengan STL.
Blair Holloway

1
@Simon: Saya sedikit terlambat ke pesta di sini, tapi saya ingin tahu apakah Anda akan memberikan contoh spesifik tentang apa yang Anda maksud dengan itu. Apa contoh yang baik untuk memecahkan masalah tertentu dengan cara yang STL terlalu umum untuk diselesaikan secara efisien?
BRaffle

21

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 ++.


18
Saya tidak setuju pada upaya lebih ke C. Sebagian besar pengembang game serta penulis SDK menggunakan C ++. Faktanya, pengguna C besar terakhir adalah id dan bahkan Carmack telah pergi ke C ++ sekarang ...
Goz

82
Komentar Pak Acton agak kabur. Secara umum, STL sangat cocok untuk masalah tersebut. Jika Anda mencoba melakukan sesuatu sedemikian rupa sehingga pendekatan STL tampak "salah," mungkin ide yang bagus untuk mengevaluasi kembali pendekatan Anda dan melihat apakah Anda benar-benar melakukannya dengan cara yang cerdas. Dalam pengalaman saya, lebih sering daripada tidak, Anda mungkin tidak. (Jauh lebih cerdas, IMO, untuk memecahkan masalah dengan memahaminya secara kuat dalam konteks alat Anda daripada membuang alat hanya untuk mengulanginya dari awal.)
Ed Ropple

50
Pengalaman saya dengan STL hampir berlawanan. Ini efisien dan menghemat waktu. Jika Anda merasa perlu untuk menggulung pustaka templat atau pustaka wadah Anda sendiri, maka itu tidak masalah. Tapi jangan berpura-pura bahwa STL (atau meningkatkan, dalam hal ini) buruk. Saya telah menggunakan STL secara luas pada iPhone komersial, Nintendo DS, Wii, PC, Mac, dan game Xbox. Setiap kali saya dipaksa untuk menggunakan perpustakaan "lebih baik" orang lain, saya merasa kurang dan bermasalah.
BRaffle

5
Ini bekerja sama baiknya pada DS seperti halnya pada platform lain yang pernah saya gunakan. Saya menggunakan STL di seluruh kode UI dan AI. Permainan itu ds.ign.com/articles/832/832147p1.html . Saya bekerja di sebuah studio kecil yang merupakan bagian dari Amaze, yang merupakan bagian dari Yayasan 9.
BRaffle

7
Mike adalah semua tentang data. Melihat data menyarankan metode terbaik untuk mengubah data. Menerapkannya dalam skala besar dan Anda memiliki pemrograman. Dalam konteks ini kritiknya masuk akal. STL (dan pola desain) menyarankan bahwa alih-alih memeriksa data untuk menghasilkan solusi, kami memeriksa solusi dalam kantong trik kami untuk menemukan solusi yang sesuai dengan data. Saya tidak bermaksud berbicara untuk Mike, tetapi saya percaya dia akan menyarankan bahwa cara pendekatan masalah ini mundur, dan berpotensi menyebabkan solusi yang tidak efisien atau membengkak.
Dan Olson

19

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.


7
Peta <> hampir tidak pernah seperti apa yang ingin Anda gunakan untuk memori atau CPU apa pun yang efisien dalam konteks permainan. hash_map <> hampir selalu merupakan pilihan yang lebih baik, meskipun kinerja hash_map sangat berbeda dengan vendor. Jika Anda membangun gim yang baik untuk konsol atau fitur bermain jaringan yang dapat diskalakan, STL benar-benar bisa terlalu lambat atau membengkak untuk tujuan Anda.
Ben Zeigler

3
unordered_map <> sekarang tersedia secara luas dan memiliki persyaratan kinerja yang sangat ketat dalam konsep TR1 saat ini. (Untuk titik terlalu spesifikasi saya pikir - itu bahkan melarang hashing terbuka, dan sementara itu biasanya lebih lambat, saya tidak berpikir itu harus langsung dilarang oleh standar.)

5
STL menawarkan algoritme dan juga wadah. Tidak pernah ada alasan untuk tidak menggunakan versi stl dari suatu algoritma. Sebagai contoh, std::sortumumnya menggunakan introsort di bawahnya, sangat cepat dan cukup rumit sehingga Anda tidak ingin melakukannya sendiri.
deft_code

kebenaran adalah unordered_mapsalah satu dari C + + 11 atau meningkatkan keduanya terlalu lambat, yang Anda inginkan adalah peta hash alamat terbuka, seperti google :: sparse_map atau Anda sendiri.
v.oddou

16

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.


10

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.


ide menarik; apa yang Anda maksud dengan " menggunakan berbasis kelas baru dan menghapus "? Maksud Anda, mempercepat proses dengan menggunakan objek yang sudah ada di heap?
johnbakers

9

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.


Seperti disebutkan di tempat lain, Anda dapat memberikan pengalokasi khusus ke kelas wadah - ini dapat menggunakan daftar bebas jika Anda mau (array yang telah dialokasikan sebelumnya). Array-of-structs vs struct-of-array sangat tergantung pada apa yang Anda coba lakukan - tidak ada aturan keras dan cepat tentang mana yang lebih baik.
Skizz

Saya menghargai poin Anda bahwa penting untuk memahami dengan baik masalah yang Anda selesaikan. Tetapi dengan hormat, saya masih berpikir saya tidak setuju dengan kesimpulan Anda. Setiap masalah memiliki pola penggunaan yang tidak dapat diekspresikan ke pengalokasi STL khusus, tetapi dapat dengan mudah dimanfaatkan dalam wadah kustom, seperti pengalokasi blok tetap yang diimplementasikan dengan susunan datar. Dan menerapkan transformasi tetap pada array tipe homogen akan sangat mungkin menghasilkan koherensi cache yang jauh lebih baik daripada iterasi pada vektor tipe polimorfik dan menggunakan metode virtual.
Terrance Cohen

5

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!


1
"Ketahui kapan harus berdagang kinerja untuk kenyamanan". Iya. Kalimat ini saja merupakan jawaban yang sama baiknya dengan jawaban apa pun. Cari tahu apa yang perlu Anda capai dengan game Anda, konsultasikan dengan rekan-rekan dan putuskan apakah STL akan membantu Anda sampai di sana atau menghalangi Anda. Saya akan mengatakan jika Anda tidak ingin mengatur bar untuk grafis dan kinerja next-gen dengan game Anda, STL mungkin akan membantu Anda.
gkimsey

4

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?


2
Dalam praktiknya, menjelang akhir proyek, kinerja cenderung menjadi masalah kritis. Jika Anda menggunakan STL, Anda memiliki peluang yang sangat kecil untuk optimisasi karena ia mengambil aplikasi spesifik Anda dan menyelesaikannya secara umum. Memecahkan kasus tertentu dengan cara tertentu (dan tanpa alokasi memori dinamis) hampir selalu berkinerja lebih tinggi.
Terrance Cohen

2
Tetapi jika Anda tidak ingin alokasi memori dinamis, maka Anda seharusnya tidak menggunakan STL. Itulah intinya. Kode Anda sendiri tidak akan lebih baik, dan tentu saja bisa lebih buruk. The keputusan desain untuk menyalahgunakan STL adalah masalah di sini, bukan STL, kemampuan, atau karakteristik perf nya. Anda menyerang bagian yang salah dari masalah.
Ed Ropple

4

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.


4

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.


4

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.


3

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


3

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.


2

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.


2
Saya setuju 100% dengan bagian terakhir dari komentar Anda, tetapi saya akan melangkah lebih jauh: jika Anda dapat menunjukkan secara meyakinkan mengapa STL bukan pilihan yang baik, jangan gunakan STL. Kalau tidak, lakukan. Kultus kargo (mulai dari "oh, pengembang game menggunakan C ++!" Hingga "oh, pengembang game tidak menggunakan STL!") Tidak sehat. Saya akan, bagaimanapun, mengambil sedikit masalah dengan paragraf kedua Anda: Sangat tidak mungkin bahwa orang yang masih cukup naif untuk berpikir menerapkan kembali STL adalah ide yang baik akan membangun yang lebih baik vectordaripada orang-orang STL. Pada saat Anda dapat melakukannya, Anda tidak lagi berpikir Anda perlu! :-)
Ed Ropple

2

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.


2

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.


2

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.)


1

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 ++.


1
Meskipun Anda benar, mungkin ada penalti besar untuk refactoring; jadi membuat keputusan berdasarkan informasi di muka bukannya yang sewenang-wenang akan menghemat waktu Anda dalam jangka panjang.
Alan

1

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.


1
Saya setuju tentang waktu kompilasi. Setiap waktu kompilasi yang signifikan menggandakan jumlah pekerjaan yang hilang; misal, jika kompilasi berlangsung 5 menit, Anda akan menghabiskan 10 menit untuk mendapatkan kopi setiap kali. ;)
Ipsquiggle

Sementara saya melihat kedua sisi argumen ini, saya harus mengatakan saya sangat setuju dengan argumen Anda, Richard. +1.
Insinyur
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.