penyimpanan / pemuatan status game?


12

apa metode atau algoritma yang paling sering digunakan untuk menyimpan status permainan (profil), database file teks bagaimana enkripsi berjalan dan hal-hal terkait.

Saya telah melihat Caesar IV menggunakan mySQL.

ada saran.

Jawaban:


20

Saya cukup yakin ini paling sering dilakukan dalam format (biner) berpemilik, hanya menulis setiap variabel dari status permainan apa pun yang Anda gunakan ke dalam file, atau membaca file itu kembali ke instance dari struct. Dalam C ++ misalnya, Anda dapat memperlakukan objek seperti array byte dan hanya fwrite () ke dalam file, atau fread () dari file dan melemparkannya kembali ke bentuk objeknya.

Jika Anda menggunakan Java atau bahasa lain, Anda dapat memilih untuk menggunakan serialisasi untuk membuat tugasnya sangat mudah. Penjelasan Java ada di bagian bawah jawaban ini; bahasa lain (level lebih tinggi dari C ++) pasti memiliki pustaka serialisasi sendiri atau fungsi bawaan, yang harus Anda pilih untuk digunakan. Tidak peduli seberapa tidak efisiennya rutinisasi serialisasi, ruang hard drive saat ini murah, terutama ketika keadaan gim seharusnya tidak terlalu besar sama sekali, dan itu mencegah Anda dari menulis dan mempertahankan rutinitas serialisasi Anda sendiri.

Anda benar-benar tidak boleh menggunakan MySQL (cukup baca kalimat pertama dari ulasan ini ). Jika Anda benar-benar membutuhkan database relasional untuk beberapa alasan, gunakan SQLite ; ini adalah sistem basis data yang ringan dan ada dalam satu file basis data. Tetapi untuk sebagian besar gim, basis data relasional bukanlah jalan yang harus ditempuh, dan perusahaan yang mencoba menggunakannya biasanya akhirnya menggunakannya sebagai tabel pencarian nilai-kunci daripada basis data relasional yang sebenarnya.

Setiap jenis enkripsi file disk lokal hanya kebingungan ; peretas apa pun hanya akan mengendus data setelah program Anda mendekripsi. Saya pribadi menentang hal semacam itu, TERUTAMA dengan satu pemain permainan. Pandangan saya adalah bahwa pemilik permainan (pelanggan yang membayar, ingatlah Anda) harus diizinkan untuk meretas permainan jika mereka mau. Dalam beberapa kasus ini dapat menciptakan rasa komunitas yang lebih besar, dan "mod" dapat dikembangkan untuk game Anda yang mendorong lebih banyak pelanggan kepada Anda. Contoh terbaru yang terlintas dalam pikiran adalah Portal in Minecraft mod yang baru-baru ini dirilis. Ini diterbitkan di situs berita gamer di seluruh internet, dan Anda dapat bertaruh itu meningkatkan penjualan Minecraft.


Jika karena alasan tertentu Anda sebenarnya cukup gila untuk menggunakan Java untuk pengembangan game seperti saya, berikut ini penjelasan singkat tentang serialisasi di Jawa:

Simpan semua data status permainan Anda dalam satu kelas, buat kelas menjadi serial dengan menerapkan Serializable, gunakan transientkata kunci jika Anda mencampur variabel instantiated khusus ke dalam kelas (objek sementara tidak serial), dan cukup gunakan ObjectOutputStreamuntuk menulis ke file dan ObjectInputStreammembaca dari file . Itu dia.


2
Hehe, The Witcher tidak mengenkripsi data mereka. Sangat mudah untuk membuka file save game dalam hex editor, sedikit berantakan dan dapatkan semua kartu cewek telanjang ... oh Tuhan, aku minta maaf!
Anthony

