Masa depan game on-chain: 'Janji mesin MUD ECS'

Menengah3/18/2024, 8:59:36 AM
Artikel ini memberikan penjelasan teknis dan solusi untuk masalah industri permainan berantai berdasarkan mesin ECS.

Cita-cita web3 tampaknya sangat cocok dengan industri game dan tren gamifikasi dalam beberapa tahun terakhir. Selama beberapa waktu, kita telah dijanjikan sebuah disrupsi baru dalam bentuk pengalaman yang unik - On-chain-gaming. Dengan sifat-sifat seperti desentralisasi yang menggeser keseimbangan kekuatan dari para petahana industri game ke arah entitas kreatif, komposabilitas yang mendobrak tembok-tembok yang telah lama tertutup, dan kepemilikan sejati bagi para pemain.

Namun, cita-cita yang kuat ini tetap berada di samping karena kita belum melihatnya dalam praktik. MUD adalah upaya berani pertama untuk membuat kerangka kerja lengkap untuk game on-chain, sebuah percikan yang dapat memicu generasi game berikutnya. Ini bukanlah mimpi di siang bolong. Dalam waktu yang singkat, tim MUD bertanggung jawab atas OPcraft, sebuah game bertema Minecraft 3D yang sepenuhnya on-chain.

Pelajaran dari industri permainan tradisional

Banyak hal yang dapat dikatakan tentang obsesi untuk berinovasi, membangun segala sesuatu dari bawah ke atas, dan menciptakan makhluk yang sama sekali baru. Namun mengenai game, ada pelajaran puluhan tahun dalam pola desain dan penciptaan ceruk teknik baru yang harus ditanggapi dengan serius. Mengabaikan hal ini sama saja dengan mencoba membuat game AAA dengan teknologi Atari.

Ketika melihat tahun-tahun awal pengembangan game, kita dapat melihat kemiripan yang jelas dengan game on-chain - banyak sekali talenta dan proyek yang sangat inspiratif, tetapi juga kurangnya koordinasi dan kerangka kerja yang jelas.

Pada masa-masa awal video game, sebelum dimulainya mesin game, keyakinan dan pola desain yang mapan. Video game yang berbeda memiliki sedikit kesamaan, hingga pada titik tertentu, game yang serupa dapat memiliki basis kode yang sama sekali berbeda. Tetapi dengan diperkenalkannya mesin game, semuanya berubah.

Sulit untuk membuat perbedaan yang jelas antara mesin game dan game itu sendiri. Secara umum, game engine adalah kerangka kerja dengan seperangkat aturan dan pola desain yang dapat sedikit dimodifikasi dan diperluas untuk membuat implementasi game yang berbeda. Pada tahun 90-an, setelah bertahun-tahun pengembangan game yang terfragmentasi, sesuatu berubah, dan mesin game "berbasis genre" dan beberapa upaya untuk mengembangkan mesin tujuan umum memimpin. Game seperti Doom dan Unreal memiliki komponen inti yang dapat digunakan kembali untuk membuat berbagai macam game. Game dengan genre serupa mulai berbagi banyak implantasi logika inti mereka. Biaya dan kerumitan pengembangan game balap, pertarungan, dan penembak orang pertama menurun drastis. Hal yang mustahil menjadi mungkin, dan generasi game serta kode yang ditingkatkan telah terakumulasi di atas satu sama lain. Dari perspektif perangkat lunak, ini adalah salah satu alasan utama pengembangan game menjadi industri yang sangat besar.

Ada beberapa masalah inti yang terkait dengan game on-chain:

  1. Kurangnya kerangka kerja: Setiap tim mencoba membangun semuanya dari awal sehingga menghasilkan efisiensi yang buruk dan kurangnya pengetahuan sistemik setelah mengumpulkan pengalaman para pembangun yang menangani masalah yang sama dan mengoptimalkan solusi terbaik.
  2. Kurangnya penggunaan ulang kode: Ambil contoh banyak game on-chain yang sedang dikembangkan saat ini. Berapa banyak dari mereka yang dapat disalin dengan sukses untuk membuat game yang sedikit berbeda? Berapa banyak dari mereka yang memiliki perbedaan yang jelas antara berbagai lapisan dan komponen permainan yang memungkinkan pembuatan generasi baru dengan basis kode yang serupa? Janji untuk menciptakan proyek sumber terbuka yang paling signifikan dan saling berhubungan untuk game tampaknya masih jauh.
  3. Kurangnya kemampuan menyusun data: Ini tidak berakhir dengan penggunaan ulang kode. Ini juga tentang kemampuan game on-chain untuk memanfaatkan status blockchain bersama untuk membangun di atas satu sama lain menggunakan data game A dalam game B. Dalam praktiknya, dibutuhkan banyak pekerjaan dan sumber daya untuk menggabungkan data dan logika satu game ke dalam game lainnya.

