ECS? Saya benar-benar akan menyarankan bahwa mungkin tidak prematur jika demikian untuk menaruh banyak pemikiran ke sisi berorientasi data dari desain dan benchmark repetisi yang berbeda karena dapat berdampak pada desain antarmuka Anda , dan yang terakhir sangat mahal untuk berubah di akhir permainan. ECS juga hanya menuntut banyak pekerjaan dan pemikiran di muka dan saya pikir layak menggunakan sebagian dari waktu itu untuk memastikan itu tidak akan memberi Anda kesedihan kinerja tingkat desain lebih jauh di bawah garis mengingat bagaimana itu akan menjadi jantung dari hati Anda seluruh mesin freaking. Bagian ini memelototi saya:
unordered_map<string,[yada]>
Bahkan dengan optimasi string kecil, Anda memiliki wadah berukuran variabel (string) di dalam wadah berukuran variabel lain (unordered_maps). Bahkan, optimasi string kecil sebenarnya bisa sama berbahayanya dengan membantu dalam kasus ini jika tabel Anda sangat jarang, karena optimasi string kecil akan menyiratkan bahwa setiap indeks tabel hash yang tidak digunakan masih akan menggunakan lebih banyak memori untuk optimasi SS ( sizeof(string)akan menjadi jauh lebih besar) ke titik di mana total memori overhead tabel hash Anda mungkin lebih mahal daripada apa pun yang Anda simpan di dalamnya, terutama jika itu adalah komponen sederhana seperti komponen posisi, di samping menimbulkan lebih banyak cache yang hilang dengan langkah besar untuk mendapatkan dari satu entri di tabel hash ke yang berikutnya.
Saya mengasumsikan string adalah semacam kunci, seperti ID komponen. Jika demikian, ini sudah membuat segalanya lebih murah secara dramatis:
unordered_map<int,[yada]>
... jika Anda menginginkan manfaat memiliki nama yang mudah digunakan yang dapat digunakan skrip, misalnya, string yang diinternir dapat memberi Anda yang terbaik dari kedua dunia di sini.
Yang mengatakan, jika Anda bisa memetakan string ke kisaran yang cukup rendah dari indeks yang digunakan secara padat, maka Anda mungkin bisa melakukan ini:
vector<[yada]> // the index and key become one and the same
Alasan saya tidak menganggap ini terlalu dini adalah karena, sekali lagi, ini dapat berdampak pada desain antarmuka Anda. Maksud dari DOD seharusnya bukan untuk mencoba untuk datang dengan representasi data yang paling efisien yang dapat dibayangkan dalam sekali jalan IMO (yang umumnya harus dicapai secara iteratif sesuai kebutuhan), tetapi untuk memikirkannya cukup untuk merancang antarmuka di atas untuk bekerja dengan itu data yang membuat Anda cukup ruang bernapas untuk profil dan mengoptimalkan tanpa perubahan desain cascading.
Sebagai contoh naif, perangkat lunak pemrosesan video yang memasangkan semua kodenya dengan ini:
// Abstract pixel that could be concretely represented by
// RGB, BGR, RGBA, BGRA, 1-bit channels, 8-bit channels,
// 16-bit channels, 32-bit channels, grayscale, monochrome,
// etc. pixels.
class IPixel
{
public:
virtual ~IPixel() {}
...
};
Tidak akan jauh tanpa berpotensi menulis ulang epik, karena gagasan mengabstraksi pada tingkat piksel tunggal sudah sangat tidak efisien ( vptritu sendiri akan sering menghabiskan lebih banyak memori daripada seluruh piksel) dibandingkan dengan mengabstraksi pada tingkat gambar (yang akan sering mewakili jutaan piksel). Jadi taruh pemikiran yang cukup dalam representasi data Anda terlebih dahulu sehingga Anda tidak harus menghadapi skenario mimpi buruk seperti itu, dan idealnya tidak lebih, tapi di sini saya pikir ada baiknya memikirkan hal-hal ini di muka karena Anda tidak ingin membangun sebuah mesin rumit di sekitar ECS Anda dan temukan bahwa ECS itu sendiri adalah penghambat dalam cara yang mengharuskan Anda mengubah hal-hal pada tingkat desain.
Mengenai kesalahan cache ECS, menurut saya pengembang sering berusaha terlalu keras untuk membuat cache ECS mereka ramah. Itu mulai menghasilkan sedikit bang untuk uang untuk mencoba mengakses semua komponen Anda dengan cara yang berdekatan, dan sering akan menyiratkan menyalin dan mengacak data di semua tempat. Biasanya cukup baik untuk, katakanlah, hanya indeks komponen sortir radix sebelum mengaksesnya sehingga Anda mengaksesnya dengan cara di mana Anda setidaknya tidak memuat wilayah memori ke dalam garis cache, hanya untuk mengusirnya, dan kemudian memuatnya, lalu memuat semuanya lagi dalam loop yang sama hanya untuk mengakses bagian yang berbeda dari garis cache yang sama. Dan ECS tidak harus memberikan efisiensi luar biasa di seluruh papan. Ini tidak seperti manfaat sistem input dari itu sebanyak fisika atau sistem rendering, jadi saya sarankan bertujuan untuk "baik" efisiensi secara menyeluruh dan "luar biasa" hanya di tempat-tempat di mana Anda benar-benar membutuhkannya. Yang mengatakan, penggunaanunordered_mapdan di stringsini cukup mudah untuk dihindari.