Saya telah menggunakan serialisasi .NET biner untuk menyimpan game, dan C # mungkin platform yang sedikit lebih masuk akal daripada Java untuk mengembangkan game. Saya suka bagaimana secara otomatis menyimpan seluruh objek grafik secara otomatis. Ini dulunya jauh lebih sulit. Tentu saja sekarang ada tantangan untuk mengecualikan potongan yang tidak perlu seperti tekstur, tapi itu bukan masalah besar untuk dicapai.
BlueMonkMN

Saya tidak setuju bahwa C # sedikit lebih populer daripada Java untuk mengembangkan game. Lebih masuk akal menyiratkan beberapa subjektivitas, dan sebagai pengembang XNA dan Java, saya lebih suka Java. Jangan ragu untuk mendaftar instruksi tentang serialisasi dalam C # juga jika Anda mau, saya belum pernah melakukannya tetapi saya dapat mengeditnya menjadi jawaban saya. Serialisasi Java memang menyimpan seluruh grafik objek dan kata kunci 'sementara' pada variabel mengecualikan potongan yang tidak perlu seperti tekstur; setiap anggota non-transien harus Serializable atau Anda dapat menulis metode writeObject khusus untuk menyiasatinya.
Ricket

Acar Python akan menyimpan seluruh grafik objek untuk Anda juga dan sangat mudah digunakan. Ketika tiba saatnya deserialize, Anda akan diberikan kembali benda-benda yang terhidrasi sepenuhnya, semudah pie: docs.python.org/library/pickle.html
drhayes

Saat menggunakan formatter biner bawaan, mengecualikan bidang-bidang tertentu dari serialisasi dalam C # /. NET semudah menghiasi mereka dengan atribut [NonSerialized]. Apa yang mudah untuk diabaikan, bagaimanapun, adalah bahwa peristiwa yang dihasilkan kompiler (yaitu setiap peristiwa tanpa operator tambah / hapus kustom) membuat bidang dukungan untuk menyimpan pelanggan mereka. Dengan demikian, mudah untuk secara tidak sengaja (dan tanpa sadar) memasukkan event handler dalam grafik objek berseri. Untuk menyiasatinya, Anda perlu menambahkan atribut NonSerialized ke deklarasi acara, tetapi Anda perlu menambahkan kualifikasi "bidang:":[field: NonSerialized]
Mike Strobel

3

Jika Anda menulis kode sendiri, katakan dalam C ++, Anda dapat menggunakan file biner. File biner memberi Anda bentuk enkripsi melalui kebingungan. Tetapi seperti yang didokumentasikan di seluruh internet, itu adalah bentuk keamanan yang sangat lemah.

ATAU, Anda dapat menggunakan sesuatu seperti RapidXML jika Anda menginginkan solusi yang dapat dibaca manusia.

Jika Anda menggunakan semacam kerangka kerja, lihatlah fungsi dukungan file itu. HTH


0

Sebagian besar permainan yang saya lihat hanya menggunakan kode tulisan tangan untuk membaca / menulis dari file biner. Seringkali, format pada disk akan menjadi replika yang tepat dari tata letak memori suatu objek sehingga pemuatan hanya:

  1. Baca file ke dalam memori.
  2. Keluarkan pointer ke buffer ke tipe objek.

Ini cepat, tapi itu tugas untuk mempertahankan, spesifik platform, dan tidak fleksibel.

Akhir-akhir ini, saya telah melihat beberapa game menggunakan SQLite. Orang yang saya ajak bicara sepertinya menyukainya.


0

Serialisasi disebutkan dalam beberapa jawaban lain, dan saya setuju itu adalah solusi yang masuk akal. Salah satu cara gagal adalah dalam versi.

Katakanlah Anda merilis game dan orang-orang memainkannya dan membuat beberapa save game. Kemudian di tambalan nanti Anda ingin memperbaiki bug atau menambahkan beberapa fitur. Jika Anda menggunakan metode serialisasi biner sederhana dan Anda menambahkan anggota ke kelas Anda, serialisasi Anda mungkin tidak kompatibel dengan save game lama ketika pelanggan memasang patch Anda.