Solusi dari MUD:

Mud adalah upaya berani pertama untuk membuat mesin dan kerangka kerja untuk game on-chain dengan menyediakan struktur untuk Maintainability, upgradability, dan moldability. Pola Entity Component System (ECS) yang dianjurkan oleh mud tidak hanya masuk akal dalam pengertian pengembangan game secara umum, tetapi lebih dari itu untuk pengembangan game on-chain.

ECS dalam kontrak pintar:

Blok bangunan paling dasar dalam MUD adalah komponen. Mereka menggunakan kontrak yang berfungsi seperti basis data yang menyimpan data tentang entitas. Sebagai contoh, mari kita ambil sebuah entitas (alamat) seperti dompet pemain. Entitas yang diwakili oleh sebuah alamat dapat memiliki properti yang berbeda, seperti nilai posisi (x,y) pada komponen posisi, level 10 pada komponen level, dan 50 pada komponen koin. Komponen hanya terdiri dari pemetaan dan konfigurasi dasar. Sistem lebih rumit dan menerapkan logika perubahan nilai dalam komponen. Anda dapat memikirkan hal ini sebagai sistem yang mengkhususkan API untuk permintaan POST pada basis data (komponen). Mereka dapat melakukannya hanya jika diberikan akses menulis ke komponen tertentu. Di sini menjadi menarik. Sistem dapat berinteraksi dengan berbagai komponen untuk membuat logika yang terperinci. Anda dapat memiliki sistem pergerakan yang menentukan pergerakan valid yang dapat dilakukan pemain (misalnya, dua langkah setiap kali), dan Anda dapat memiliki sistem hadiah yang memberi pemain koin setiap kali mereka naik level. Semuanya terdaftar di "Kontak dunia" sehingga setiap perubahan dalam data komponen diikuti oleh peristiwa yang dipancarkan. Kontrak dunia tidak memerlukan izin. Siapa pun dapat menambahkan sistem dan komponen baru. Secara teori, dunia yang berbeda dapat berinteraksi satu sama lain.

Membawa ECS ke game on-chain menghasilkan struktur yang sangat elegan, sehingga OPcraft hanya terdiri dari 10 komponen dan sekitar 15 sistem. Anda dapat melihat postingan blog yang bagus ini di MUD.dev

Kemampuan komposisi yang sesungguhnya

Sistem ECS tidak hanya masuk akal dalam pengembangan game tradisional, tetapi terlebih lagi dalam game on-chain dengan menyediakan dua fitur penting

  1. Kemampuan peningkatan game yang digunakan
  2. Tingkat komposabilitas tertinggi

Bayangkan dua jalur. Salah satunya adalah mempertahankan desain dasar. Dan yang lainnya adalah mengubah logika permainan inti.

Pikirkan tentang game strategi PVT standar di mana pemain dapat membangun pasukan untuk bertempur satu sama lain. Versi dasarnya adalah 2D, tetapi sekarang tim telah memutuskan bahwa mereka ingin membuat render 3D yang mendetail dari game ini. Yang perlu mereka lakukan adalah mengambil semua sistem yang berhubungan dengan posisi dan membuat versi yang ditingkatkan dengan koordinat (x,y,z), bukan (x,y). Semua sistem dan komponen lainnya (seperti sistem serangan, HP, dan pembangunan pasukan) dapat tetap sama. Bahkan lebih dari sekadar tim pengembang awal, komunitas dapat membuat mod game yang berbeda dengan menerapkan ulang sistem dan komponen atau bahkan berinteraksi dengan komponen yang sama dengan memberikan akses penulisan ke sistem baru (jika ini adalah game milik komunitas, berbagai model tata kelola dapat diterapkan untuk keputusan semacam ini)

