Trang chủ » Blog » Phần cứng định hình trò chơi: Dấu vết của những giới hạn

Phần cứng định hình trò chơi: Dấu vết của những giới hạn

| Blog

Trong Resident Evil bản gốc, mỗi lần nhân vật mở một cánh cửa, màn hình chuyển sang cảnh cận cánh cửa từ từ mở ra. Mỗi cánh cửa, thang máy và cổng trong game đều kéo dài đúng bảy giây. Trong một lượt chơi bình thường, người chơi dành hơn một tiếng đồng hồ chỉ để nhìn cửa mở.

Không ai thiết kế bảy giây đó vì nó hay. Nó tồn tại vì ổ đĩa CD của PlayStation cần chừng đó thời gian để nạp căn phòng tiếp theo, và Capcom cần một thứ gì đó để người chơi nhìn trong lúc chờ. Đây là cách hiểu phổ biến trong cộng đồng, và trên bản PlayStation thì thời gian mở cửa gần như trùng khớp với thời gian nạp dữ liệu. Đến bản GameCube, thời gian nạp thực tế chỉ còn khoảng hai đến bốn giây tùy phòng, và trên bản Wii thì gần như tức thời, tức là hoạt cảnh mở cửa không còn che giấu gì nữa. Nhưng nó vẫn ở đó, vì đến lúc ấy nó đã trở thành một phần bản sắc của dòng game.

Đó là mô hình chung của cả bài viết này. Rất nhiều thứ mà người chơi hôm nay coi là ngữ pháp tự nhiên của trò chơi điện tử thực ra là những vết sẹo. Chúng là hình dạng mà một giới hạn kỹ thuật để lại sau khi bản thân giới hạn đó đã biến mất từ lâu.

Bốn loại giới hạn, bốn nhóm quy ước

Gần như mọi quy ước thiết kế game cổ điển đều truy được về một trong bốn ràng buộc vật lý.

  • Ràng buộc thứ nhất là dung lượng bộ nhớ làm việc, tức máy có thể giữ bao nhiêu dữ liệu cùng lúc. Ràng buộc này sinh ra khái niệm màn chơi rời rạc, phòng tách biệt và bản đồ chia ô.
  • Ràng buộc thứ hai là tốc độ đọc dữ liệu từ vật lưu trữ vào bộ nhớ. Ràng buộc này sinh ra màn hình loading, cùng với cả một họ thủ thuật che giấu nó như cửa mở, thang máy, hành lang hẹp và đoạn đi bộ chậm.
  • Ràng buộc thứ ba là khả năng hiển thị đồng thời, tức máy vẽ được bao nhiêu thứ lên màn hình trong một khung hình. Ràng buộc này sinh ra sprite hai chiều, bảng màu hạn chế, hiện tượng nhân vật nhấp nháy, và sau này là sương mù cùng tầm nhìn xa bị cắt cụt.
  • Ràng buộc thứ tư là khả năng ghi dữ liệu, tức máy có lưu được trạng thái sau khi tắt nguồn hay không. Ràng buộc này sinh ra mật khẩu, checkpoint, mạng chơi, và cả cấu trúc độ khó của toàn bộ thời kỳ 8 bit.

Bốn ràng buộc này là bốn cột trong bảng dưới đây. Mỗi mục tiếp theo trong bài truy nguyên một quy ước cụ thể về đúng cột của nó.

Sprite hai chiều và bản đồ chia ô

Nhân vật game những năm 1980 không phải là hình ảnh tự do vẽ lên màn hình. Chúng là những khối đồ họa mà bản thân con chip xử lý hình ảnh biết cách di chuyển độc lập với nền, và số lượng cùng kích thước của chúng bị đóng cứng trong mạch điện.

Trên NES, màn hình được ghép từ các ô 8×8 hoặc 8×16 pixel xếp theo lưới. Cách này tiết kiệm bộ nhớ nhưng hạn chế sự linh hoạt về hình ảnh. Máy định nghĩa được tối đa 64 sprite trong một khung hình, và mỗi sprite hoặc ô nền chỉ dùng được ba màu cộng với một màu trong suốt, lấy từ bảng màu cố định 64 màu.

Hai hệ quả thiết kế đi thẳng ra từ đây. Thứ nhất, nhân vật lớn phải được ghép từ nhiều sprite nhỏ. Phần cứng chỉ hỗ trợ nguyên gốc hai kích thước là 8×8 và 8×16, nên muốn có nhân vật to hơn thì phải xếp nhiều sprite cạnh nhau. Thứ hai, và quan trọng hơn về mặt thẩm mỹ, phong cách pixel art với đường viền dày và bảng màu tương phản mạnh không phải là một lựa chọn nghệ thuật. Nó là cách duy nhất để một nhân vật vẽ bằng ba màu vẫn đọc được trên màn hình CRT nhòe.

