Các nhà phát triển NES thảo luận về quy trình tạo ra những trò chơi cổ điển định hình một thế hệ

Hệ thống Giải trí Nintendo, và phiên bản Famicom của nó ở Nhật Bản, không cần giới thiệu – nếu bạn đang đọc tạp chí này, bạn sẽ biết rằng phần cứng 8-bit đã đưa Nintendo lên vị thế dẫn đầu toàn cầu trong lĩnh vực trò chơi điện tử, và đã là nơi diễn ra các phiên bản đầu tiên của vô số loạt trò chơi cổ điển. 

Mặc dù việc tiếp thị đã đóng vai trò quan trọng trong thành công thương mại và văn hóa này, nhưng điều đó không thể xảy ra nếu thiếu phần cứng. Sau tất cả, ColecoVision và Atari 5200 mới chỉ hơn một năm tuổi khi Famicom ra mắt tại Nhật Bản vào năm 1983, và 3DO và Atari Jaguar đã có mặt trên thị trường vào thời điểm các nhà phát triển cuối cùng từ bỏ NES vào năm 1994. Một máy không thể duy trì tính cập nhật trong thời gian dài như vậy nếu thiếu phần cứng đủ linh hoạt và đủ có khả năng để theo kịp sở thích thay đổi của game thủ.

Đất mới

Nhưng NES không chỉ là một hiện tượng của thời đại của nó – rất nhiều nhà phát triển đều đang tạo ra những trò chơi mới cho phần cứng này, đẩy nó mạnh mẽ hơn bao giờ hết với các công cụ phát triển hiện đại. Hai CPU và các dẫn xuất của chúng đã chiếm ưu thế trên thị trường phần cứng gia đình của thập niên 80 – Zilog Z80, như đã thấy trong ZX Spectrum, ColecoVision và Master System, và MOS Technology 6502, được sử dụng trong Atari 5200, Apple II và Commodore 64. Kỹ sư của Nintendo, Masayuki Uemura, đã chọn 6502 cho NES, chủ yếu vì nó nhỏ đủ để một chip cũng có thể bao gồm khả năng phát âm thanh.

Vào năm 2016, kỹ sư đã qua đời này cho Retro Gamer biết rằng sự lựa chọn này đã gây 'vấn đề lớn trong công ty' khi trò chơi arcade nổi tiếng Donkey Kong của Nintendo đã sử dụng Z80 và mã nguồn không thể tái sử dụng. Việc xem xét cho bất kỳ nhà lập trình ngoài Nintendo nào cũng không phải là ưu tiên, vì công ty ban đầu không có ý định để nhà xuất bản bên thứ ba trở thành một phần của mô hình kinh doanh của mình. Tất nhiên, thành công của phần cứng ở Nhật Bản và Bắc Mỹ cuối cùng đã đòi hỏi phát triển của bên thứ ba chỉ để đáp ứng nhu cầu về trò chơi mới. 

Hệ thống không tạo ra cùng một tác động tại Vương quốc Anh, đó là lý do tại sao nhà lập trình Paul Machacek không gặp một chiếc cho đến năm 1988, khi anh gia nhập Rare – một trong số ít nhà phát triển ở Vương quốc Anh tập trung vào hệ thống của Nintendo. Các trò chơi đã được công bố trước đó của anh đã được viết cho các máy tính dựa trên Z80, và anh được giao nhiệm vụ ban đầu là viết cho bo mạch trò chơi RAZZ dựa trên Z80, nhưng sau đó anh sớm được yêu cầu làm việc trên một dự án NES. May mắn thay, Paul quen thuộc với mã lắp ráp 6502 từ thời gian sở hữu Oric-1 của mình. 'Tôi nhanh chóng nắm bắt lại được,' anh nói, 'nhưng quên hết về tất cả việc tính toán số mà bạn làm trên nó so với Z80 vì 6502 chỉ có một số lượng ít register, nhưng lại có bộ nhớ trang 0 nhanh chóng.' 

