Các trò chơi dựa trên hộp mực được lập trình như thế nào? [đóng cửa]

Tôi nghĩ giống như SNES, N64, Atari ... ngay cả DS ngày nay, tôi cho rằng.

Các trò chơi SNES thường không chiếm quá 4 MB dung lượng và các trò chơi N64 thường có giá trị dữ liệu từ 32 đến 64 MB.

Ngày nay, bạn hầu như không thể biên dịch một "thế giới xin chào!" chương trình không có phần tổng hợp kết quả tạo ra 1,21 gigabyte !! Dữ liệu. (Đùa sang một bên, các tập tin ngày nay chiếm hàng tấn không gian so với một số công nghệ hồi đó.)

Vì vậy, làm thế nào họ làm điều đó?

• Họ đã lập trình những trò chơi này trong cái gì? HỎI? Toàn bộ điều trong ASM?!
• Đồ họa được tạo ra như thế nào? Họ đã có công nghệ gì để tạo ra các tấm sprite và, trong một số trường hợp (như N64), các mô hình 3D?
• Làm thế nào mà chúng phù hợp với nhiều cấp độ, nhân vật, nhiệm vụ và vật phẩm trên các hộp mực này? Ý tôi là, Super Mario World trên đồng hồ SNES trong khoảng 1 MB và nó có 96 lối thoát! Ocarina of Time, Banjo-Kazooie, DK64 và một vài trò chơi khác chiếm ít hơn 64 MB và có thế giới rộng lớn, hàng tấn nội dung và mô hình 3D!

Xin lỗi nếu câu hỏi của tôi có vẻ hơi ngoài kia, tôi chỉ ngạc nhiên khi có rất nhiều tựa game hay ngoài kia được quản lý để phù hợp với một không gian lưu trữ nhỏ như vậy.

Điều đó thật hấp dẫn đối với tôi bởi vì ngay cả những tập tin và trò chơi nhỏ nhất và tầm thường nhất cũng chiếm ít nhất vài MB, vì vậy hãy tưởng tượng rằng các mức độ lớn như GoldenEye 007 đã xoay sở để không mất dữ liệu.

Đó là tài nguyên nghệ thuật và âm thanh chiếm không gian, lựa chọn ngôn ngữ lập trình liên quan nhiều hơn đến việc tận dụng tối đa phần cứng.

Sử dụng N64 làm ví dụ, hầu hết các trò chơi của bên thứ 3 là 8, 12 hoặc 16Mb. Các trò chơi 32 & 64Mb hầu hết là của Nintendo vì nó quá đắt để vận chuyển những chiếc xe đẩy lớn cho những người khác. Nghe có vẻ nhỏ bé, nhưng sau đó là tài sản nghệ thuật và đầu ra hình ảnh cuối cùng. Bạn phải nhớ rằng hầu hết các trò chơi N64 được hiển thị ở 320x240 không phải là 1280x760 trở lên ngày nay. Với độ phân giải đầu ra nhỏ như vậy, kết cấu và họa tiết nhỏ hơn nhiều so với ngày nay.

Do bộ đệm kết cấu nhỏ trên N64, hầu hết các kết cấu là 32x64 pixel với bảng màu 4/8 bit (còn gọi là 16/256 màu). Chi tiết màu bổ sung thường được thực hiện bằng cách trộn họa tiết và màu đỉnh. Các trò chơi Banjo là một ví dụ tốt về điều này.

Ngày nay, một tảng đá duy nhất trong một trò chơi động cơ Unreal sẽ có nhiều 512x512x24bpp hoặc thậm chí 32bpp. Ngoài ra, thay vì chỉ là một kết cấu khuếch tán duy nhất, giờ đây bạn đã có bản đồ bình thường, mặt nạ gương, mặt nạ phản chiếu, hình khối phản chiếu và hơn thế nữa. Vì vậy, một đối tượng từng có kết cấu 4Kb hiện được bao phủ trong một vài MB dữ liệu.

Các trò chơi cũ cũng có một lượng lớn sử dụng lại nghệ thuật. Những bụi cây trong Super Mario Bros. là những nhánh cây giống như những đám mây, những ngọn đồi giống như những cây nấm. Các nhân vật khác nhau chỉ là phiên bản thay đổi màu sắc của cùng một tài nguyên nghệ thuật. Tất cả điều này được sử dụng nhiều hơn từ mỗi kết cấu hoặc sprite trên giỏ hàng.

