Bagaimana permainan berbasis kartrid diprogram? [Tutup]

Saya berpikir seperti SNES, N64, Atari ... bahkan DS hari ini, saya kira.

Game SNES biasanya tidak memakan ruang lebih dari 4 MB, dan game N64 biasanya bernilai 32 hingga 64 MB.

Hari-hari ini, Anda hampir tidak bisa mengkompilasi "hello world!" program tanpa kompilasi yang dihasilkan menghasilkan 1,21 gigabyte !! data. (Di samping bercanda, file saat ini memang memakan banyak ruang dibandingkan dengan beberapa teknologi saat itu.)

Jadi bagaimana mereka melakukannya?

• Di mana mereka memprogram game-game ini? ASM? Seluruh hal dalam ASM ?!
• Bagaimana grafik dibuat? Teknologi apa yang mereka miliki untuk membuat sprite sheet dan, dalam beberapa kasus (seperti N64), model 3D?
• Bagaimana mereka cocok dengan begitu banyak level, karakter, pencarian, dan item pada kartrid ini? Maksudku, Super Mario World pada jam SNES sekitar 1 MB, dan ada 96 pintu keluar! Ocarina of Time, Banjo-Kazooie, DK64 dan beberapa game lainnya membutuhkan waktu kurang dari 64 MB dan memiliki dunia besar, banyak konten dan model 3D!

Maaf jika pertanyaan saya tampaknya sedikit di luar sana, saya hanya kagum bahwa banyak judul hebat di luar sana berhasil masuk dalam ruang penyimpanan yang begitu kecil.

Ini menarik bagi saya karena bahkan file dan game terkecil dan paling sepele berhasil mengambil setidaknya beberapa MB, jadi bayangkan tingkat besar seperti yang ada di GoldenEye 007 berhasil mengambil hampir tidak ada data sama sekali yang mengejutkan.

Ini adalah sumber daya seni dan audio yang mengambil ruang, pilihan bahasa pemrograman lebih tentang mendapatkan hasil maksimal dari perangkat keras.

Menggunakan N64 sebagai contoh, sebagian besar game pihak ke-3 adalah 8, 12, atau 16Mb. Game 32 & 64Mb sebagian besar dari Nintendo karena harganya sangat mahal untuk dikirim dengan kereta yang besar untuk orang lain. Kedengarannya kecil, tapi begitu juga aset seni dan output visual akhir. Anda harus ingat bahwa sebagian besar game N64 dirender pada 320x240 bukan 1280x760 atau lebih hari ini. Dengan resolusi keluaran sekecil itu, tekstur dan sprite jauh lebih kecil daripada sekarang.

Karena cache tekstur yang kecil pada N64, sebagian besar tekstur berukuran 32x64 piksel dengan palet 4/8 bit (alias 16/256 warna). Detail warna ekstra sering dilakukan dengan mencampur tekstur dan warna titik. Game Banjo adalah contoh yang bagus untuk ini.

Hari ini satu batu dalam permainan mesin Unreal akan memiliki beberapa 512x512x24bpp atau bahkan 32bpp. Ditambah alih-alih hanya satu tekstur difus, Anda sekarang punya peta normal, topeng specular, topeng refleksi, cubemaps refleksi dan banyak lagi. Jadi objek yang dulu memiliki tekstur 4Kb sekarang tercakup dalam beberapa MB data.

Game lama juga memiliki sejumlah besar penggunaan kembali seni. Semak-semak di Super Mario Bros adalah sprite yang sama dengan awan, bukit-bukit sama dengan jamur. Karakter yang berbeda hanyalah versi yang berubah warna dari sumber seni yang sama. Semua ini mendapat lebih banyak penggunaan dari setiap tekstur atau sprite yang ada di troli.