Môi trường phát triển mà Paul làm việc với khá cơ bản. 'Ban đầu tại Rare, mọi người đều sử dụng PDS (Hệ thống Phát triển của Lập trình viên) là một trình soạn thảo văn bản và bộ lập trình. Chúng tôi có các thẻ giao diện tự làm được cắm vào khe cắm cartridge trên NES, và chúng được kết nối bằng dây nối đến các máy tính cá nhân chạy PDS,' anh giải thích. 'Chúng tôi không có mạng. Các máy tính là Amstrad với ổ cứng 20MB (không phải là lỗi gõ) Mỗi khi bạn lập trình mã của mình – tất cả đều được thực hiện trong một lần, chúng tôi chưa có liên kết viên – toàn bộ mã nhị phân sẽ được sao chép qua dây nối đến thẻ giao diện và bạn sẽ chạy mã của mình trên máy mục tiêu. Còn về tài liệu, chúng tôi chỉ có tài liệu NES tiêu chuẩn, có một số lỗi chính tả cần được sửa chữa nếu không sẽ gặp sự cố, và cũng có hướng dẫn sử dụng tập lệnh 6502 tiện ích cho việc tham khảo định kỳ, đặc biệt là nếu bạn muốn viết mã tự sửa đổi.'

Nếu bạn là một nhà lập trình cảm thấy đau đớn với điều đó, nó còn tồi tệ hơn. 'Không có công cụ gỡ lỗi như bạn biết ngày nay,' Paul tiếp tục. 'Có những mẹo để tìm hiểu xem mã của bạn đã đến đâu trước khi mọi thứ gặp sự cố, như việc viết các giá trị vào một vị trí bộ nhớ và xem cái nào được viết cuối cùng trước khi nó gặp sự cố, sau đó sử dụng tìm kiếm nửa đoạn để thu hẹp về mã đang gây sự cố. Đối với việc kiểm tra hiệu suất, bạn thường có một số thay đổi trực quan trên màn hình (di chuyển thanh cuộn màn hình ngang, hoặc thay đổi bảng màu) ở đầu của một chức năng, và sau đó đặt lại nó ở cuối để bạn có thể 'đo lường' thời gian mà nó hiển thị trên màn hình bằng cách vẽ dấu với bút đánh dấu xung quanh chỉ báo hiển thị này, và xem xem các dấu có càng gần nhau hơn khi bạn tiếp tục tối ưu mã của mình. Vâng, các bạn, đó là những ngày mà bạn đo lường hiệu suất mã bằng inch!' 

Nghe có vẻ là một cách làm khá khó khăn, nhưng Paul chỉ nhìn nhận nó như là một sản phẩm của hoàn cảnh vào thời điểm đó. 'Chúng tôi đã làm những gì chúng tôi phải làm vào ngày xưa. Mọi người, hãy quay lại 35 năm trước, phát triển những gì chúng ta đã làm với các công cụ mà chúng ta có trên các hệ thống mà chúng ta đã sử dụng và nói cho tôi bạn sẽ không kết thúc bằng cách làm một điều tương tự!' May mắn thay, tình hình này sẽ dần được cải thiện cho Paul và đồng nghiệp của anh. 'Sau vài năm, Rare đã thuê Jon Ritman, một người bạn thân thiết, để viết một hệ thống mới được gọi là GLAM [Global Language Assembler Monitor] để thay thế PDS. GLAM có thể nhắm mục tiêu vào nhiều loại bộ xử lý hơn và có một trình liên kết cũng như bộ lập trình để bạn không cần phải lắp ráp toàn bộ mã của mình mỗi lần bạn thay đổi bất kỳ điều gì, điều này làm tăng tốc quá trình phát triển. GLAM hoạt động rất tốt.'

