Năm 1970, nhà toán học John Conway công bố một trò chơi không có người chơi. Nó diễn ra trên một lưới ô vuông, mỗi ô hoặc sống hoặc chết, và toàn bộ luật gồm ba dòng về việc một ô sống hay chết ở thế hệ sau tùy theo số ô sống xung quanh nó.
Từ ba dòng đó, người ta phát hiện ra những cấu trúc di chuyển được trên lưới, những cấu trúc tự sinh sản ra cấu trúc khác, và cuối cùng là chứng minh rằng hệ thống này có thể mô phỏng bất kỳ phép tính nào mà một máy tính làm được.
Conway không thiết kế bất kỳ cấu trúc nào trong số đó. Ông viết ba dòng luật. Mọi thứ còn lại là do người khác tìm ra sau khi hệ thống đã chạy.
Đây là hiện tượng mà bài viết này bàn tới, và nó là một trong những công cụ mạnh nhất mà người thiết kế game có, đồng thời cũng là công cụ dễ hiểu sai nhất.
Khái niệm gốc: hệ phức hợp
Cần phân biệt hai từ mà tiếng Việt lẫn tiếng Anh đều dễ nhầm.
Một hệ phức tạp là hệ có rất nhiều bộ phận. Một chiếc máy bay có hàng triệu chi tiết, nhưng nếu biết đủ về từng chi tiết thì hành vi của cả chiếc máy bay là dự đoán được. Tổng thể đúng bằng tổng các phần.
Một hệ phức hợp thì khác. Theo mô tả của John Holland, tính nổi trội chỉ xuất hiện khi hoạt động của các bộ phận không đơn giản cộng lại thành hoạt động của tổng thể. Với tính nổi trội, tổng thể thực sự lớn hơn tổng các phần.
Những ví dụ kinh điển gồm sự sống, vốn chỉ là các phân tử; ý thức, vốn là kết quả tương tác giữa các tế bào não; và tổ kiến, nơi không có bất kỳ trung tâm chỉ huy nào. Không con kiến nào biết bản thiết kế của tổ, nhưng cái tổ vẫn được xây.
Điểm quan trọng cần giữ trong đầu suốt bài viết: hệ phức hợp không đòi hỏi luật phức tạp. Ngược lại là đằng khác. Gần như mọi hệ phức hợp thú vị đều được sinh ra từ một số ít luật rất đơn giản, và đó chính là điều làm chúng đáng học.
Chú thích: Đàn chim bay theo những hình khối phức tạp mà không con nào nắm được toàn cảnh. Mô hình boids nổi tiếng tái tạo được hành vi này chỉ với ba luật cục bộ: tránh va chạm, khớp hướng bay với lân cận, và hướng về trung tâm của nhóm lân cận.
Nổi trội và tiến trình: hai cách tạo ra thử thách
Jesper Juul, trong bài viết năm 2002, đưa ra sự phân biệt đã trở thành nền tảng cho mọi thảo luận về sau. Ông cho rằng hầu hết game máy tính là sự kết hợp của hai cách khác nhau để đặt thử thách trước người chơi.
Cách thứ nhất là nổi trội, tức một số ít luật kết hợp với nhau tạo ra biến thể. Trong cấu trúc này, game được đặc tả bằng một nhóm nhỏ luật lệ, chúng kết hợp và sinh ra số lượng lớn tình huống khác nhau mà người chơi phải tự nghĩ chiến lược để đối phó. Juul gọi đây là cấu trúc game nguyên thủy, và ông chỉ ra rằng về cơ bản mọi trò chơi tiền điện tử đều thuộc loại này. Game nổi trội có xu hướng chơi đi chơi lại được, và có xu hướng sinh ra giải đấu cùng những cẩm nang chiến thuật.
Cách thứ hai là tiến trình, tức các thử thách được định sẵn và trình bày lần lượt. Đây là cấu trúc mới hơn về mặt lịch sử, đi vào game máy tính qua thể loại phiêu lưu. Ở đây người chơi phải thực hiện một chuỗi hành động được định trước để hoàn thành game.
Điểm mà Juul nhấn mạnh và cũng là điểm quan trọng nhất: sự biến thiên trong game nổi trội không phải ngẫu nhiên, cũng không phải do người chơi cung cấp. Nó là hệ quả không hiển nhiên của chính luật chơi.
Mỗi cấu trúc có nhược điểm riêng khi dùng thuần túy. Game tiến trình thuần khiến người chơi có cảm giác bị đặt lên đường ray, và đòi hỏi nhà phát triển tốn nhiều thời gian đắp tay từng trải nghiệm. Game nổi trội thuần có nguy cơ làm người chơi ngợp trước không gian khả năng quá rộng, hoặc chán vì không có phương hướng tiến lên rõ ràng.
Vì thế gần như mọi game thực tế đều là hỗn hợp, và câu hỏi thiết kế không phải chọn cái nào mà là pha theo tỷ lệ nào.
Bốn điều kiện để tính nổi trội xuất hiện
Đây là phần thực dụng nhất. Nếu thiếu bất kỳ điều kiện nào trong bốn điều dưới đây, hệ thống sẽ trông có vẻ hệ thống nhưng không sinh ra hành vi bất ngờ.
Điều kiện thứ nhất: luật phải phổ quát cho cả lớp đối tượng mà chúng áp dụng. Nếu một vật bằng gỗ cháy được thì mọi vật bằng gỗ phải cháy được. Càng nhiều ngoại lệ tồn tại trong game, người chơi càng ít động lực để thử những cách khác nhau.
Đây là điều kiện bị vi phạm nhiều nhất trong thực tế, vì ngoại lệ luôn rẻ hơn trong ngắn hạn. Khi một vật gỗ cụ thể không nên cháy vì lý do thiết kế màn chơi, cách nhanh nhất là đánh dấu nó là ngoại lệ. Cái giá không hiện ra ngay mà hiện ra sau vài chục ngoại lệ, khi người chơi ngừng thử vì họ đã học được rằng thử thường không có tác dụng.
Điều kiện thứ hai: các thành phần phải tương tác với nhau, chứ không chỉ tương tác với người chơi. Đây là điều kiện then chốt và bị bỏ sót nhiều nhất. Một game có ba mươi loại vũ khí mà mỗi loại chỉ tác động lên kẻ địch thì không có tính nổi trội, nó chỉ có ba mươi lựa chọn song song. Tính nổi trội bắt đầu ở đúng khoảnh khắc mà lửa gặp nước, mà kẻ địch này gây tiếng động đánh thức kẻ địch kia, mà cơn mưa làm mặt đá trơn.
Điều kiện thứ ba: trạng thái phải bền đủ lâu để chồng lên nhau. Nếu ngọn lửa tắt sau nửa giây thì nó không kịp gặp thùng thuốc nổ. Tính nổi trội cần thời gian để các hệ quả gối lên nhau, và một hệ thống dọn dẹp trạng thái quá nhanh sẽ giết chết phần lớn tổ hợp thú vị trước khi chúng kịp xảy ra.
Điều kiện thứ tư: người chơi phải quan sát được quan hệ nhân quả. Nếu một tổ hợp xảy ra mà người chơi không nhìn thấy nguyên nhân, thì về mặt trải nghiệm nó không tồn tại. Họ sẽ coi đó là ngẫu nhiên hoặc là lỗi, và sẽ không lặp lại. Tính nổi trội trong hệ thống mà người chơi không đọc được thì chỉ là nhiễu.
Một ví dụ cụ thể: ba luật của một cỗ máy hóa học
Trong bài trình bày tại hội nghị nhà phát triển game năm 2017, giám đốc kỹ thuật của Breath of the Wild là Takuhiro Dohta mô tả cái mà đội ngũ gọi là cỗ máy hóa học. Nếu cỗ máy vật lý là một bộ tính toán chuyển động dựa trên luật, thì cỗ máy hóa học là một bộ tính toán trạng thái dựa trên luật.
Hệ thống chia mọi thứ trong thế giới thành hai loại. Những thứ không giữ trạng thái cố định, như lửa, nước, băng, điện và gió, được gọi là nguyên tố. Những vật thể rắn như cây, đá, và cả bản thân nhân vật, được gọi là vật liệu.
Toàn bộ luật gồm ba dòng. Nguyên tố có thể thay đổi trạng thái của vật liệu, chẳng hạn lá trên cây cháy và biến mất. Nguyên tố có thể thay đổi trạng thái của nhau, chẳng hạn lửa tắt khi gặp nước. Và vật liệu không thể thay đổi trạng thái của vật liệu khác.
Dohta nhận xét rằng mô hình này cực kỳ đơn giản nhưng cho phép biểu đạt đủ mọi loại sự kiện.
Điều đáng chú ý nhất trong ba luật đó lại là luật thứ ba, vì nó là một hạn chế cố ý. Nếu vật liệu cũng tương tác được với nhau thì số lượng cặp phải xử lý sẽ tăng vọt và hệ thống trở nên bất khả kiểm thử. Bằng cách cấm một chiều tương tác, đội ngũ giữ được ma trận đủ nhỏ để làm cho đúng, trong khi vẫn giữ được phần lớn không gian khả năng thú vị.
Đây là bài học thiết kế quan trọng hơn bản thân ví dụ: tính nổi trội không đến từ việc cho phép mọi thứ, mà đến từ việc chọn đúng một số ít chiều tương tác và làm chúng thật nhất quán.
Câu tổng kết của Dohta về triết lý này đáng ghi nhớ: thay vì tạo ra thứ gì đó vui, hãy tạo ra một hệ thống làm cho những thứ vui xảy ra.
Ma trận tương tác: công cụ đo chiều sâu hệ thống
Có một cách rất thực dụng để đo xem một hệ thống có chiều sâu hay không, và nó chỉ cần một bảng.
Liệt kê mọi thành phần của hệ thống thành hàng và cột, rồi điền vào mỗi ô kết quả khi thành phần hàng gặp thành phần cột. Ô nào không có gì xảy ra thì để trống.
Chú thích: Ma trận tương tác mẫu. Đây là bảng tự dựng để minh họa phương pháp, không phải bảng thật của bất kỳ tựa game nào. Giá trị của nó nằm ở chỗ nó biến câu hỏi mơ hồ về chiều sâu thành một tỷ lệ đếm được.
Ma trận này dùng được theo ba cách.
Cách thứ nhất là đo mật độ. Chia số ô có nội dung cho tổng số ô. Một hệ thống có mật độ dưới hai mươi phần trăm gần như chắc chắn không sinh ra tính nổi trội, vì phần lớn tổ hợp mà người chơi thử sẽ không cho kết quả gì.
Cách thứ hai là tìm hàng và cột trống. Nếu một thành phần có cả hàng lẫn cột gần như trống rỗng, thì thành phần đó là trang trí chứ không phải một phần của hệ thống. Nó tốn công làm, tốn công kiểm thử, và không đóng góp gì vào chiều sâu.
Cách thứ ba là ước lượng chi phí khi mở rộng. Đây là chỗ toán học trở nên vừa hấp dẫn vừa đáng sợ.
Cộng và nhân
Khi thêm nội dung vào một game tiến trình, tổng lượng nội dung tăng theo phép cộng. Thêm một màn chơi thì có thêm một màn chơi.
Khi thêm một thành phần vào một hệ thống có tương tác, số lượng tổ hợp tăng theo phép nhân. Với n thành phần tương tác đầy đủ với nhau, số cặp là n nhân với n trừ một, chia hai. Thêm một thành phần thứ n cộng một thì sinh ra thêm n cặp mới.
Chú thích: Số cặp tương tác tăng theo bậc hai của số thành phần. Đây vừa là nguồn sức mạnh của thiết kế hệ thống, vừa là nguồn chi phí kiểm thử của nó.
Đường cong này giải thích hai điều cùng lúc.
Nó giải thích vì sao một hệ thống chỉ tám thành phần có thể cho cảm giác vô tận: hai mươi tám cặp tương tác, và người chơi phát hiện ra chúng dần dần trong hàng chục giờ chơi.
Nó cũng giải thích vì sao thiết kế hệ thống đắt hơn nhiều so với vẻ ngoài. Mỗi cặp phải được định nghĩa, cài đặt, kiểm thử và cân bằng. Ở mười sáu thành phần đã là một trăm hai mươi cặp, và không đội ngũ nào kiểm thử hết được. Đó là lý do gốc rễ của mọi lỗ hổng khai thác trong game hệ thống: chúng không phải do lập trình cẩu thả mà do không gian tổ hợp vượt quá khả năng kiểm thử.
Vì sao không thể ép buộc tính nổi trội
Đến đây là luận điểm quan trọng nhất của bài viết, và nó mang tính triết học hơn kỹ thuật.
Trong thiết kế hệ thống, nhà thiết kế định nghĩa tương tác, không định nghĩa kết quả. Một khi các luật tồn tại, kết quả được khám phá chứ không được trao. Quyền quyết định kết quả chuyển từ nhà thiết kế sang chính mô phỏng: hệ thống không quan tâm kết quả có tối ưu hay không, nó chỉ quan tâm kết quả có tuân theo luật hay không.
Đây là một sự đánh đổi quyền lực thật sự, và nó có ba hệ quả mà đội ngũ phải chấp nhận trước khi bắt đầu.
Hệ quả thứ nhất là thất bại trở nên thường xuyên. Trong một hệ thống chế tạo truyền thống, kết quả có thể đoán trước và thất bại hiếm gặp. Trong một hệ thống thật sự, người chơi thử nhiều thứ không hoạt động, và điều đó là bình thường chứ không phải lỗi thiết kế.
Hệ quả thứ hai là chiều sâu không còn tỷ lệ với lượng nội dung. Với hệ thống chế tạo, thêm nội dung thì thêm chiều sâu. Với hệ thống thật sự, chiều sâu đến từ tương tác chứ không từ số lượng, nên có thể có hệ thống rất sâu với rất ít nội dung, và ngược lại.
Hệ quả thứ ba, và là hệ quả khó chấp nhận nhất về mặt tổ chức: một khoảnh khắc nổi trội được thiết kế sẵn là một mâu thuẫn về mặt logic. Nếu một studio dàn dựng một cảnh tia sét đánh trúng vật kim loại rồi làm nổ thùng thuốc, thì đó không phải tính nổi trội, đó là tiến trình đội lốt. Người chơi cảm nhận được sự khác biệt gần như ngay lập tức, vì khoảnh khắc dàn dựng thì lặp lại giống hệt nhau còn khoảnh khắc nổi trội thì không.
Thứ mà nhà thiết kế thực sự điều khiển được là xác suất, không phải sự kiện. Họ chọn thành phần nào tồn tại, chọn chiều tương tác nào được phép, chọn tần suất mà các thành phần đó xuất hiện gần nhau. Sau đó họ phải chấp nhận rằng khoảnh khắc đáng nhớ nhất trong game của mình sẽ do một người chơi nào đó tìm ra, chứ không do họ viết.
Cái giá phải trả
Để tránh làm bài viết thành một lời ca ngợi một chiều, cần liệt kê rõ những thứ mà tính nổi trội lấy đi.
Nó lấy đi khả năng kiểm soát nhịp và tường thuật. Nếu người chơi có thể giải quyết một tình huống theo mười cách, thì không cách nào đảm bảo họ trải nghiệm một cao trào cảm xúc cụ thể vào đúng thời điểm mong muốn.
Nó lấy đi khả năng kiểm thử toàn diện, vì lý do bậc hai đã nói ở trên.
Nó mở cửa cho khai thác lỗ hổng. Người chơi sẽ tìm ra tổ hợp phá vỡ cân bằng, và trong một hệ thống nhất quán thì tổ hợp đó thường hợp lệ về mặt luật, nên vá nó đồng nghĩa với việc thêm một ngoại lệ, và ngoại lệ thì phá điều kiện thứ nhất.
Và nó có nguy cơ làm người chơi ngợp, đúng như cảnh báo về game nổi trội thuần túy.
Bốn cái giá này là lý do vì sao gần như mọi game thương mại thành công đều pha trộn hai cấu trúc: dùng tiến trình để dẫn dắt, kiểm soát nhịp và dạy hệ thống, rồi dùng tính nổi trội để tạo chiều sâu và lý do chơi lại. Câu hỏi thiết kế đúng không phải là chọn bên nào, mà là mỗi phần của game nên nghiêng về bên nào.
Năm câu hỏi kiểm tra một hệ thống
Luật của tôi có ngoại lệ nào không, và mỗi ngoại lệ đang mua cho tôi cái gì. Nếu số ngoại lệ nhiều hơn số luật, hệ thống đã chết.
Các thành phần có tương tác với nhau không, hay tất cả chỉ tương tác với người chơi. Đây là câu hỏi phân biệt một hệ thống thật với một danh sách tính năng.
Trạng thái tồn tại bao lâu. Nếu mọi hiệu ứng biến mất trong một giây, tổ hợp không kịp xảy ra.
Điền ma trận ra, mật độ là bao nhiêu, hàng nào cột nào trống. Đây là bài kiểm tra rẻ nhất và cho nhiều thông tin nhất.
Tôi có sẵn sàng để hệ thống quyết định kết quả thay cho tôi không. Nếu câu trả lời là không, thì việc đang làm là thiết kế tiến trình, và điều đó hoàn toàn hợp lệ, chỉ là không nên gọi nó bằng tên khác.
Câu hỏi cuối cùng đó đáng suy nghĩ nhất, vì nó không phải câu hỏi kỹ thuật mà là câu hỏi về khí chất. Thiết kế hệ thống đòi hỏi sự thoải mái với việc không biết trước điều gì sẽ xảy ra trong chính sản phẩm mình làm ra, và không phải nhà thiết kế nào cũng có sự thoải mái đó. Biết mình thuộc loại nào là thông tin hữu ích hơn nhiều so với việc cố trở thành loại kia.
Tài liệu tham khảo
- Juul, Jesper. The Open and the Closed: Games of Emergence and Games of Progression, 2002. Bài viết gốc, bản đầy đủ trên trang của tác giả. https://jesperjuul.net/text/openandtheclosed.html
- Juul, Jesper. The Open and the Closed, bản kỷ yếu DiGRA, gồm phần dẫn định nghĩa tính nổi trội của John Holland và các ví dụ kinh điển. https://dl.digra.org/index.php/dl/article/download/9/9/6
- Deriving Quests from Open World Mechanics, arXiv. Nguồn của phần nhược điểm khi dùng thuần túy một trong hai cấu trúc. https://arxiv.org/pdf/1705.00341
- Dormans, Joris. Integrating Emergence and Progression, kỷ yếu DiGRA 2011. Nguồn của luận điểm về cách cấu trúc không gian kéo game về phía tiến trình. https://dl.digra.org/index.php/dl/article/download/593/593/590
- Thumbsticks, Breath of the Wild, Science, and Clever Little Lies. Tường thuật bài nói của Takuhiro Dohta tại GDC 2017, nguồn của ba luật của cỗ máy hóa học và phân biệt nguyên tố với vật liệu. https://www.thumbsticks.com/gdc-17-breath-of-the-wild-science-lies/
- Medium, Breath of the Wild: Experimental Solutions. Nguồn bổ sung về ba luật và về hệ quả thiết kế đối với người chơi. https://medium.com/@joshuabgad/breath-of-the-wild-experimental-solutions-5ce0ec0ec9b7
- The Artifice, Systemic Games: A Design Philosophy. Nguồn của nguyên tắc luật phải phổ quát cho cả lớp đối tượng và của cảnh báo về ngoại lệ. https://the-artifice.com/systemic-games-philosophy/
- The Design Lab, Immersive Design: Systemic Chemistry. Nguồn của phần chuyển dịch quyền quyết định kết quả từ nhà thiết kế sang mô phỏng, và của bảng so sánh giữa hệ thống chế tạo và hóa học hệ thống. https://thedesignlab.blog/2026/02/09/immersive-design-systemic-chemistry/
- Wikipedia, Immersive sim. Nguồn của mô tả về các hệ thống tương tác, nhất quán và phản ứng tạo ra lối chơi nổi trội. https://en.wikipedia.org/wiki/Immersive_sim
- Yahoo Tech, phỏng vấn đội ngũ về hệ thống vật lý của Tears of the Kingdom. Nguồn của phát biểu về việc tạo ra hệ thống làm cho những thứ vui xảy ra thay vì tạo ra thứ vui. https://tech.yahoo.com/computing/articles/development-going-chaos-physics-tears-000138397.html
0 Lời bình