Jadi, apa pun pendekatan yang Anda gunakan, pastikan Anda memikirkan masalah ini sebelum Anda merilis game pertama kalinya! Pelanggan tidak akan senang jika mereka harus memulai dari awal setelah menerapkan tambalan.

Salah satu cara untuk menghindari ini adalah dengan meminta setiap tipe data dasar menerapkan metode Simpan (versi) dan Muat (versi) yang cukup pintar untuk mengetahui data apa yang akan disimpan dan dimuat untuk setiap versi gim. Dengan begitu Anda dapat mendukung kompatibilitas mundur game save Anda dan gagal dengan anggun jika pengguna mencoba memuat save game dari versi game yang lebih baru daripada yang mereka jalankan.


1
Sebagai catatan singkat: menerapkan fungsi "simpan" dan "muat" untuk setiap versi game dengan cepat berubah menjadi mimpi buruk pemeliharaan. Saya menemukan solusi yang lebih baik adalah dengan menyematkan nomor versi, menulis fungsi "simpan / muat" untuk versi gim saat ini, dan tulis fungsi "konversi" dari versi tidak terbaru ke versi saat ini. Maka simpan saja semua fungsi konversi Anda. Mencoba memuat permainan versi lama sepuluh akan menjalankan sepuluh fungsi konversi secara seri, lalu fungsi asli "memuat versi game saat ini".
ZorbaTHut

Jauh lebih mudah untuk mempertahankan jangka panjang - menyimpan serangkaian fungsi "muat setiap file game sebelumnya" dengan cepat berubah menjadi operasi waktu polinomial.
ZorbaTHut

Dalam gim yang saya garap ternyata tidak serumit itu - alih-alih menyimpan banyak salinan metode memuat / menyimpan, satu metode tunggal menggunakan nomor versi untuk menentukan byte mana yang harus dibaca dan ditulis. Ini menjadi lebih mudah jika Anda tidak hanya menulis struktur, tetapi menerapkan pemuatan dan penyimpanan sebagai operasi pada tingkat tipe data primitif (mis. ReadByte / ReadFload / dll). Kemudian jika Anda menambahkan anggota baru Anda dapat melakukan sesuatu seperti if (versi> 10) {someNewByte = ReadByte (); } Menerapkannya dengan cara ini juga membuat mendukung platform endian yang berbeda menjadi lebih mudah.
kevin42

Cara lain untuk menghindari peningkatan dukungan versi adalah dengan menghindari metode serialisasi / deserialisasi objek Anda menulis / membaca nilai individual langsung dari stream. Sebagai gantinya, objek bisa menulis data miliknya ke dalam tas properti menggunakan pasangan kunci / nilai, dan kemudian menulis tas ke aliran. Selama deserialisasi, objek dapat membaca nilai dari tas dengan nama. Tetapi alih-alih menyarankan pemeriksaan nomor versi khusus seperti yang disarankan kevin42, Anda bisa saja memiliki aturan untuk bagaimana menangani nilai yang hilang (yaitu menggunakan nilai standar standar ketika nilai yang diperlukan tidak ada dalam kantong).
Mike Strobel

0

Jika Anda dapat menggunakan format yang sama dengan yang Anda gunakan untuk menyimpan level Anda, itu adalah bonus.

Misalnya, permainan seperti Peggle mungkin memiliki tata letak papan awal, jumlah bola, skor saat ini (0 untuk papan awal), dll. Kemudian permainan yang disimpan dapat menggunakan format yang persis sama.

Jika Anda menggunakan format yang sama maka save game dan level load dapat membagikan kode yang memudahkan pekerjaan Anda!

Untuk game dengan file peta yang sangat besar, save game dapat menyertakan file peta dengan referensi. File level awal mungkin melakukan hal yang sama, bahkan, yang membuat kembali ke peta itu lebih mudah juga jika karena alasan tertentu cerita memiliki karakter kembali ke tempat yang sama, kecuali beberapa NPC mati dan ada mayat tergeletak semua lebih.

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.