Cuối cùng, lập trình 6502 không phải là vấn đề lớn đối với Paul khi chuyển sang một nền tảng mới. 'Đối với tôi, điều điều chỉnh lớn hơn là từ máy tính cá nhân với màn hình bit-map, sang hệ thống được ánh xạ ký tự của NES, với các chỉ định bảng màu riêng biệt, các ngân hàng ký tự (và việc tráo đổi) và việc tráo đổi ngân hàng bộ nhớ trên các đĩa cart,' anh nhớ lại. Vi xử lý Hình ảnh của Nintendo – PPU viết tắt là – được thiết kế tùy chỉnh bởi Ricoh, và theo Nicolas Bétoux của Morphcat Games, 'So với phần cứng khác của thời điểm đó, khả năng đồ họa và cuộn màn hình của nó rất tuyệt vời.' 

Thật vậy, khi Famicom ra mắt vào năm 1983, đối thủ gần nhất của nó tại Nhật Bản là SG-1000 của Sega. Khả năng đồ họa của Famicom rõ ràng là vượt trội hơn – nó có một bảng màu hơn 50 màu so với chỉ 16 trên hệ thống của Sega, các sprite có thể có ba màu mỗi cái so với chỉ một màu, và màn hình có thể được cuộn theo từng pixel chứ không phải là từng ký tự, dẫn đến một diện mạo mượt mà đáng kể. Phần cứng của Nintendo cũng có thể hiển thị nhiều sprite hơn tổng cộng, và nhiều sprite hơn mỗi dòng quét. Sega giới thiệu phần cứng Mark III có đồ họa vượt trội hơn vào năm 1985, điều này có nghĩa là sự cạnh tranh diễn ra trên một cơ sở công bằng hơn khi NES và Master System đến với khán giả quốc tế. 

Công cụ của nghề

Trong khi phần cứng 8-bit của Nintendo có khả năng đồ họa tiên tiến, những phương pháp được sử dụng để tạo ra những đồ họa đó hoàn toàn không tiên tiến. Giống như Paul, nghệ sĩ Kevin Bayliss chưa bao giờ gặp một NES trước khi tạo ra trò chơi cho hệ thống này. 'Trong ngày đầu tiên ở Rare, Tim [Stamper] đã chỉ cho tôi quá trình 'pixelation' cơ bản và dạy tôi cách tạo ra công việc thực sự có thể được đưa vào trò chơi,' anh nói. 

'Tôi phải vẽ tác phẩm của mình và đặt nó dưới một tờ lưới trên một tấm bảng vẽ lớn đầy với các dải fluorescent. Sau đó, tôi sẽ vẽ lại bức tranh của mình bằng cách sử dụng lưới để xác định pixel bằng bút chì, và sau đó tôi sẽ sử dụng bút cảm ứng để điền vào các pixel. Sau đó, công việc phải được tổ chức và chia thành các ô (sprites 8x8) và dữ liệu sprite và dữ liệu vị trí phải được tính toán trong hệ thập lục phân, trong đầu của tôi. Điều này khá dễ dàng nhưng đôi khi hơi mệt mỏi, và bạn thường không muốn làm công việc này vì nó hoàn toàn không sáng tạo. Bạn chỉ muốn thấy công việc của mình trong trò chơi.' 

Nếu bạn bối rối vì không có máy tính trong quá trình đó, bạn không hiểu lầm gì cả. 'Không có công cụ nào ngoài bút, bút chì, giấy và dao phẫu thuật để viết ra những lỗi của bạn,' Kevin làm sáng tỏ. 'Có một trình chỉnh sửa sprite đơn giản mà Mark Betteridge viết nhưng điều này thực sự không được sử dụng vì nó rất hạn chế và không cho phép bạn xem hoạt ảnh của mình (như trong tất cả các cảnh quay 'hậu trường' cũ của Disney – bằng cách lật trang giấy của bạn đi lại để tạo ra ấn tượng của hoạt ảnh).' 