Âm thanh là một sự khác biệt lớn cho các trò chơi hiện đại. Gần như mọi thứ trong những ngày xưa đã được thực hiện với các bài hát được giải trình tự. Bây giờ cả hai bản nhạc, hiệu ứng âm thanh và âm thanh được lưu trữ ở các định dạng âm thanh nén khác nhau. Mặc dù chắc chắn nhỏ hơn dữ liệu không nén, chúng vẫn lớn hơn đáng kể so với dữ liệu tương đương theo trình tự của chúng.

Đối với NES (và SNES cũng vậy), đây là một tổng quan cơ bản. Tôi đã không viết bất kỳ trò chơi NES nào nhưng đã viết một trình giả lập NES (Graybox) và đã thực hiện một số lượng khá lớn các kỹ thuật tái tạo xe đẩy cũ.

Đối với ngôn ngữ lập trình: có, tất cả là lắp ráp. Lập trình NES có nghĩa là làm việc trực tiếp với các ngắt phần cứng, cổng DMA, chuyển đổi ngân hàng, v.v ... May mắn thay, lập trình 6502 (hay đúng hơn là 2A03) khá dễ dàng [1]:

• Có một vài thanh ghi: A, X và Y là chủ yếu, hai cái sau chỉ có thể sử dụng để lập chỉ mục và lặp
• bộ hướng dẫn là nhỏ và chủ yếu là đơn giản
• không có nhiều bộ nhớ: RAM chính là 2KB, với phần mở rộng 8KB được hỗ trợ bằng pin. Trong số 2KB đó, 256 byte được dành riêng cho ngăn xếp và trang 0 (256 byte đầu tiên) là nơi bạn muốn lưu trữ các con trỏ và giá trị được sử dụng nhiều nhất của mình do một số chế độ địa chỉ đặc biệt

Cả 3 điều này tạo nên một môi trường đủ dễ để ghi nhớ trong khi làm việc với nó. Có, bạn tự mình quản lý tất cả bộ nhớ nhưng điều đó có nghĩa là về cơ bản là bạn tạo một bản đồ đầy đủ về nơi mọi thứ đi lên phía trước và bản đồ đó không lớn lắm vì bạn chỉ phải lo lắng về 2K, vì vậy bạn có thể vẽ ra một mảnh biểu đồ. Bạn phải lập kế hoạch cho mọi thứ nhiều hơn một chút và gán tĩnh các biến và hằng cho các vị trí RAM và ROM (trên hộp mực).

Nó có một chút khó khăn hơn khi dữ liệu hộp mực của bạn vượt quá giới hạn địa chỉ của CPU. Đó là 64KB, trong đó 32KB thấp hơn được đặt trong đá và được ánh xạ tới tất cả các loại cổng phần cứng và RAM. Đây là lúc chuyển đổi ngân hàng phát huy tác dụng, có nghĩa là ánh xạ một phần của ROM vào (một phần) không gian địa chỉ 32KB cao hơn.

Điều này có thể được sử dụng theo cách mà lập trình viên muốn, nhưng một ví dụ sử dụng có thể có một trò chơi với 3 cấp độ, với tất cả dữ liệu cấp độ, dữ liệu meta và mã cho mỗi cấp độ được nhồi nhét vào các vùng nhớ 8KB riêng biệt trên hộp mực. Cấp độ có thể có các cuộc gọi lại, ví dụ như khởi tạo, cập nhật mỗi khung hình, v.v. "Đang tải" cấp độ có nghĩa là ánh xạ khối 8KB của bộ nhớ ở mức 0xC000. Sau đó, bạn có thể chỉ định rằng thường trình init luôn ở mức 0xC000, thói quen cập nhật khung là 0xC200 và dữ liệu mức bắt đầu từ 0xC800. Mã chính của trò chơi nằm trong một đoạn bộ nhớ khác, sau đó kiểm soát các thay đổi cấp độ chỉ bằng cách hoán đổi ở đoạn bên phải và nhảy đến địa chỉ tuyệt đối 0xC000 và 0xC200 vào những thời điểm thích hợp.