Audio adalah perbedaan besar lainnya untuk gim modern. Hampir semuanya di masa lalu dilakukan dengan trek berurutan. Sekarang kedua trek musik, efek suara dan suara disimpan dalam berbagai format audio terkompresi. Meskipun tentu saja lebih kecil dari data yang tidak terkompresi, mereka masih secara signifikan lebih besar dari padanan yang diurutkan.

Adapun SEN (dan SNES kebanyakan), inilah gambaran dasar. Saya tidak menulis game NES tetapi menulis emulator NES (Graybox) dan melakukan cukup banyak rekayasa ulang kereta lama.

Adapun bahasa pemrograman: ya, itu semua perakitan. Memprogram NES berarti bekerja secara langsung dengan interupsi perangkat keras, port DMA, transfer bank, dll. Untungnya, pemrograman 6502 (atau lebih tepatnya, 2A03) cukup mudah [1]:

• ada beberapa register: A, X dan Y terutama, dua yang terakhir hanya dapat digunakan untuk pengindeksan dan iterasi
• set instruksi kecil dan kebanyakan langsung
• tidak banyak memori: RAM utama adalah 2KB, dengan ekstensi 8KB yang didukung baterai opsional. Dari 2KB itu, 256 byte dicadangkan untuk stack dan halaman 0 (256 byte pertama) adalah tempat Anda ingin menyimpan pointer dan nilai yang paling sering digunakan karena beberapa mode pengalamatan khusus

3 hal ini bersama-sama membuat lingkungan yang cukup mudah untuk dihafal saat bekerja dengannya. Ya, Anda mengelola semua memori sendiri, tetapi itu pada dasarnya berarti Anda membuat peta lengkap tentang di mana semuanya berjalan di depan dan peta itu tidak terlalu besar karena Anda hanya perlu khawatir tentang 2K, sehingga Anda dapat merencanakannya pada selembar kertas grafik. Anda harus merencanakan beberapa hal lebih banyak dan secara statis menetapkan variabel dan konstanta untuk lokasi RAM dan ROM (pada kartrid).

Itu menjadi sedikit lebih rumit setelah data kartrij Anda melampaui batas yang dapat dialamatkan dari CPU. Itu 64KB, di mana 32KB lebih rendah diatur dalam batu dan dipetakan ke semua jenis port perangkat keras dan RAM. Di sinilah bank-switching berperan, yang berarti memetakan bagian ROM ke dalam (bagian dari) ruang alamat 32KB yang lebih tinggi.

Ini dapat digunakan sesuai keinginan programmer, tetapi contoh penggunaannya mungkin memiliki permainan dengan 3 level, dengan semua data level, data meta dan kode untuk setiap level dijejalkan ke area memori 8KB yang terpisah pada cartridge. Level tersebut mungkin memiliki callback untuk misalnya inisialisasi, per pembaruan frame, dll. "Memuat" level tersebut akan berarti memetakan 8KB potongan memori pada misalnya 0xC000. Anda kemudian dapat menentukan bahwa rutin init selalu pada 0xC000, rutin pembaruan bingkai pada 0xC200 dan data level dimulai pada 0xC800. Kode utama gim ini bertempat di memori yang lain kemudian mengontrol perubahan level hanya dengan menukar bagian yang benar dan melompat ke alamat absolut 0xC000 dan 0xC200 pada waktu yang tepat.

Wrt data grafis: data ubin NES adalah 2-bit peta 8x8 piksel. Untuk latar belakang mereka dikombinasikan dengan layer 2-bit resolusi 1/4. Nilai-nilai 4-bit ini kemudian diindeks ke dalam palet 16 entri, dengan saya percaya 53 warna unik yang efektif tersedia. Sprite juga menggunakan data piksel 2-bit dan masing-masing sprite menentukan indeks grup 2-bitnya sendiri membentuk indeks sahabat 4-bit. Gambar BG di layar adalah array 32x30 nomor indeks ubin.