Vì các công cụ phát triển NES không được tiêu chuẩn hóa, một loạt các công cụ nghệ thuật khác nhau đã được sử dụng bởi các công ty khác nhau. Nintendo đã sử dụng sprite vẽ bằng tay ở một thời điểm nào đó, nhưng cuối cùng đã tạo ra một công cụ nghệ thuật pixel được điều khiển bằng chuột, trong khi Namco có một công cụ chỉnh sửa sprite có tính năng xem trước hoạt ảnh như Kevin mô tả. Tuy nhiên, anh ấy thích phương pháp kỹ thuật thấp được sử dụng tại Rare.

'Thực sự là khá tốt khi có một bảng màu hạn chế. Tôi muốn nói, không có cách nào bạn có thể vẽ tất cả đồ họa của mình trên giấy cho bất kỳ máy console 16-bit nào vì bạn sẽ không có đủ bút, và sẽ mất cả ngày để giải mã – và bạn sẽ mắc rất nhiều lỗi – điều đó sẽ là không thể,' anh nói. 'Nhưng do sự đơn giản của bảng màu và độ phân giải thấp và số lượng sprite nhỏ mà chúng tôi thường xử lý, việc tạo đồ họa trên giấy thực sự khá vui và cảm giác tự nhiên hơn nhiều so với việc tạo chúng kỹ thuật số trên SNES, vì vậy tôi đoán là có điều gì đó đáng nói về điều đó.' 

Bất kể cách một nhà phát triển tạo nghệ thuật cho NES như thế nào, các hạn chế kỹ thuật đều đóng vai trò của họ trong kết quả cuối cùng. 'Sprite trên mỗi dòng (hơn 64 pixel được điền vào một dòng quét ngang) là một vấn đề nên bạn sẽ cố gắng không làm cho các nhân vật rất rộng,' Kevin giải thích. 'Ví dụ, cụ thể tôi nhớ tất cả các nhân vật cho các trò chơi WWF tôi đã làm phải 'rơi về sau' hoặc 'nằm trên mặt đất' và tất nhiên điều đó có nghĩa là họ sẽ khá rộng khi ở tư thế đó. Vì vậy, bạn thường cố gắng góc họ hoặc thông minh với tư thế, nhưng bạn thực sự không bao giờ tránh khỏi nó. Bạn có thể thấy các nhân vật thường nhấp nháy lên và tắt đi đặc biệt là trong các trò chơi đấm bốc như vậy, và đó là một vấn đề mà tất cả các công ty đã phải đối mặt với cách tốt nhất có thể.' 

Điều nhấn mạnh đó thực sự là một biện pháp làm việc thông minh – NES đơn giản là bỏ qua các pixel nếu quá nhiều sprite được hiển thị, vì vậy việc lập tức chuyển sprite lên và tắt chúng ít nhất đảm bảo chúng sẽ được hiển thị dưới một dạng nào đó.

Trên thực tế, các nhà phát triển NES thường phải sáng tạo để thực hiện những tầm nhìn của họ – như những nhân vật boss khổng lồ mà Kevin vẽ cho Cobra Triangle. 'Với Cobra Triangle chúng tôi may mắn vì trò chơi diễn ra trong một môi trường isometric, vì vậy tất cả các đồ họa được xem từ một góc độ giảm bớt phần rộng mà bạn thường thấy trong một trò chơi cuộn ngang,' anh nói. 

'Các nhân vật boss đều là một tập hợp các sprite lớn và chúng tôi có thể sử dụng bề mặt của nước để làm cho mọi thứ trở nên ngập nước bằng cách thêm một số sprite 'sóng' xung quanh chúng ở phần đáy. Vì vậy, ví dụ nhân vật quái vật biển (Nessie) mà tôi tạo ra khá cao, và những cái gò sau lưng của cô ta di chuyển độc lập, và vì góc độ, không có nhiều hiện tượng nhấp nháy sprite.'