Pendekatan lain akan mempertahankan komponen dan sistem yang sama tanpa memberikan akses penulisan sistem baru. Tetapi dengan komponen dan sistem tambahan untuk memperluas fungsionalitas dalam game, seperti apa bentuknya? Pertimbangkan permainan catur dasar pada rantai. Sistem gerakan dan aturan sudah diterapkan. Orang-orang dapat memainkan game ini seolah-olah mereka bermain catur di dunia nyata, tetapi mungkin tim Anda memutuskan bahwa Anda perlu membuat lapisan tambahan, lapisan sosial yang terdiri dari sistem peringkat untuk perjodohan atau kasus penggunaan lainnya. Yang perlu Anda lakukan adalah menambahkan komponen peringkat dan sistem dengan aturan peringkat. Hal ini tidak hanya menghasilkan pergeseran yang sangat mulus ke versi game baru (UX yang lebih baik), tetapi juga menciptakan sarana teknis untuk versi yang berbeda untuk hidup berdampingan atau di atas satu sama lain di tingkat kontrak pintar. Pemain dapat tetap menggunakan berbagai versi game sambil berinteraksi dengan data komponen inti yang sama, yang sangat inovatif, terlepas dari aplikasi composability. Ini menciptakan fitur keabadian keikutsertaan, menciptakan dimensi lain dari kepemilikan yang disediakan oleh game on-chain. Kepemilikan sejati dari berbagai aset game (seperti skor, NFT, pencapaian) yang dijamin dengan logika yang tidak dapat diubah yang dapat diperpanjang dengan peningkatan tambahan tetapi tidak berubah pada intinya. Ini memecahkan salah satu masalah utama game web3, yaitu kemampuan kreator untuk melakukan nerf aset tanpa persetujuan.

Perspektif keseluruhan dari sisi klien:

Perhatikan bahwa MUD adalah proyek yang sedang berjalan. Bagian berikutnya mungkin tidak mutakhir dan mengandung beberapa ketidakakuratan dan perbedaan kasar, tetapi arsitektur umum tidak diharapkan untuk diubah secara drastis.

Sejauh ini, kami telah melihat MUD di tingkat kontrak pintar. Namun masih banyak lagi. MUD menyediakan paket lengkap dengan pustaka klien dan lapisan. Ada beberapa fitur unik yang didesain untuk MUD.

  1. Komposabilitas klien
  2. Klien sepenuhnya disinkronkan dengan perubahan status blockchain (data game)
  3. PhaserX sebagai lapisan rendering

Mari kita selami detail teknis untuk membuatnya lebih konkret.

Lapisan jaringan:

Lapisan jaringan adalah lapisan dasar klien. Ini berisi konfigurasi dasar (kontrak dunia, permainan, dan konfigurasi jaringan) dan API untuk interaksi permainan. Ketika lapisan jaringan dibuat, lapisan ini memiliki spesifikasi semua komponen dan sistem yang berbeda yang dapat berinteraksi dengan klien Anda, dan Anda dapat memilih untuk berinteraksi hanya dengan komponen/sistem tertentu. Misalnya, jika Anda ingin membuat gerakan dalam game Anda dan memberikan representasi di frontend, Anda harus membuat lapisan jaringan yang disinkronkan dengan kontrak pintar komponen posisi yang digunakan dan juga dengan sistem gerakan. Sekarang Anda dapat membuat Move API yang mengambil posisi dan beberapa objek (entitas) dalam game dan mengatur posisinya atau memindahkannya dari satu tempat ke tempat lain. Setiap saat pemain akan menggunakan Move API. Mereka akan mengirimkan transaksi ke blockchain. Dalam kasus sistem pergerakan, mereka akan menjalankan fungsi dalam kontrak pintar sistem pergerakan.

Struktur ini memungkinkan game berbasis multi-klien. Setiap orang dapat membuat klien yang unik, dan semuanya sama validnya selama disinkronkan dengan blockchain dan mengikuti struktur dasar lapisan jaringan. Kami telah melihat kasus penggunaan yang sangat keren untuk game multi-klien, seperti dalam kasus hutan gelap, di mana para pemain bersaing satu sama lain tetapi menggunakan klien dan plugin yang berbeda. Struktur klien memungkinkan kami untuk melakukan implantasi lapisan jaringan dan memodifikasi API untuk mendapatkan versi klien yang berbeda dengan sangat cepat, sehingga mencapai tingkat kemampuan cetakan dan komposabilitas klien yang tinggi.

Anda mungkin bertanya bagaimana tepatnya komponen klien disinkronkan dengan komponen rantai. Ini adalah salah satu tantangan signifikan yang dihadapi para pembuat game ketika berhadapan dengan sisi klien dari game on-chain. MUD memiliki beberapa solusi untuk itu.

