Pada titik tertentu mesin HARUS mengkhususkan diri dan tahu hal-hal tentang permainan. Saya akan pergi bersinggungan di sini.
Ambil sumber daya dalam RTS. Satu permainan mungkin memiliki Creditsdan yang Crystallainnya MetaldanPotatoes
Anda harus menggunakan konsep OO dengan benar dan mencari maks. penggunaan kembali kode. Jelas bahwa konsep Resourceada di sini.
Jadi kami memutuskan sumber daya memiliki yang berikut:
- Sebuah kait di loop utama untuk menambah / mengurangi sendiri
- Cara untuk mendapatkan jumlah saat ini (mengembalikan sebuah
int)
- Cara untuk mengurangi / menambah sewenang-wenang (pemain mentransfer sumber daya, pembelian ....)
Perhatikan bahwa gagasan tentang a ini Resourcebisa mewakili pembunuhan atau poin dalam permainan! Itu tidak terlalu kuat.
Sekarang mari kita pikirkan sebuah game. Kita dapat mengurutkan mata uang dengan bertransaksi dalam penny dan menambahkan titik desimal ke output. Yang tidak bisa kita lakukan adalah sumber daya "instan". Seperti mengatakan "pembangkit listrik"
Katakanlah Anda menambahkan InstantResource kelas dengan metode serupa. Anda sekarang (mulai) mencemari mesin Anda dengan sumber daya.
Masalah
Mari kita ambil contoh RTS lagi. Misalkan pemain apa pun menyumbangkan sebagian Crystalkepada pemain lain. Anda ingin melakukan sesuatu seperti:
if(transfer.target == engine.getPlayerId()) {
engine.hud.addIncoming("You got "+transfer.quantity+" of "+
engine.resourceDictionary.getNameOf(transfer.resourceId)+
" from "+engine.getPlayer(transfer.source).name);
}
engine.getPlayer(transfer.target).getResourceById(transfer.resourceId).add(transfer.quantity)
engine.getPlayer(transfer.source).getResourceById(transfer.resourceId).add(-transfer.quantity)
Namun ini benar-benar sangat berantakan. Ini tujuan umum, tapi berantakan. Meskipun sudah memaksakan resourceDictionaryyang berarti sekarang sumber daya Anda harus memiliki nama! DAN itu adalah per pemain, jadi Anda tidak dapat memiliki sumber daya tim lagi.
Ini adalah "terlalu banyak" abstraksi (bukan contoh yang brilian akan saya akui) sebagai gantinya Anda harus mencapai titik di mana Anda menerima bahwa permainan Anda memiliki pemain dan kristal, maka Anda hanya dapat memiliki (misalnya)
engine.getPlayer(transfer.target).crystal().receiveDonation(transfer)
engine.getPlayer(transfer.source).crystal().sendDonation(transfer)
Dengan kelas Playerdan kelas CurrentPlayerdi mana CurrentPlayer'scrystal objek secara otomatis akan menampilkan hal-hal di HUD untuk transfer / pengiriman donasi.
Ini mencemari mesin dengan kristal, sumbangan kristal, pesan pada HUD untuk pemain saat ini dan semua itu. Lebih cepat dan lebih mudah untuk membaca / menulis / memelihara (yang lebih penting, karena tidak secara signifikan lebih cepat)
Komentar akhir
Kasus sumber daya tidak brilian. Saya harap Anda masih bisa mengerti intinya. Jika ada yang saya tunjukkan bahwa "sumber daya tidak termasuk dalam mesin" seperti apa yang dibutuhkan oleh game tertentu dan apa yang berlaku untuk semua pengertian tentang sumber daya adalah SANGAT berbeda. Apa yang biasanya Anda temukan adalah 3 (atau 4) "lapisan"
- "Core" - ini adalah definisi mesin buku teks, ini adalah adegan grafik dengan kait acara, ini berkaitan dengan shader dan paket jaringan dan gagasan abstrak pemain
- "GameCore" - Ini sangat umum untuk jenis game tetapi tidak untuk semua game - misalnya sumber daya di RTS atau amunisi di FPS. Logika permainan mulai meresap ke sini. Di sinilah konsep sumber daya kami sebelumnya. Kami telah menambahkan hal-hal ini yang masuk akal untuk sebagian besar sumber daya RTS.
- "GameLogic" SANGAT spesifik untuk game yang sebenarnya dibuat. Anda akan menemukan variabel dengan nama-nama seperti
creatureatau shipatau squad. Menggunakan warisan Anda akan mendapatkan kelas yang menjangkau semua 3 lapisan (misalnya Crystal adalah Resource yang merupakan GameLoopEventListener kata)
- "Aset" ini tidak berguna untuk game lain. Ambil contoh skrip AI gabungan di paruh 2, mereka tidak akan digunakan dalam RTS dengan mesin yang sama.
Membuat game baru dari mesin lama
Ini SANGAT umum. Fase 1 adalah untuk merobek lapisan 3 dan 4 (dan 2 jika permainan adalah tipe yang BENAR-BENAR berbeda) Misalkan kita membuat RTS dari RTS lama. Kami masih memiliki sumber daya, tidak hanya kristal dan barang-barang - sehingga kelas dasar di lapisan 2 dan 1 masih masuk akal, semua kristal yang dirujuk dalam 3 dan 4 dapat dibuang. Jadi kami lakukan. Namun kami dapat memeriksanya sebagai referensi untuk apa yang ingin kami lakukan.
Polusi pada lapisan 1
Ini bisa terjadi. Abstraksi dan kinerja adalah musuh. UE4 misalnya menyediakan banyak kasus komposisi yang dioptimalkan (jadi jika Anda ingin X dan Y seseorang menulis kode yang melakukan X dan Y secara bersamaan dengan sangat cepat - ia tahu ia melakukan keduanya) dan hasilnya BENAR-BENAR cukup besar. Ini tidak buruk tetapi memakan waktu. Layer 1 akan memutuskan hal-hal seperti "bagaimana Anda mengirimkan data ke shaders" dan bagaimana Anda menghidupkan sesuatu. Melakukannya dengan cara terbaik untuk proyek Anda SELALU baik. Coba saja dan rencanakan masa depan, menggunakan kembali kode adalah teman Anda, mewarisi ke mana masuk akal.
Lapisan klasifikasi
TERAKHIR (saya janji) jangan terlalu takut dengan lapisan. Engine adalah istilah kuno dari masa lalu pipa fungsi tetap di mana mesin cukup banyak bekerja dengan cara yang sama secara grafis (dan sebagai hasilnya memiliki banyak kesamaan) pipa yang dapat diprogram menghidupkan ini di kepalanya dan dengan demikian "lapisan 1" menjadi tercemar dengan efek apa pun yang ingin dicapai pengembang. AI adalah fitur yang membedakan (karena berbagai pendekatan) dari mesin, sekarang AI dan grafis.
Kode Anda tidak boleh diajukan di lapisan ini. Bahkan mesin Unreal yang terkenal memiliki BANYAK versi yang berbeda masing-masing khusus untuk permainan yang berbeda. Ada beberapa file (selain struktur data seperti mungkin) yang tidak akan berubah. Ini baik-baik saja! Jika Anda ingin membuat gim baru dari gim lain, dibutuhkan waktu lebih dari 30 menit. Kuncinya adalah merencanakan, untuk mengetahui bit apa yang akan disalin dan ditempelkan dan apa yang harus ditinggalkan.