Các hạn chế trở nên khó khăn hơn khi phát triển các trò chơi được cấp phép, như thường xuyên làm tại Rare. 'Đối với các trò chơi đấu vật WWF, chúng tôi phải đảm bảo có một nét tương đồng tốt với các nhân vật. Vì vậy, việc 'số hóa' các bức ảnh bằng tay và tái tạo đặc điểm của mọi người một cách chính xác khi bạn chỉ có khoảng 16x16 pixel cho một bức ảnh chân dung của nhân vật trên trang chọn,' Kevin nói. 'Tôi nhớ nhận được những bức fax chất lượng tồi với hình ảnh của các đô vật và tôi phải cố gắng tái tạo chúng bằng độ phân giải thấp và ba màu.'

Điều này đã dẫn đến một số trải nghiệm hài hước, tuy nhiên. 'Rất nhiều lúc tôi nhận lại các fax từ Mỹ nói rằng, 'Các đồ họa cần được chú ý thêm,' vì sự tương đồng không đủ gần gũi,' Kevin tiếp tục. 'Sau đó, tôi sẽ thay đổi, như, một pixel và sau đó tôi sẽ nhận lại một fax vào ngày hôm sau nói rằng hình ảnh tốt hơn nhiều. Điều đó thực sự khiến tôi cười khi điều đó xảy ra. Ngoài ra, khi tôi làm việc trên trò chơi Beetlejuice, tôi gặp vấn đề ngược lại, và nghệ thuật trang tiêu đề của tôi trông quá giống Michael Keaton rõ ràng, vì vậy tôi đã phải làm lại nó để trông giống hơn với Beetlejuice – hơi khó khăn khi họ là cùng một người.'

Bóng giữa

Đôi khi, có thể đẩy hệ thống vượt ra ngoài giới hạn lý thuyết của nó. 'Nếu bạn nhìn vào Super Off Road, bạn sẽ nhận ra có nhiều màu trên màn hình vào một số thời điểm hơn là phần cứng có thể xử lý được theo tiêu chuẩn,' nói Paul. 'Có bốn bảng màu với bốn màu mỗi bảng, nhưng màu đầu tiên trong mỗi bảng màu đều là màu nền giống nhau cho tất cả. Vì vậy, tổng số màu bạn có thể hiển thị cho các nhân vật nền là 13. Có nhiều màu hiển thị trên Super Off Road vì tôi đã thay đổi các bảng màu với việc truy cập VRAM vào thời gian trống ngang ngang. Điều này đã hoạt động tốt,' Paul giải thích, trước khi sửa lại. 'Thực ra, điều này đã hoạt động trên phiên bản NES của Mỹ.

Khi trò chơi hoàn thành, tôi được thông báo rằng nó sẽ được phát hành tại Nhật trên Famicom, một chút khác biệt về phần cứng và không may mà chuyển màu của tôi sẽ không hoạt động trên đó, vì vậy tôi tin rằng nó không được phát hành ở đó.' Âm thanh được xử lý bởi cùng một vi chip Ricoh 2A03 chứa CPU. 'Trên NES, bạn có bốn kênh âm thanh để làm việc. Chúng tôi không tính kênh DPCM (mẫu), chúng tôi không sử dụng nó vì nó có một số nhược điểm,' nói Nicolas, một nhà phát triển các trò chơi NES hiện đại.

'Dù sao, đó là hai bộ phát sóng hình vuông, một sóng tam giác thường được sử dụng cho các dòng bass và một kênh tiếng ồn được sử dụng cho các âm thanh như nhịp nhàng. Vì vậy, bạn thấy, có các lựa chọn hạn chế cho polyphony và timbre, điều này làm cho việc tạo ra một bản nhạc nền hơi khó khăn hơn mà bạn có thể nghe trong các trò chơi hiện đại. Có lẽ, đó là một lý do tại sao nhiều bản nhạc nền trò chơi từng bước vào ngày xưa bù đắp cho nó bằng các bản nhạc sáng tạo và giai điệu bắt tai.'