Pertama, MUD menempatkan fitur snapshot yang memungkinkan klien untuk melakukan sinkronisasi dengan keadaan dunia (yaitu, nilai entitas berdasarkan komponen) tanpa memproses semua peristiwa masa lalu untuk merekonstruksi keadaan, yang menghasilkan latensi rendah dan penurunan kompleksitas.

Selain itu, sistem ID MUD, di mana setiap sistem dan komponen mendapatkan id berdasarkan nama mereka, dan pada saat penyebaran, mereka akan didaftarkan di kontrak dunia, membuatnya jauh lebih mudah untuk melacak perubahan, berinteraksi dengan permainan, dan mengambil acara dengan mudah.

Lapisan rendering - kapan dan bagaimana peristiwa dirender

MUD hadir dengan PhaserX, "Mesin yang sangat skalabel yang dibangun di atas phaser", PhaserX tidak wajib. Di OPcraft, terdapat mesin voxel Noa sebagai pengganti PhaserX. Secara teori, Anda dapat menggunakan mesin apa pun yang Anda inginkan selama mesin tersebut mengikuti struktur.

Seperti yang dinyatakan sebelumnya, setiap komponen dan sistem terdaftar pada kontrak dunia, dan ketika terjadi perubahan, sebuah peristiwa akan dipancarkan (dengan data yang diidentifikasi seperti ID komponen dan ID entitas). Di sini, layanan streaming ECS dapat memberikan opsi kepada klien untuk memilih acara mana yang akan dilanggan.

Representasi grafis dari entitas dapat berupa apa pun yang Anda inginkan. Game pertarungan dapat memiliki karakter anime, ksatria, atau bahkan influencer kripto favorit Anda. Semuanya adalah versi yang valid selama mereka mewakili dan bereaksi terhadap peristiwa on-chain.

Penafian: Penafian

  1. Artikel ini dicetak ulang dari[mirror], Semua hak cipta adalah milik penulis asli[Matchbox DAO]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim " Gate Learn "), dan mereka akan segera menanganinya.
  2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
  3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.

Masa depan game on-chain: 'Janji mesin MUD ECS'

Menengah3/18/2024, 8:59:36 AM
Artikel ini memberikan penjelasan teknis dan solusi untuk masalah industri permainan berantai berdasarkan mesin ECS.

Cita-cita web3 tampaknya sangat cocok dengan industri game dan tren gamifikasi dalam beberapa tahun terakhir. Selama beberapa waktu, kita telah dijanjikan sebuah disrupsi baru dalam bentuk pengalaman yang unik - On-chain-gaming. Dengan sifat-sifat seperti desentralisasi yang menggeser keseimbangan kekuatan dari para petahana industri game ke arah entitas kreatif, komposabilitas yang mendobrak tembok-tembok yang telah lama tertutup, dan kepemilikan sejati bagi para pemain.

Namun, cita-cita yang kuat ini tetap berada di samping karena kita belum melihatnya dalam praktik. MUD adalah upaya berani pertama untuk membuat kerangka kerja lengkap untuk game on-chain, sebuah percikan yang dapat memicu generasi game berikutnya. Ini bukanlah mimpi di siang bolong. Dalam waktu yang singkat, tim MUD bertanggung jawab atas OPcraft, sebuah game bertema Minecraft 3D yang sepenuhnya on-chain.

Pelajaran dari industri permainan tradisional

Banyak hal yang dapat dikatakan tentang obsesi untuk berinovasi, membangun segala sesuatu dari bawah ke atas, dan menciptakan makhluk yang sama sekali baru. Namun mengenai game, ada pelajaran puluhan tahun dalam pola desain dan penciptaan ceruk teknik baru yang harus ditanggapi dengan serius. Mengabaikan hal ini sama saja dengan mencoba membuat game AAA dengan teknologi Atari.

Ketika melihat tahun-tahun awal pengembangan game, kita dapat melihat kemiripan yang jelas dengan game on-chain - banyak sekali talenta dan proyek yang sangat inspiratif, tetapi juga kurangnya koordinasi dan kerangka kerja yang jelas.

Pada masa-masa awal video game, sebelum dimulainya mesin game, keyakinan dan pola desain yang mapan. Video game yang berbeda memiliki sedikit kesamaan, hingga pada titik tertentu, game yang serupa dapat memiliki basis kode yang sama sekali berbeda. Tetapi dengan diperkenalkannya mesin game, semuanya berubah.