Hôm nay pixel art là một trường phái được chọn chủ động, xuất hiện trong những game chạy trên máy có thể dựng hình ba chiều thời gian thực. Giới hạn đã biến mất, phong cách thì ở lại.

phần cứng định hình trò chơi 1

Nhân vật nhấp nháy khi màn hình đông

Ai từng chơi game NES đều nhớ hiện tượng nhân vật chớp tắt khi có nhiều đối tượng cùng hàng ngang. Đây không phải lỗi băng game.

Trong lúc chuẩn bị từng dòng quét, chip xử lý hình ảnh của NES duyệt qua danh sách 64 sprite theo thứ tự, tìm tám sprite đầu tiên nằm trên dòng đó và chép thuộc tính của chúng vào một vùng nhớ nội bộ rất nhỏ. Vùng đó chỉ chứa được tám sprite, nên máy không thể hiển thị quá tám sprite trên cùng một dòng quét. Những sprite đứng sau trong danh sách đơn giản là không có chỗ để chép vào và không được vẽ. Giới hạn này nằm hoàn toàn bên trong chip xử lý hình ảnh, nên không thể lách bằng phần cứng bổ sung trên băng game.

Nhấp nháy là giải pháp mà lập trình viên nghĩ ra để biến một lỗi thành một khuyết điểm chấp nhận được. Bằng cách xoay vòng thứ tự ưu tiên của sprite qua từng khung hình, game khiến các đối tượng chớp tắt luân phiên thay vì để một số biến mất hẳn. Kết quả là người chơi vẫn nhận ra được có bao nhiêu đối tượng và chúng ở đâu.

Nhưng hệ quả thiết kế mới là điều đáng chú ý. Nguyên tắc làm game NES là tránh dồn nhiều đối tượng hoạt động vào cùng một dải ngang, phân bố chúng ra theo không gian và thời gian để giữ ngân sách sprite. Nói cách khác, cấu trúc “kẻ địch xuất hiện theo đợt nhỏ, cách nhau đều đặn” của game hành động 8 bit không phải là nhịp điệu do nhà thiết kế chọn. Đó là ngân sách phần cứng viết ra nhịp điệu đó.

phần cứng định hình trò chơi 2

Màn chơi rời rạc và phòng tách biệt

Câu hỏi vì sao game cổ điển chia thành màn 1-1, 1-2, 1-3 thay vì một thế giới liền mạch có câu trả lời rất thẳng: máy không giữ nổi cả thế giới trong bộ nhớ cùng lúc.

Ngay cả khi bước sang thời ba chiều, ràng buộc này vẫn còn. Silent Hill bản PlayStation phải hoạt động với chỉ 2 MB RAM, một bộ xử lý có năng lực tính toán số thực hạn chế, và 1 MB bộ nhớ hình ảnh dùng chung cho cả kết cấu bề mặt lẫn bộ đệm khung hình. Game chia cả thị trấn thành những khối 40 mét và chỉ giữ được bốn khối trên màn hình cùng lúc, với kết cấu bề mặt được nạp và tái sử dụng động tùy theo nhu cầu của từng khối.

Đây chính là gốc của cấu trúc phòng trong game kinh dị sinh tồn, của khái niệm khu vực trong Metroidvania, và của cả cái gọi là màn chơi trong hầu hết game hành động. Một màn chơi, xét về bản chất kỹ thuật, là một đơn vị dữ liệu vừa đủ nhét vào bộ nhớ. Vạch đích cuối màn không phải là một ý tưởng tường thuật. Nó là ranh giới của một lần nạp dữ liệu.

Màn hình loading và nghệ thuật che giấu nó

Khi vật lưu trữ chậm hơn nhu cầu của trò chơi, người ta có hai lựa chọn: bắt người chơi chờ một cách lộ liễu, hoặc bắt họ chờ mà không biết mình đang chờ.

Thế hệ băng từ thập niên 1980 chọn cách thứ nhất và không giấu giếm gì, với những màn hình sọc ngang nhảy múa kéo dài vài phút. Thời đĩa quang chọn cách thứ hai, và đây là lúc kỹ thuật che giấu trở thành ngôn ngữ thiết kế.