Âm thanh của NES có một số đặc điểm đặc biệt, không ít nhất là các sóng tam giác được bước dọc thang thay vì mượt mà, do việc xử lý âm thanh 4 bit của hệ thống. 'Do số lượng kênh có hạn, bạn cũng phải nhớ rằng hiệu ứng âm thanh có thể làm gián đoạn nhạc,' Nicolas thêm. 'Lý tưởng, bạn sẽ cho hiệu ứng âm thanh chỉ phát trên các kênh bạn sử dụng cho dàn nhạc đệm, để chúng sẽ không làm im lặng giai điệu.'

Âm thanh cũng là một trong những điểm khác biệt giữa Famicom và NES, vì Famicom hỗ trợ âm thanh mở rộng qua cổng cartridge – điều mà Hệ thống đĩa Famicom và một số chip cartridge đặc biệt tận dụng. Vì NES không có khả năng này, các phiên bản Nhật Bản của các trò chơi như The Legend Of Zelda và Castlevania III: Dracula's Curse có âm nhạc tốt hơn rõ ràng so với các phiên bản quốc tế của chúng. Thực sự, là các chip đặc biệt là một trong những yếu tố quan trọng trong sự mãi mãi của NES. Ngoài việc hỗ trợ cả ROM và RAM trên PCB cartridge, NES có thể sử dụng các chip mà Nintendo gọi là Bộ Điều Khiển Quản Lý Bộ Nhớ. 

Ngoài việc cho phép chuyển đổi ngân hàng vượt qua các giới hạn lưu trữ của cấu hình cartridge ban đầu, những chip này còn có thể cung cấp các tính năng phụ trợ để hỗ trợ trong việc phát triển trò chơi, và đối với Famicom thậm chí là âm thanh mở rộng. Đó cuối cùng là cách hệ thống có thể chuyển từ việc đón tiếp các trò chơi như Donkey Kong đến các tựa game phức tạp hơn nhiều như Kirby's Adventure qua một thập kỷ. Tất nhiên, ngay cả khi dung lượng ROM vượt xa tổng dung lượng ban đầu là 40KB, các nhà phát triển thường chiến đấu vì mỗi byte. 'Một vấn đề phổ biến trong những ngày đó là cố gắng chèn các trò chơi của bạn vào các cartridge nhỏ mà chúng tôi đã được cho,' Paul nói. 'Điều này phức tạp trên NES/Game Boy (cả hai hệ thống 8 bit với bản đồ bộ nhớ 64KB) bởi việc phải có chuyển ngân hàng nơi khu vực có thể được chia thành bốn khối 16KB, và bạn có thể chuyển các ngân hàng ROM khác nhau vào và ra khỏi chúng. 

Vì vậy, bạn phải sắp xếp cẩn thận mã và dữ liệu ở đâu và cách bạn sẽ chuyển từ một ngân hàng ROM sang ngân hàng khác trong cùng một không gian địa chỉ, sử dụng bảng nhảy overlay tiêu chuẩn ở đầu không gian. Chúng tôi cũng phải phát triển các qui trình nén dữ liệu, thường là các qui trình khác nhau cho các loại dữ liệu khác nhau - dữ liệu ký tự, dữ liệu bản đồ, dữ liệu văn bản, dữ liệu âm nhạc. Nén Huffman được sử dụng khá nhiều, nhưng tôi đã dành thời gian để nhìn chằm chằm vào các bản in của các loại dữ liệu khác nhau, tìm kiếm các mẫu mà tôi có thể sử dụng để phát triển phần mềm nén.'

8-bit