Sulit untuk membuat perbedaan yang jelas antara mesin game dan game itu sendiri. Secara umum, game engine adalah kerangka kerja dengan seperangkat aturan dan pola desain yang dapat sedikit dimodifikasi dan diperluas untuk membuat implementasi game yang berbeda. Pada tahun 90-an, setelah bertahun-tahun pengembangan game yang terfragmentasi, sesuatu berubah, dan mesin game "berbasis genre" dan beberapa upaya untuk mengembangkan mesin tujuan umum memimpin. Game seperti Doom dan Unreal memiliki komponen inti yang dapat digunakan kembali untuk membuat berbagai macam game. Game dengan genre serupa mulai berbagi banyak implantasi logika inti mereka. Biaya dan kerumitan pengembangan game balap, pertarungan, dan penembak orang pertama menurun drastis. Hal yang mustahil menjadi mungkin, dan generasi game serta kode yang ditingkatkan telah terakumulasi di atas satu sama lain. Dari perspektif perangkat lunak, ini adalah salah satu alasan utama pengembangan game menjadi industri yang sangat besar.

Ada beberapa masalah inti yang terkait dengan game on-chain:

  1. Kurangnya kerangka kerja: Setiap tim mencoba membangun semuanya dari awal sehingga menghasilkan efisiensi yang buruk dan kurangnya pengetahuan sistemik setelah mengumpulkan pengalaman para pembangun yang menangani masalah yang sama dan mengoptimalkan solusi terbaik.
  2. Kurangnya penggunaan ulang kode: Ambil contoh banyak game on-chain yang sedang dikembangkan saat ini. Berapa banyak dari mereka yang dapat disalin dengan sukses untuk membuat game yang sedikit berbeda? Berapa banyak dari mereka yang memiliki perbedaan yang jelas antara berbagai lapisan dan komponen permainan yang memungkinkan pembuatan generasi baru dengan basis kode yang serupa? Janji untuk menciptakan proyek sumber terbuka yang paling signifikan dan saling berhubungan untuk game tampaknya masih jauh.
  3. Kurangnya kemampuan menyusun data: Ini tidak berakhir dengan penggunaan ulang kode. Ini juga tentang kemampuan game on-chain untuk memanfaatkan status blockchain bersama untuk membangun di atas satu sama lain menggunakan data game A dalam game B. Dalam praktiknya, dibutuhkan banyak pekerjaan dan sumber daya untuk menggabungkan data dan logika satu game ke dalam game lainnya.

Solusi dari MUD:

Mud adalah upaya berani pertama untuk membuat mesin dan kerangka kerja untuk game on-chain dengan menyediakan struktur untuk Maintainability, upgradability, dan moldability. Pola Entity Component System (ECS) yang dianjurkan oleh mud tidak hanya masuk akal dalam pengertian pengembangan game secara umum, tetapi lebih dari itu untuk pengembangan game on-chain.

ECS dalam kontrak pintar:

Blok bangunan paling dasar dalam MUD adalah komponen. Mereka menggunakan kontrak yang berfungsi seperti basis data yang menyimpan data tentang entitas. Sebagai contoh, mari kita ambil sebuah entitas (alamat) seperti dompet pemain. Entitas yang diwakili oleh sebuah alamat dapat memiliki properti yang berbeda, seperti nilai posisi (x,y) pada komponen posisi, level 10 pada komponen level, dan 50 pada komponen koin. Komponen hanya terdiri dari pemetaan dan konfigurasi dasar. Sistem lebih rumit dan menerapkan logika perubahan nilai dalam komponen. Anda dapat memikirkan hal ini sebagai sistem yang mengkhususkan API untuk permintaan POST pada basis data (komponen). Mereka dapat melakukannya hanya jika diberikan akses menulis ke komponen tertentu. Di sini menjadi menarik. Sistem dapat berinteraksi dengan berbagai komponen untuk membuat logika yang terperinci. Anda dapat memiliki sistem pergerakan yang menentukan pergerakan valid yang dapat dilakukan pemain (misalnya, dua langkah setiap kali), dan Anda dapat memiliki sistem hadiah yang memberi pemain koin setiap kali mereka naik level. Semuanya terdaftar di "Kontak dunia" sehingga setiap perubahan dalam data komponen diikuti oleh peristiwa yang dipancarkan. Kontrak dunia tidak memerlukan izin. Siapa pun dapat menambahkan sistem dan komponen baru. Secara teori, dunia yang berbeda dapat berinteraksi satu sama lain.