Cửa mở bảy giây của Resident Evil là ví dụ nổi tiếng nhất. Nhưng cùng một logic sinh ra cả một họ chi tiết mà người chơi hôm nay coi là bình thường: thang máy đi rất chậm, hành lang hẹp và dài không có gì để làm, khe đá phải lách người qua, đoạn nhân vật bám vách leo chậm rãi, và những đoạn hội thoại xảy ra đúng lúc nhân vật đang đi bộ từ khu này sang khu khác. Tất cả đều là màn hình loading đội lốt nội dung.

Điều thú vị là những chi tiết này đã tiến hóa thành công cụ thiết kế thực thụ. Một hành lang hẹp sau khi hết nhiệm vụ kỹ thuật vẫn còn nhiệm vụ nhịp điệu, tức là hạ nhịp người chơi xuống trước khi đẩy họ vào một trận đánh lớn. Đây là điểm mấu chốt giải thích vì sao các quy ước sống dai hơn nguyên nhân sinh ra chúng, và tôi sẽ quay lại ở phần sau.

phần cứng định hình trò chơi 3

Sương mù, bóng tối và tầm nhìn xa

Không có ví dụ nào sạch hơn Silent Hill.

Sương mù trong Silent Hill với Konami ban đầu không phải là mối quan tâm nghệ thuật mà là mối quan tâm kỹ thuật. Phần cứng hạn chế của PlayStation không cho phép dựng hình toàn bộ thị trấn trong lúc người chơi di chuyển, nên sương mù được nghĩ ra như một tấm màn che đi sự thật rằng game chỉ dựng hình khu vực sát quanh người chơi. Thế giới nhìn thấy được chỉ trải dài khoảng 13,5 mét tính từ máy quay. Các khối địa hình mới bắt đầu được nạp khi người chơi tiến vào trong khoảng 16 mét quanh rìa của chúng, tức game có chừng 2,5 mét để chuẩn bị trước khi chúng lọt vào tầm nhìn.

Cuối cùng thì giới phê bình và người hâm mộ ca ngợi sương mù như một thủ pháp tạo không khí, dù xuất phát điểm của nó không hơn gì một nhu cầu kỹ thuật.

Cùng thời kỳ đó, hàng loạt game khác dùng chính thủ thuật này. Bóng tối trong hầm ngầm, khói độc phủ kín đường phố, bão tuyết, đêm mưa: tất cả đều là những cái tên khác nhau cho cùng một hành động là cắt ngắn tầm nhìn để đỡ phải dựng hình. Ngày nay tầm nhìn xa không còn là vấn đề, nhưng sương mù vẫn được cố tình đưa vào game kinh dị, vì hóa ra thứ mà nó thực sự làm rất tốt là lấy đi thông tin của người chơi.

phần cứng định hình trò chơi 4

Mật khẩu, pin và checkpoint

Nhóm quy ước thứ tư đến từ một câu hỏi mà máy chơi game đời đầu không trả lời được: làm sao nhớ được người chơi đã đi tới đâu.

Các hệ máy như Atari 2600 và NES lưu game trên băng chứa chip ROM, tức bộ nhớ chỉ đọc. Ngay cả khi nhà phát triển muốn làm game phức tạp hơn game arcade đơn giản, họ cũng không có chỗ nào để ghi tiến trình. Giải pháp là mật khẩu. Game gia đình đầu tiên có hệ thống mật khẩu là Survival Island cho Atari 2600 năm 1983, và mật khẩu thực sự phổ biến trên NES vài năm sau đó, bắt đầu với Castlevania của Konami tháng 5 năm 1987, rồi Kid Icarus và Metroid của chính Nintendo.

Giải pháp thay thế tốn tiền. Những băng game có lưu tiến trình phải mang thêm một chút bộ nhớ SRAM được nuôi bằng pin cúc áo. SRAM luôn đắt, và bảng mạch lớn hơn, phức tạp hơn cũng không giúp giảm chi phí. Với những game đơn giản thì việc gắn thêm chức năng này không hợp lý về mặt kinh tế, nên trong giai đoạn đầu của NES nhiều nhà phát triển chọn mật khẩu cho cả những game phức tạp của họ.

Hệ quả thiết kế sâu hơn nhiều người tưởng. Chính khái niệm độ khó nghiệt ngã đặc trưng của game NES bắt nguồn từ việc kéo dài thời lượng chơi bằng độ khó thuần túy, bởi vì băng game không có nhiều dung lượng. Nói cách khác, cái mà người chơi hoài niệm như bản lĩnh thiết kế của thời kỳ vàng son thực ra là một cách bù đắp cho việc thiếu bộ nhớ.

phần cứng định hình trò chơi 5