James cũng đầy khen ngợi cho phần mềm, nói rằng, 'Cộng đồng tuyệt vời và các nguồn lực để sử dụng các ứng dụng theo dõi âm nhạc có thể truy cập được bởi bất kỳ ai, dù bạn là một nhà soạn nhạc kinh nghiệm hoặc chỉ là một người hâm mộ của chiptunes.' Với những công cụ hiện đại này trong tay, các nhà phát triển NES ngày nay thường thử nghiệm những dự án rất tham vọng. Trò chơi hành động bốn người chơi là điều hiếm trên NES, nhưng Morphcat Games đã tạo ra một trò chơi xuất sắc trong Micro Mages. Điều này yêu cầu sử dụng phần cứng rất tiết kiệm. 

'NES cho phép tối đa 64 sprite phần cứng có thể hiển thị trên màn hình vào bất kỳ thời điểm nào,' Nicolas bắt đầu. 'Các sprite này có kích thước 8x8 pixel (có một chế độ 8x16, nhưng nó có nhược điểm của nó) và có thể ghép lại để tạo ra các sprite lớn hơn. 'Vì vậy, để có một sprite 16x16 trong chế độ đầu tiên, bạn sẽ phải sử dụng bốn sprite phần cứng. Nếu cả bốn người chơi đều sử dụng các sprite 16x16, đó là một phần tư của tất cả các sprite phần cứng có sẵn được sử dụng cho người chơi! Ngoài ra, có một hạn chế phần cứng là nếu có nhiều hơn tám sprite trên cùng một dòng ngang, chúng sẽ bắt đầu biến mất,' ông tiếp tục. 'Để khắc phục điều này và vẫn cho phép nhiều đối tượng và hiệu ứng đồ họa khác trên màn hình, các nhân vật người chơi trong Micro Mages sử dụng một sprite 8x8 duy nhất mỗi người.' 

CPU 8 bit cũng chứng tỏ là một yếu tố hạn chế, theo Nicolas. 'Nếu một trò chơi có một kẻ thù chỉ di chuyển ngang và quay ngược lại khi gặp tường, đó là một số lượng kiểm tra có hạn cần được thực hiện. Người chơi con người, ngược lại, là các thẻ bài hoang dã, họ sẽ tương tác với mọi thứ xung quanh một cách mà một nhà phát triển không thể hoàn toàn dự đoán được. 

Ngoài ra, nếu người chơi có khả năng bắn, số lượng đối tượng trên màn hình sẽ tăng nhanh chóng,' anh nói với chúng tôi. 'Điều này không phải là vấn đề lớn trong trò chơi một người chơi và bạn thường có thể thoát khỏi tình huống trong trò chơi hai người chơi. Tuy nhiên, trong trò chơi bốn người chơi? Ôi chết. Trong Micro Mages, chúng tôi đã dành rất nhiều thời gian cho việc tối ưu hóa để tránh trễ. Tuy nhiên, trong chế độ bốn người chơi, có những trường hợp trò chơi vẫn chậm lại khi có quá nhiều điều xảy ra.' 

Một ưu điểm mà các nhà phát triển hiện đại có là khả năng lựa chọn từ một loạt các giải pháp quản lý bộ nhớ - hiện nay thường được biết đến là các mapper. 'Chúng thật sự thú vị để khám phá và phát triển,' James nói. Mặc dù có sẵn những mapper mạnh nhất, chúng không phải lúc nào cũng là sự lựa chọn mặc định. 'Khi một trò chơi được lên kế hoạch phát triển tại Mega Cat, chúng tôi bắt đầu làm việc ngược lại từ những gì cần thiết để lõi gameplay trở nên thú vị,' James giải thích. 'Trong một số trường hợp, chúng tôi kết thúc mặc định cho một cái gì đó mạnh mẽ như mapper MMC3. Trong những trường hợp khác, chúng tôi có thể giữ nó đơn giản và sử dụng một mapper riêng biệt, như NROM.' Thực tế, trò chơi NES gần đây Blazing Rangers từ nhà phát triển Nhật Bản Karu_gamo đã sử dụng mapper đơn giản nhất, NROM, để gợi lại kỷ niệm cho những ngày đầu của Famicom. Đó thực sự là lõi của sự mê hoặc với NES từ phía các nhà phát triển - nó không chỉ là một hệ thống kỹ thuật thú vị, mà còn là một hệ thống có sức hấp dẫn mãnh liệt.'