Membawa ECS ke game on-chain menghasilkan struktur yang sangat elegan, sehingga OPcraft hanya terdiri dari 10 komponen dan sekitar 15 sistem. Anda dapat melihat postingan blog yang bagus ini di MUD.dev

Kemampuan komposisi yang sesungguhnya

Sistem ECS tidak hanya masuk akal dalam pengembangan game tradisional, tetapi terlebih lagi dalam game on-chain dengan menyediakan dua fitur penting

  1. Kemampuan peningkatan game yang digunakan
  2. Tingkat komposabilitas tertinggi

Bayangkan dua jalur. Salah satunya adalah mempertahankan desain dasar. Dan yang lainnya adalah mengubah logika permainan inti.

Pikirkan tentang game strategi PVT standar di mana pemain dapat membangun pasukan untuk bertempur satu sama lain. Versi dasarnya adalah 2D, tetapi sekarang tim telah memutuskan bahwa mereka ingin membuat render 3D yang mendetail dari game ini. Yang perlu mereka lakukan adalah mengambil semua sistem yang berhubungan dengan posisi dan membuat versi yang ditingkatkan dengan koordinat (x,y,z), bukan (x,y). Semua sistem dan komponen lainnya (seperti sistem serangan, HP, dan pembangunan pasukan) dapat tetap sama. Bahkan lebih dari sekadar tim pengembang awal, komunitas dapat membuat mod game yang berbeda dengan menerapkan ulang sistem dan komponen atau bahkan berinteraksi dengan komponen yang sama dengan memberikan akses penulisan ke sistem baru (jika ini adalah game milik komunitas, berbagai model tata kelola dapat diterapkan untuk keputusan semacam ini)

Pendekatan lain akan mempertahankan komponen dan sistem yang sama tanpa memberikan akses penulisan sistem baru. Tetapi dengan komponen dan sistem tambahan untuk memperluas fungsionalitas dalam game, seperti apa bentuknya? Pertimbangkan permainan catur dasar pada rantai. Sistem gerakan dan aturan sudah diterapkan. Orang-orang dapat memainkan game ini seolah-olah mereka bermain catur di dunia nyata, tetapi mungkin tim Anda memutuskan bahwa Anda perlu membuat lapisan tambahan, lapisan sosial yang terdiri dari sistem peringkat untuk perjodohan atau kasus penggunaan lainnya. Yang perlu Anda lakukan adalah menambahkan komponen peringkat dan sistem dengan aturan peringkat. Hal ini tidak hanya menghasilkan pergeseran yang sangat mulus ke versi game baru (UX yang lebih baik), tetapi juga menciptakan sarana teknis untuk versi yang berbeda untuk hidup berdampingan atau di atas satu sama lain di tingkat kontrak pintar. Pemain dapat tetap menggunakan berbagai versi game sambil berinteraksi dengan data komponen inti yang sama, yang sangat inovatif, terlepas dari aplikasi composability. Ini menciptakan fitur keabadian keikutsertaan, menciptakan dimensi lain dari kepemilikan yang disediakan oleh game on-chain. Kepemilikan sejati dari berbagai aset game (seperti skor, NFT, pencapaian) yang dijamin dengan logika yang tidak dapat diubah yang dapat diperpanjang dengan peningkatan tambahan tetapi tidak berubah pada intinya. Ini memecahkan salah satu masalah utama game web3, yaitu kemampuan kreator untuk melakukan nerf aset tanpa persetujuan.

Perspektif keseluruhan dari sisi klien:

Perhatikan bahwa MUD adalah proyek yang sedang berjalan. Bagian berikutnya mungkin tidak mutakhir dan mengandung beberapa ketidakakuratan dan perbedaan kasar, tetapi arsitektur umum tidak diharapkan untuk diubah secara drastis.

Sejauh ini, kami telah melihat MUD di tingkat kontrak pintar. Namun masih banyak lagi. MUD menyediakan paket lengkap dengan pustaka klien dan lapisan. Ada beberapa fitur unik yang didesain untuk MUD.

  1. Komposabilitas klien
  2. Klien sepenuhnya disinkronkan dengan perubahan status blockchain (data game)
  3. PhaserX sebagai lapisan rendering