Dữ liệu đồ họa Wrt: dữ liệu gạch của NES là bản đồ pixel 8 bit 8 bit. Đối với nền, chúng được kết hợp với lớp 2 bit độ phân giải 1/4. Các giá trị 4 bit này sau đó được lập chỉ mục vào bảng màu 16 mục, với tôi tin rằng 53 màu độc đáo hiệu quả có sẵn. Sprites cũng sử dụng dữ liệu pixel 2 bit và mỗi sprite chỉ định lại chỉ số nhóm 2 bit của chính nó tạo thành chỉ số pal 4 bit. Hình ảnh BG trên màn hình là một mảng 32x30 của số chỉ mục ô.

Về cơ bản, bằng cách có rất nhiều sự lặp lại và lập chỉ mục thành các chỉ mục, bạn có thể giữ dữ liệu rất nhỏ. Dữ liệu mức thường được lưu trữ dưới dạng các thanh dọc của các chỉ mục gạch và vì các thanh dọc đó cũng được sử dụng lại, chúng cũng được lập chỉ mục và chỉ được lưu trữ một lần trên hộp mực. Kỹ thuật nén dữ liệu đơn giản hoạt động tương tự. Điều này cho phép Mario 1 có được 32KB dữ liệu (có chỗ trống) và 8KB dữ liệu bitmap.

Đối với môi trường nhà phát triển, tôi đã thấy một số hình ảnh nơi mọi người làm việc trên một số máy tính cổ xưa chắc chắn được nối với các ổ ghi EEPROM để làm việc. Gỡ lỗi được hỗ trợ bởi công cụ không thực sự là một khả năng cho đến sau tuổi SNES [2]. Đây là lý do chính khiến rất nhiều game cũ có lỗi "rõ ràng" trong đó và tại sao những thứ như Gameshark có thể làm những gì họ làm; sức khỏe người chơi sẽ luôn ở vị trí mem-X, vì vậy bạn có thể buộc nó là 100 mọi lúc.

Nếu bạn thấy những điều này thú vị, tôi khuyến khích bạn xem ví dụ: http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Có khá nhiều khóa học lập trình cho NES được tìm thấy trực tuyến.

Tôi hy vọng tổng quan đơn giản này đã cung cấp một số cái nhìn sâu sắc về phát triển trò chơi từ những năm 80.

[1] Nói một cách tương đối. Ngoài ra, tôi thiên vị khi tôi tự viết Graybox trong khoảng 85% PowerPC. [2] Xem việc tạo ra bài viết FF6: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/

Có rất nhiều chủ đề phụ trong hầu hết tất cả các câu hỏi bạn đang hỏi. Tối ưu hóa là một lĩnh vực rất lớn đối với chính nó và có rất nhiều điều để khám phá.

Nếu bạn quan tâm đến loại tối ưu hóa này, một trong những điều bạn có thể khám phá là demoscene . Demoscene, và một số nền văn hóa nghệ thuật liên quan của nó, từ lâu vẫn giữ được cảm giác tuyệt vời về việc cố gắng tạo ra nghệ thuật phức tạp cho các máy tính chiếm ít không gian nhất có thể. Nhiều người trong số họ sẽ có thông tin về cách họ đã thực hiện một số hoặc tất cả các "thủ thuật" của họ.

Thường có một sự pha trộn nghệ thuật của ý nghĩa thông thường, mặc dù có "thủ thuật" và "hack" cụ thể cho một trò chơi hoặc thể loại. Thường có một chút "may mắn" liên quan và một nhóm biết các giới hạn mà họ đang làm việc (có lẽ liên tục tàn phá những giới hạn đó trong suốt quá trình), biết được sự đánh đổi có sẵn của họ và sẵn sàng thực hiện một số giao dịch cần thiết -offs và hy sinh để đáp ứng giới hạn của họ.

Dưới đây là một số điều mà tôi có thể nghĩ ra có thể giúp một đội có được một trò chơi với kích thước nhỏ hơn:

• Tái sử dụng những gì bạn có thể: sử dụng lại các họa tiết tương tự và các biến thể mà bạn có thể dễ dàng thực hiện từ một hình ảnh sprite duy nhất (như phản xạ, xoay, dịch chuyển bảng màu) sẽ giúp bạn tiết kiệm không gian. Điều tương tự cũng xảy ra với mã, âm nhạc và gần như mọi thứ khác trong một trò chơi.
• Nén những gì bạn có thể: có một số phương án nén ngoài kia, và biết những cách nào để sử dụng có thể là một khoản tiết kiệm không gian rất lớn. Thậm chí đôi khi các lược đồ nén đơn giản như mã hóa độ dài chạy có thể tạo ra sự khác biệt đáng ngạc nhiên. Không chỉ vậy, còn có các lược đồ nén (và các định dạng thay thế không nén chính xác) cho các loại tệp riêng lẻ, thường có sự đánh đổi chất lượng. Ví dụ, các tệp âm thanh wave / CD có thể được nén, với một số mất thông tin bên lề, thành các tệp MP3. Ngoài ra, các định dạng tệp như MIDI và MOD dựa trên bộ lấy mẫu là các định dạng thay thế chiếm ít không gian hơn, nhưng mã hóa nhạc hoàn toàn khác nhau và yêu cầu các kỹ năng khác nhau để làm cho chúng nghe hay.
• Mất những gì bạn không cần: bạn có thể làm nó rẻ hơn không? Chẳng hạn, bạn vẫn có thể nhận được "tính cách" của một nhân vật trong ít pixel hơn (hoặc đa giác)? Là vị trí của gạch cần phải được xác định chính xác bởi một nhà thiết kế hoặc chúng có thể được tạo ngẫu nhiên trong mã chương trình của bạn không?
• Mã thường rẻ hơn: mặc dù bạn đã nói đùa về việc biên dịch mã thường chiếm bao nhiêu dung lượng (và có nhiều lý do tại sao 'nền tảng' này đã tăng lên trong nhiều năm qua và cách thu nhỏ nó khi bạn thực sự cần), nhưng nói chung nếu bạn có thể thực hiện một cách dễ dàng về mặt thuật toán / thủ tục / mã, cách tiếp cận đó cũng sẽ dễ dàng điều chỉnh hơn và sử dụng lại cho các tài sản tương tự nhưng có cảm giác khác nhau. Fractals là một ví dụ đặc biệt dễ thấy: bạn có thể có một hình ảnh của một mảnh nhỏ phức tạp chiếm nhiều không gian so với công thức toán học tạo ra nó. Ngoài ra, công thức toán học có thể có các tham số có thể tạo ra các hình ảnh trông giống nhau, nhưng đôi khi đáng ngạc nhiên.

Dù sao, đối với một bộ câu hỏi lớn, đầy tải như vậy, hy vọng một số chủ đề ở trên sẽ là điểm khởi đầu tốt để bạn tìm hiểu thêm.

Một điều là tôi không chắc liệu nó có còn tồn tại trong kỷ nguyên N64 hay không, nhưng SNES và N64 thường sử dụng lại họa tiết trên các vật thể 3D khác, thường tiết kiệm không gian đáng kể và nghệ thuật kết xuất trước mà nền thường là giả. Một mẹo khác là tạo sương mù nền biên giới sẽ được sử dụng.

San Francisco Rush N64 luôn có một chút sương mù mặc dù các cài đặt có thể thay đổi mật độ trong đó arcade San Francisco Rush không có và bạn có thể thấy Cầu Cổng Vàng trên Đường 1 so với phiên bản N64.

Ngoài ra, các trò chơi thường sử dụng lại âm nhạc như Zelda Ocarina of Time sử dụng lại âm nhạc rất nhiều, điều mà tôi cảm thấy khó chịu vì có thể đã làm một công việc tốt hơn như cách Banjo Kazooie / DK64 thường có chủ đề trong các chủ đề!

Zelda Ocarina của thời gian có thể có Hyrule Overworld và sau đó là phiên bản dưới nước của chủ đề nếu bạn đi dưới nước hoặc tạo ra các nhạc cụ trong Chủ đề Cửa hàng phản ánh khu vực bên ngoài nơi sáo và câu đố sẽ được sử dụng cho cửa hàng Rừng Kokiri và sừng và kèn cho cửa hàng Hyrule Castle Town và trống trong làng Goron.etc

Trong các mô-đun 3D của PC được biên dịch vào các thư viện để nhanh chóng truy cập chúng bằng chương trình để giải nén nó nhưng tôi không chắc đó có phải là trường hợp của Nintendo dựa trên ROM không. PC là RAM giống như đi vào một căn phòng bừa bộn, trong đó mọi thứ không phải lúc nào cũng ở nơi chúng được cho là và thông tin có thể được ghi đè đến mức máy tính thậm chí sẽ không bắt đầu!

Máy chơi game là ROM nơi mọi thứ được lưu trữ trong một không gian được phân bổ, vì vậy mỗi khi bạn bật trò chơi, nó sẽ tìm các tệp trong không gian được phân bổ đó với sự đảm bảo rằng nó sẽ vẫn ở đó.