kengine
Kengine 6.0
Mesin Koala adalah mesin game yang sepenuhnya diimplementasikan sebagai Sistem Komponen Entitas (ECS).
Mesinnya didasarkan pada entt. Integrasi dengan perangkat lunak lain menggunakan EnTT harus langsung. Dokumentasi ini mengasumsikan setidaknya pengetahuan dasar tentang EnTT dan terminologinya ( entity , registry , handle ...).
Contoh proyek menampilkan beberapa fitur inti. Ini harus memberi Anda gambaran tentang apa yang ditawarkan dukungan mesin untuk refleksi dan runtime.
Mesin menggunakan submodule git, dan karenanya harus dikloning secara rekursif dengan
git clone https://github.com/phisko/kengine --recursive
Mesin telah diuji pada Windows dengan MSVC dan Mingw.
Kompilasi Linux bekerja dengan GCC. Pada saat penulisan, dentang tidak mendukung C ++ 20 constexpr std::string dan std::vector .
Mesin membutuhkan kompiler C ++ 20 .
Mesin dimulai sebagai proyek gairah/siswa pada 2016-17. Teman -teman/kolega saya dan saya harus mengimplementasikan ECS dari bawah ke atas. Kami menginginkan keamanan dan kejelasan jenis absolut, dan sementara kami sudah bermain -main dengan metaprogramming template, ini adalah kesempatan bagi kami untuk belajar lebih banyak tentang hal itu.
Setelah ECS inti berfungsi, mesin berubah menjadi taman bermain untuk mempelajari lebih lanjut tentang pengembangan game. Saya belajar rendering OpenGL, cara menggunakan Navmeshes dengan Recast/Detour, pengaturan fisika dengan peluru ... sambil mengembangkan pembantu yang bermanfaat dan fasilitas refleksi runtime yang kompatibel dengan ECS.
Setelah sekarang lebih dari 5 tahun mengerjakan mesin, saya menyadari inti ECS itu sendiri tidak lagi menjadi fokus proyek ini. Perpustakaan lain, dan EnTT , menawarkan API yang sangat mirip, dengan fitur yang jauh lebih canggih. Jadi saya meluangkan waktu untuk benar -benar mengeluarkan ECS internal dan menggantinya dengan EnTT . Semua fitur tetap sama, dan ini akan memberi saya lebih banyak waktu untuk mengerjakan pembantu yang bermanfaat, yang dapat bekerja dengan proyek -proyek EnTT lainnya.
Banyak bagian mesin (seperti sistem skrip atau editor entitas IMGUI) memanfaatkan API refleksi putils . Sebagian besar komponen dalam sampel berikut dengan demikian didefinisikan sebagai dipantulkan.
Kode mesin disusun dalam tiga kategori:
Perhatikan bahwa systems bukan objek dari kelas tertentu. Sistem hanyalah entitas dengan komponen eksekusi (atau apa pun yang mereka butuhkan untuk melakukan pekerjaan mereka). Entitas kemudian hidup dalam registry dengan sisa keadaan permainan. Ini memungkinkan pengguna mengintrospeksi sistem atau menambahkan perilaku kepada mereka seperti entitas lainnya.
Ketiga kategori ini dibagi menjadi berbagai perpustakaan, misalnya:
Perhatikan bahwa beberapa perpustakaan berisi sub-perpustakaan, misalnya:
Bagian CMake lebih detail tentang cara bekerja dengan perpustakaan ini.
Mesin ini dilengkapi dengan jumlah komponen pra-dibangun (cukup besar) yang dapat digunakan untuk bootstrap permainan, atau hanya sebagai contoh yang dapat Anda dasarkan implementasi Anda sendiri.
Komponen -komponen ini cocok dengan tiga kategori:
Komponen data menyimpan data tentang entitas mereka.
Komponen data adalah apa yang pertama kali terlintas dalam pikiran ketika memikirkan komponen, seperti transformasi atau nama.
Komponen data terkadang dapat memiliki fungsi:
Komponen fungsi memiliki fungsi untuk meminta, mengubah, atau memberi tahu entitas mereka.
Komponen fungsi hanyalah pemegang untuk fungsi yang dapat dilampirkan sebagai komponen untuk entitas. Mekanik ini dapat digunakan untuk:
Komponen fungsi adalah jenis yang mewarisi dari base_function, memberikannya tanda tangan fungsi sebagai parameter template.
Untuk memanggil komponen fungsi, seseorang dapat menggunakan operator() atau fungsi call .
entt::registry r;
const auto e = r.create();
r.emplace<main_loop::execute>(e,
[]( float delta_time) { std::cout << " Yay! " << std::endl; }
);
const auto & execute = r.get<main_loop::execute>(e); // Get the function
execute ( 0 .f); // Call it with its parameters
execute.call( 42 .f); // AlternativelyKomponen meta adalah komponen untuk komponen.
Mesin menggunakan "tipe entitas" untuk menyimpan informasi tentang berbagai komponen yang digunakan. Setiap entitas jenis mewakili jenis komponen yang berbeda, dan dapat digunakan untuk menanyakan properti komponen saat runtime.
Komponen meta dilampirkan pada "entitas tipe" ini, dan tahan implementasi fungsi generik untuk jenis tertentu. Karena mereka memiliki fungsi, mereka sangat mirip dengan komponen fungsi.
Contohnya membuat ini lebih jelas: meta :: imgui :: edit adalah komponen meta yang, ketika dipanggil, akan menggambar properti "komponen induknya" menggunakan imgui untuk entitas yang diberikan. Kode berikut akan menampilkan jendela untuk mengedit komponen nama e
// r is a registry with the "type entity" for `name` already setup
const auto e = r.create();
r.emplace<core::name>(e);
const auto type_entity = type_helper::get_type_entity<core::name>(r);
const auto & edit = r.get<meta::imgui::edit>(type_entity);
if (ImGui::Begin( " Edit name " ))
edit ({ r, e });
ImGui::End ();Jika Anda menggeneralisasi ini, Anda dapat mengedit semua komponen untuk entitas dengan kode berikut:
// r is a registry with the "type entities" for all used components already setup
// e is an entity with an unknown set of components
if (ImGui::Begin( " Edit entity " ))
for ( const auto & [type_entity, edit] : r.view<meta::imgui::edit>()) {
edit ({ r, e });
}
ImGui::End ();Lihat CMake untuk instruksi tentang cara mengaktifkan setiap perpustakaan.
Skrip python generate_type_registration disediakan, yang dapat digunakan untuk menghasilkan file C ++ yang berisi fungsi yang akan mendaftarkan satu set jenis yang diberikan dengan mesin.
Ini sama sekali tidak wajib .
Mesin menggunakan CMake sebagai sistem build. Kerangka kerja khusus telah diberlakukan untuk menyederhanakan pembuatan perpustakaan. Root cmakelists mengulangi sub-direktori dan secara otomatis menambahkannya sebagai perpustakaan jika mereka cocok dengan beberapa kondisi.
Perpustakaan Basis kengine Interface dibuat yang tautan dengan semua perpustakaan yang diaktifkan, sehingga klien dapat dengan mudah menautkannya dengan itu.
Opsi cmake berikut diekspos.
KENGINE_TESTSMengkompilasi tes yang dapat dieksekusi untuk pustaka yang mengimplementasikan tes.
KENGINE_NDEBUGMenonaktifkan kode debug.
KENGINE_TYPE_REGISTRATIONAkan menghasilkan kode pendaftaran jenis untuk jenis mesin. Ini adalah pusat dari banyak kemampuan refleksi mesin, karena memberikan implementasi untuk komponen meta.
KENGINE_GENERATE_REFLECTIONAkan memperbarui header refleksi untuk jenis mesin. Ini sudah dihasilkan sebelumnya, jadi kecuali jika Anda memodifikasi kode sumber mesin, Anda tidak perlu mengaktifkan ini.
Semua perpustakaan dinonaktifkan secara default, untuk menghindari membangun dependensi yang tidak diinginkan. Setiap perpustakaan dapat diaktifkan secara individual dengan mengatur opsi CMake untuk ON . Lihat Penamaan Perpustakaan untuk nama opsi.
Atau, semua perpustakaan dapat diaktifkan dengan opsi KENGINE_ALL_SYSTEMS .
Perhatikan bahwa sub-perpustakaan membutuhkan perpustakaan induknya untuk diaktifkan: kengine_imgui_entity_editor membutuhkan kengine_imgui.
Perpustakaan dinamai tergantung pada jalur relatif mereka ke akar mesin. Ganting di jalur hanya digantikan oleh garis bawah, misalnya:
kengine_corekengine_imgui_toolNama -nama ini adalah:
KENGINE_CORE untuk kengine_core )KENGINE_CORE_EXPORT untuk kengine_core )Dimungkinkan untuk menguji keberadaan perpustakaan selama kompilasi berkat C ++ Define Macro. Ini memiliki nama yang sama dengan opsi cmake, misalnya:
# ifdef KENGINE_CORE
// The kengine_core library exists
# endifBeberapa perpustakaan memanfaatkan VCPKG untuk manajemen ketergantungan.
Karena perpustakaan secara otomatis terdeteksi oleh root CMakeLists.txt , membuat perpustakaan baru cukup mudah.
Perpustakaan secara otomatis menautkan terhadap kengine_core , karena memberikan pembantu yang harus digunakan oleh semua perpustakaan (seperti log_helper dan profile_helper).
Sub-tibraria secara otomatis terhubung dengan orang tua mereka. Misalnya, kengine_imgui_entity_editor secara otomatis menautkan terhadap kengine_imgui.
File sumber dari subdirektori helpers dan systems perpustakaan ditambahkan secara otomatis. Jika tidak ada yang ditemukan, perpustakaan akan menjadi perpustakaan antarmuka CMake.
Jenis pendaftaran dan kode refleksi dapat secara otomatis dihasilkan untuk komponen. Secara default, semua header dalam data dan functions perpustakaan akan diteruskan ke skrip pembuatan.
systems/tests pula dengan file sumber, jika helpers/tests *.tests.cpp .
CMakeLists.txt Custom Perpustakaan Dasar seharusnya tidak memerlukan CMakeLists.txt mereka sendiri, karena file sumbernya akan secara otomatis. Namun, jika perpustakaan membutuhkan perilaku khusus (misalnya untuk menambahkan sumber tambahan atau untuk menautkan dengan perpustakaan pihak ketiga), itu dapat menambahkan CMakeLists.txt sendiri. Bahwa CMakeLists.txt akan dipanggil setelah panggilan ke add_library .
Variabel dan fungsi berikut didefinisikan sebelum memanggil CMakeLists.txt :
kengine_library_name : nama perpustakaankengine_library_tests_name : Nama target googletest perpustakaanlink_type : Jenis tautan perpustakaan ( PUBLIC atau INTERFACE , tergantung pada apakah sumber ditemukan atau tidak)kengine_library_link_public_libraries(libraries) : tautan terhadap perpustakaan lain (secara publik)kengine_library_link_private_libraries(libraries) : tautan terhadap perpustakaan lain (secara pribadi)register_types_from_headers(headers) : Menambahkan header untuk jenis pendaftaran dan header refleksi yang dapat dihasilkansubdirectory_is_not_kengine_library(path) : Menunjukkan ke root CMakeLists.txt bahwa itu tidak boleh memproses path sebagai perpustakaan kengine