Mật khẩu cũng định hình cấu trúc trò chơi theo chiều ngược lại. Nhiều game phiêu lưu đời đầu bị dẫn dắt theo đường ray khá chặt nhằm giảm số tổ hợp trạng thái cần ghi nhớ. Nếu game chia thành chương, thì chỉ những vật phẩm và cờ sự kiện liên quan tới chương đó mới cần được mã hóa vào mật khẩu. Tính tuyến tính của game thời kỳ này, ít nhất một phần, là hệ quả của độ dài chuỗi ký tự mà người chơi chịu chép tay được.

Khi máy chuyển sang đĩa quang, chữ ROM trong CD-ROM có nghĩa là không ghi được, và game lúc đó đã quá phức tạp để dùng mật khẩu, nên thẻ nhớ ra đời. Thẻ nhớ lại đẻ ra một quy ước khác nữa là việc đếm dung lượng theo ô, và cùng với nó là thói quen của cả một thế hệ người chơi phải cân nhắc xóa file nào để lưu file nào.

Checkpoint hiện đại và tính năng tự động lưu là hậu duệ trực tiếp của chuỗi này. Chúng vẫn giữ nguyên cấu trúc “trạng thái được đóng băng tại những điểm nhất định” dù không còn bất kỳ lý do kỹ thuật nào để trạng thái không được lưu liên tục.

Vì sao quy ước sống lâu hơn giới hạn

Đến đây câu hỏi thú vị không còn là các quy ước đến từ đâu, mà là vì sao chúng không chết đi khi nguyên nhân biến mất. Có ba cơ chế.

Cơ chế thứ nhất là quy ước trở thành ngữ pháp thể loại. Người chơi học cách đọc trò chơi thông qua những dấu hiệu này. Khi thấy một hành lang hẹp, họ biết sắp có chuyện. Khi thấy một điểm lưu, họ biết đoạn khó sắp tới. Bỏ quy ước đi không làm game hiện đại hơn, nó làm game khó đọc hơn.

Cơ chế thứ hai là quy ước tìm được một chức năng thứ hai. Cửa mở của Resident Evil ban đầu che thời gian nạp, nhưng nó cũng cắt đứt mạch không gian giữa hai căn phòng, tạo ra cảm giác an toàn giả và khiến người chơi không biết cái gì đang chờ ở phía bên kia. Chức năng thứ hai này vẫn còn nguyên giá trị ngay cả khi ổ SSD nạp phòng trong một phần trăm giây.

Cơ chế thứ ba là quán tính của công cụ và quy trình. Engine, công cụ dựng màn, quy trình kiểm thử, cách chia việc trong studio đều được xây quanh giả định rằng game gồm nhiều màn rời rạc có điểm bắt đầu và điểm kết thúc. Ngay cả khi phần cứng cho phép làm khác, tổ chức sản xuất vẫn kéo mọi thứ về khuôn cũ.

Ba cơ chế này giải thích một hiện tượng dễ thấy: mỗi khi một giới hạn biến mất, ngành game không lập tức vứt bỏ quy ước tương ứng mà mất khoảng một thế hệ phần cứng để quyết định xem quy ước đó còn hữu ích hay không.

Khi giới hạn thực sự biến mất

Có những quy ước đã chết hẳn, và chúng cho thấy quy luật khá rõ.

Mật khẩu chết hoàn toàn, không để lại dấu vết nào ngoài sự hoài niệm. Nó chết vì nó không có chức năng thứ hai nào cả, ngoài việc bù cho thiếu bộ nhớ.

Nhân vật nhấp nháy cũng chết hoàn toàn, vì lý do tương tự. Không ai cố tình đưa nó vào game hiện đại trừ khi đang làm sản phẩm mô phỏng thẩm mỹ retro.

Ngược lại, màn hình loading không chết mà chỉ đổi hình dạng. Kể cả khi ổ lưu trữ thể rắn khiến thời gian nạp gần như bằng không, game vẫn giữ những đoạn chuyển cảnh, đoạn đi bộ chậm và cửa cần mở, vì chúng đã trở thành công cụ điều tiết nhịp.

Màn chơi rời rạc cũng không chết mà tự tách làm hai nhánh. Một nhánh biến mất trong game thế giới mở liền mạch, nơi ranh giới nạp dữ liệu bị giấu hoàn toàn. Nhánh còn lại sống khỏe trong game di động và game nhiều lượt ngắn, nơi màn chơi rời rạc phục vụ một nhu cầu mới hoàn toàn không liên quan tới bộ nhớ, đó là phiên chơi vừa với thời gian chờ xe buýt.