Mari kita selami detail teknis untuk membuatnya lebih konkret.

Lapisan jaringan:

Lapisan jaringan adalah lapisan dasar klien. Ini berisi konfigurasi dasar (kontrak dunia, permainan, dan konfigurasi jaringan) dan API untuk interaksi permainan. Ketika lapisan jaringan dibuat, lapisan ini memiliki spesifikasi semua komponen dan sistem yang berbeda yang dapat berinteraksi dengan klien Anda, dan Anda dapat memilih untuk berinteraksi hanya dengan komponen/sistem tertentu. Misalnya, jika Anda ingin membuat gerakan dalam game Anda dan memberikan representasi di frontend, Anda harus membuat lapisan jaringan yang disinkronkan dengan kontrak pintar komponen posisi yang digunakan dan juga dengan sistem gerakan. Sekarang Anda dapat membuat Move API yang mengambil posisi dan beberapa objek (entitas) dalam game dan mengatur posisinya atau memindahkannya dari satu tempat ke tempat lain. Setiap saat pemain akan menggunakan Move API. Mereka akan mengirimkan transaksi ke blockchain. Dalam kasus sistem pergerakan, mereka akan menjalankan fungsi dalam kontrak pintar sistem pergerakan.

Struktur ini memungkinkan game berbasis multi-klien. Setiap orang dapat membuat klien yang unik, dan semuanya sama validnya selama disinkronkan dengan blockchain dan mengikuti struktur dasar lapisan jaringan. Kami telah melihat kasus penggunaan yang sangat keren untuk game multi-klien, seperti dalam kasus hutan gelap, di mana para pemain bersaing satu sama lain tetapi menggunakan klien dan plugin yang berbeda. Struktur klien memungkinkan kami untuk melakukan implantasi lapisan jaringan dan memodifikasi API untuk mendapatkan versi klien yang berbeda dengan sangat cepat, sehingga mencapai tingkat kemampuan cetakan dan komposabilitas klien yang tinggi.

Anda mungkin bertanya bagaimana tepatnya komponen klien disinkronkan dengan komponen rantai. Ini adalah salah satu tantangan signifikan yang dihadapi para pembuat game ketika berhadapan dengan sisi klien dari game on-chain. MUD memiliki beberapa solusi untuk itu.

Pertama, MUD menempatkan fitur snapshot yang memungkinkan klien untuk melakukan sinkronisasi dengan keadaan dunia (yaitu, nilai entitas berdasarkan komponen) tanpa memproses semua peristiwa masa lalu untuk merekonstruksi keadaan, yang menghasilkan latensi rendah dan penurunan kompleksitas.

Selain itu, sistem ID MUD, di mana setiap sistem dan komponen mendapatkan id berdasarkan nama mereka, dan pada saat penyebaran, mereka akan didaftarkan di kontrak dunia, membuatnya jauh lebih mudah untuk melacak perubahan, berinteraksi dengan permainan, dan mengambil acara dengan mudah.

Lapisan rendering - kapan dan bagaimana peristiwa dirender

MUD hadir dengan PhaserX, "Mesin yang sangat skalabel yang dibangun di atas phaser", PhaserX tidak wajib. Di OPcraft, terdapat mesin voxel Noa sebagai pengganti PhaserX. Secara teori, Anda dapat menggunakan mesin apa pun yang Anda inginkan selama mesin tersebut mengikuti struktur.

Seperti yang dinyatakan sebelumnya, setiap komponen dan sistem terdaftar pada kontrak dunia, dan ketika terjadi perubahan, sebuah peristiwa akan dipancarkan (dengan data yang diidentifikasi seperti ID komponen dan ID entitas). Di sini, layanan streaming ECS dapat memberikan opsi kepada klien untuk memilih acara mana yang akan dilanggan.

Representasi grafis dari entitas dapat berupa apa pun yang Anda inginkan. Game pertarungan dapat memiliki karakter anime, ksatria, atau bahkan influencer kripto favorit Anda. Semuanya adalah versi yang valid selama mereka mewakili dan bereaksi terhadap peristiwa on-chain.

Penafian: Penafian

  1. Artikel ini dicetak ulang dari[mirror], Semua hak cipta adalah milik penulis asli[Matchbox DAO]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim " Gate Learn "), dan mereka akan segera menanganinya.
  2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
  3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.
Lancez-vous
Inscrivez-vous et obtenez un bon de
100$
!