Pada dasarnya, dengan memiliki banyak pengulangan dan indeks ke dalam indeks, Anda dapat menyimpan data sangat kecil. Data level sering disimpan sebagai bilah vertikal indeks ubin dan karena bilah vertikal itu juga digunakan kembali, maka indeks itu juga diindeks dan hanya disimpan satu kali pada kartrid. Teknik kompresi data sederhana bekerja dengan cara yang sama. Ini memungkinkan Mario 1 menjadi 32KB data (dengan ruang yang tersisa) dan 8KB data bitmap.

Adapun lingkungan dev, saya telah melihat beberapa foto di mana orang bekerja pada beberapa komputer kuno yang dapat disertifikasi terhubung ke pembakar EEPROM untuk bekerja. Debugging yang dibantu alat tidak benar-benar kemungkinan sampai setelah usia SNES [2]. Ini adalah alasan utama begitu banyak game lama memiliki bug "jelas" di dalamnya dan mengapa hal-hal seperti Gameshark dapat melakukan apa yang mereka lakukan; kesehatan pemain akan selalu berada di mem-lokasi X, sehingga Anda dapat memaksanya menjadi 100 setiap saat.

Jika Anda menemukan hal-hal ini menarik, saya anjurkan Anda untuk melihat misalnya http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Ada beberapa kursus pemrograman agar NES dapat ditemukan online juga.

Saya harap ikhtisar yang disederhanakan ini memberikan beberapa wawasan tentang pengembangan game era 80-an.

[1] Secara relatif. Juga saya bias ketika saya menulis Graybox sendiri di sekitar 85% perakitan PowerPC. [2] Lihat pembuatan artikel FF6: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/

Ada banyak sub-topik di hampir semua pertanyaan yang Anda ajukan. Optimalisasi adalah bidang besar untuk dirinya sendiri dan ada banyak hal untuk dijelajahi.

Jika Anda tertarik pada optimasi semacam ini, salah satu hal yang mungkin Anda jelajahi adalah demoscene . Demoscene, dan beberapa budaya seni yang terkait, telah lama mempertahankan rasa ingin tahu tentang mencoba membuat seni yang rumit untuk komputer yang membutuhkan ruang sesedikit mungkin. Banyak dari mereka akan memiliki informasi tentang bagaimana mereka melakukan beberapa atau semua "trik" mereka.

Seringkali ada campuran akal sehat berseni, meskipun ada "trik" dan "retasan" khusus untuk permainan atau genre. Seringkali ada sedikit "keberuntungan" yang terlibat, dan sebuah tim mengetahui batas-batas yang mereka usahakan (mungkin terus-menerus membenturkan kepala dengan batasan-batasan itu selama proses berlangsung), mengetahui pertukaran yang tersedia, dan bersedia melakukan beberapa perdagangan yang diperlukan -off dan pengorbanan untuk memenuhi batas mereka.

Berikut adalah beberapa hal yang dapat saya pikirkan yang dapat membantu tim mendapatkan permainan ke ukuran yang lebih kecil:

• Reuse What You Can: menggunakan kembali sprite yang sama, dan variasi yang Anda dapat dengan mudah membuat dari gambar sprite tunggal (seperti refleksi, rotasi, pergeseran palet) akan menghemat ruang Anda. Hal yang sama berlaku untuk kode, musik, dan hampir semua hal lain dalam game.
• Kompres Apa yang Anda Bisa: ada sejumlah skema kompresi di luar sana, dan mengetahui yang mana yang dapat digunakan bisa menghemat ruang yang sangat besar. Bahkan kadang-kadang skema kompresi sederhana seperti pengkodean run-length dapat membuat perbedaan yang mengejutkan. Tidak hanya itu, tetapi ada skema kompresi (dan format alternatif yang tidak persis kompresi) untuk masing-masing jenis file, seringkali dengan trade-off berkualitas. Sebagai contoh, file audio wave / CD dapat dikompres, dengan sedikit kehilangan informasi, ke dalam file MP3. Juga, format file seperti MIDI dan MOD berbasis sampler adalah format alternatif yang memakan banyak ruang lebih sedikit, tetapi menyandikan musik sepenuhnya berbeda dan memerlukan keterampilan yang berbeda untuk membuatnya terdengar bagus.
• Kalah Apa Yang Tidak Anda Butuhkan: dapatkah Anda melakukannya dengan lebih murah? Misalnya, apakah Anda masih bisa mendapatkan "kepribadian" karakter dalam piksel lebih sedikit (atau poligon)? Apakah penempatan ubin harus ditentukan secara tepat oleh seorang desainer atau dapatkah itu dibuat secara acak dalam kode program Anda?
• Kode Sering Lebih Murah: meskipun Anda membuat lelucon tentang seberapa banyak ruang yang biasanya dikompilasi oleh sebuah kode sekarang (dan ada alasan mengapa 'platform' ini meningkat selama bertahun-tahun, dan cara untuk mengecilkannya ketika Anda benar-benar perlu), tetapi secara umum jika Anda dapat melakukan sesuatu secara algoritmik / prosedural / dalam-kode dengan mudah, pendekatan itu juga akan lebih mudah untuk mengubah dan menggunakan kembali untuk aset lain yang serupa tetapi berbeda. Fraktal adalah contoh yang sangat mudah dilihat: Anda dapat memiliki gambar fraktal rumit yang membutuhkan banyak ruang dengan perbandingan rumus matematika yang menghasilkannya. Rumus matematika, tambahan, mungkin memiliki parameter yang dapat menghasilkan gambar yang mirip, tetapi terkadang mengejutkan berbeda.

Ngomong-ngomong, untuk sekumpulan pertanyaan yang begitu besar, semoga beberapa topik di atas akan menjadi titik awal yang baik bagi Anda untuk belajar lebih banyak.

Satu hal adalah saya tidak yakin apakah itu masih berdiri di era pasca N64 tetapi SNES dan N64 sering menggunakan kembali tekstur pada objek 3D lainnya yang sering menghemat ruang yang cukup besar dan membuat seni yang latar belakangnya sering palsu. Trik lain adalah membuat border background kabut yang akan digunakan.

San Francisco Rush N64 selalu memiliki beberapa kabut meskipun pengaturan dapat mengubah kepadatan di mana arcade San Francisco Rush tidak memilikinya dan Anda dapat melihat Jembatan Golden Gate di Track 1 dibandingkan dengan versi N64.

Juga permainan sering menggunakan kembali musik seperti Zelda Ocarina of Time menggunakan kembali banyak musik yang menurut saya menjengkelkan karena mungkin telah dilakukan pekerjaan yang lebih baik seperti bagaimana Banjo Kazooie / DK64 sering memiliki tema dalam tema!

Zelda Ocarina waktu bisa memiliki Hyrule Overworld dan kemudian versi bawah laut dari tema jika Anda pergi di bawah air atau membuat instrumen dalam Tema Toko mencerminkan area luar di mana seruling dan biola akan digunakan untuk toko Hutan Kokiri dan tanduk dan terompet untuk toko Hyrule Castle Town dan drum di desa Goron.etc

Dalam modul 3D PC dikompilasi ke perpustakaan untuk dengan cepat mengaksesnya menggunakan program untuk membongkarnya tetapi saya tidak yakin apakah itu yang terjadi dengan Nintendo yang berbasis ROM. PC adalah RAM seperti pergi ke ruang berantakan di mana hal-hal tidak selalu tetap di mana seharusnya dan informasi dapat ditimpa ke titik komputer bahkan tidak akan mulai!

Game Consoles adalah ROM di mana semuanya disimpan dalam ruang yang disediakan sehingga setiap kali Anda menghidupkan game itu akan mencari file di ruang yang diberikan dengan jaminan itu akan tetap ada.