Điểm này rất đáng chú ý với người làm nghề. Một quy ước sinh ra từ giới hạn A có thể sống tiếp nhờ giới hạn B hoàn toàn khác, và người thiết kế cần biết mình đang giữ nó vì lý do nào.

Những giới hạn đang tạo ra quy ước của hôm nay

Nếu quy luật trên đúng, thì ngay lúc này ngành game cũng đang sinh ra một loạt quy ước mà hai mươi năm nữa sẽ có người viết bài truy nguyên. Có thể chỉ ra vài cái khá rõ.

Giao diện dọc, nút bấm to và cơ chế chơi một tay không phải là quyết định thẩm mỹ. Đó là hình dạng mà một màn hình cầm tay và một ngón cái để lại. Cơ chế năng lượng chờ hồi trong game di động không phải là ý tưởng thiết kế, đó là hình dạng của mô hình doanh thu miễn phí kèm mua hàng trong ứng dụng. Cấu trúc mùa nội dung và battle pass là hình dạng của yêu cầu giữ chân người dùng trong game dịch vụ. Độ trễ mạng đang định hình lại thể loại nào phù hợp với chơi trên nền tảng đám mây và thể loại nào thì không.

Khi những ràng buộc này thay đổi, phần lớn các cơ chế trên sẽ hoặc biến mất hoặc tìm được chức năng thứ hai để tồn tại tiếp. Trò chơi đoán trước xem cái nào rơi vào nhóm nào là một bài tập rất tốt cho bất kỳ ai đang học thiết kế game.

Bài học cho người thiết kế

Kết luận thực tế không phải là các quy ước cũ đều lỗi thời và cần vứt bỏ. Ngược lại, nhiều quy ước sinh ra từ ràng buộc kỹ thuật lại là những công cụ thiết kế tốt nhất mà ngành có, chính vì chúng đã được thử nghiệm trên hàng triệu người chơi suốt nhiều thập kỷ.

Kết luận thực tế là mỗi khi đưa một quy ước vào sản phẩm, người thiết kế nên trả lời được ba câu hỏi. Quy ước này sinh ra để giải quyết ràng buộc nào. Ràng buộc đó còn tồn tại trong dự án của mình không. Và nếu không còn, thì quy ước này đang phục vụ chức năng gì khác đủ giá trị để giữ lại.

Đây là sự khác nhau giữa người sao chép và người thiết kế. Người sao chép đặt điểm lưu ở cuối mỗi khu vực vì game nào cũng làm thế. Người thiết kế đặt điểm lưu ở đó vì họ biết chính xác điểm lưu đang mua cho họ điều gì, và biết chỗ nào thì nên đặt khác đi.

Còn với những ai đang học lập trình game, có một hệ quả nữa. Hiểu phần cứng không phải là kiến thức phụ trợ nằm bên cạnh thiết kế. Suốt bảy mươi năm, phần cứng đã là tác giả thầm lặng của gần như mọi ý tưởng thiết kế mà chúng ta coi là kinh điển. Một người biết vì sao chỉ có tám sprite trên mỗi dòng quét sẽ hiểu nhịp điệu của game hành động sâu hơn nhiều so với một người chỉ biết rằng nhịp điệu đó tồn tại.

 

Tài liệu tham khảo

NESDev Wiki và diễn đàn NESDev, tài liệu kỹ thuật về chip xử lý hình ảnh của NES. 

Set Side B, Behind the Code: About the NES’ Sprite Capabilities. 

Kinda Technical, A Guide to NES Game Development, các mục về PPU và giảm nhấp nháy sprite. 

RetroGame Start, Why Do NES Games Flicker: A Visual Explanation. 

Tedium, Saved Game History: Battery Backups, Memory Cards, and the Cloud. 

How-To Geek, A Brief History of Video Game Saves. 

Phân tích giải mã ngược engine Silent Hill bản PlayStation, dẫn qua Gaming Latest. 

WhatCulture, 10 Genius Ways Video Games Fixed Their Own Mistakes. 

Thảo luận cộng đồng Resident Evil về thời lượng hoạt cảnh mở cửa và thời gian nạp dữ liệu trên các nền tảng khác nhau. 

Tags:

0 Lời bình

Gửi Lời bình

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

BÀI VIẾT LIÊN QUAN

BẠN MUỐN HỌC LẬP TRÌNH?

GỌI NGAY

098 953 44 58

Đăng ký tư vấn lộ trình học lập trình

Đăng ký tư vấn, định hướng lộ trình học và giải đáp các thắc mắc về ngành nghề – Miễn phí – Online.

15 + 12 =