Ngay cả những người gặp gỡ nó lần đầu tiên trong ngữ cảnh công việc, như Kevin, cũng cảm thấy kỷ niệm. 'Tôi thích làm việc trên NES như một nghệ sĩ, bởi vì cuối cùng bạn thật sự hiểu biết về hệ thống. Cho dù bạn đang tạo nền, các sprite được hoạt hình, trang chính hoặc đồ họa nền (bảng điểm) - bạn đã có một hệ thống đã được sử dụng trong một trò chơi trước đó và đôi khi bạn đưa ra một số điều mới để đẩy nó một chút xa hơn và nén ra nhiều hơn từ đó một cách trực quan. Thời đại đơn giản, nhưng vui vẻ!'

Mặc dù Paul than phiền về việc lập trình cho 6502 nhưng anh cũng nhớ lại hệ thống một cách ấm áp. 'Tôi thích việc lập trình NES, nó hoàn toàn khác biệt so với kiến trúc máy tính cá nhân mà tôi đã làm việc trước đó, có những thủ thuật thú vị mà bạn có thể chơi với màn hình được ánh xạ theo ký tự mà bạn có thể khai thác để tạo ra chiều sâu - hãy kiểm tra các trò chơi Battletoads của chúng tôi trên NES/Game Boy - và tôi coi tất cả như là một thách thức kỹ thuật thú vị để 'giải quyết' các vấn đề mới xung quanh kiến trúc phần cứng thay thế này.' 

Tương lai của quá khứ

Nhưng đối với tất cả niềm vui của việc lập trình hệ thống, Paul hoàn toàn đúng khi chỉ ra kết quả của công việc đó là lý do thành công của NES. 'Không thể quên rằng Nintendo có một bộ sưu tập trò chơi tuyệt vời trên các hệ thống, đặc biệt là Super Mario và Zelda. Super Mario Bros 3 là một bước tiến lớn, và một đỉnh cao tuyệt đối vào thời điểm đó,' anh nói. 

Nếu bạn là một nhà phát triển trò chơi cổ điển, NES có thể là nền tảng lý tưởng cho bạn. 'Mã nguồn, đồ họa và âm thanh của NES dễ quản lý bởi mỗi người trong nhóm,' Nicolas nói. 'So với bây giờ, ngôn ngữ lập trình cảm thấy phức tạp và khó hiểu hơn so với các ngôn ngữ hiện đại. Tất cả những hạn chế đều đẩy bạn phải dành nhiều thời gian hơn cho mọi thứ,' anh ấy thừa nhận. 'Nhưng nó cũng buộc bạn phải suy nghĩ hai lần về mỗi ý tưởng. Cuối cùng, bạn có thể tập trung vào những ý tưởng quan trọng nhất cho gameplay.'

Những hạn chế này có thể giữ phạm vi của trò chơi của bạn trong kiểm soát - chỉ có một phạm vi có thể làm được.' Nếu bạn cảm thấy hấp dẫn với ý tưởng về việc đối mặt với thách thức kỹ thuật đó, hãy cho chúng tôi thấy kết quả một ngày nào đó - chúng tôi luôn quan tâm đến việc nhìn thấy chúng. 

Tính năng này ban đầu xuất hiện trong Tạp chí Retro Gamer. Để biết thêm các tính năng và cuộc phỏng vấn tuyệt vời, bạn có thể đăng ký Retro Gamer in ấn hoặc kỹ thuật số tại đây.