Trong bài trước, chúng ta đã nhắc đến những tiêu chí về thông tin khi thiết kế puzzle mà chúng ta cần phải quan tâm. Trong bài này, chúng ta sẽ thảo luận tới những tiêu chí cao cấp và trừu tượng hơn trong quá trình thiết kế puzzle để cải thiện chất lượng chung của một game, cả game thể loại puzzle nói riêng và game các thể loại nói chung.
Ảnh header: Fidel Dungeon Rescue (2017), bởi Daniel Benmergui.
Hãy dừng ngay thiết kế ngược (Backward Design)
Các game tuyến tính (linear) là game mà ở đó tính tương tác của game được thu hẹp lại thành một hành lang hẹp, có nghĩa rằng gần như chỉ có duy nhất một lối đi hay một cách giải cho tất cả các thử thách trong game. Và một trong những cách thiết kế puzzle ưa thích của game designer cho loại game tuyến tính này là thiết kế ngược. Về cơ bản, thiết kế ngược có nghĩa là người thiết kế sẽ bắt đầu bằng cách tạo một puzzle trong trạng thái đã được giải (solved state), sau đó tháo tung puzzle một cách tùy tiện, ngẫu hứng và vô phương hướng, sau đó yêu cầu người chơi đưa nó trở lại vị trí ban đầu.
Thiết kế ngược
Điểm “mạnh” duy nhất trong cách thiết kế này, đó là game designer có thể gần như ngay lập tức tạo ra một thử thách cho người chơi và đảm bảo rằng có ít nhất một cách để giải puzzle mà không cần phải suy nghĩ quá nhiều. Hơn nữa với phương thức này, độ khó của puzzle đa phần phụ thuộc vào mức độ ngẫu hứng khi game designer tháo tung các mảnh ghép.
Unblock Me
Cách thiết kế này được sử dụng rất nhiều trong các game giống như Unblock Me. Sự tùy tiện trong cách “thiết kế” puzzle kiểu như thế này được thể hiện rõ khi người ta đã nghĩ đến (và rất có thể đã thực hiện) giải thuật để máy có thể tự động xuất ra các level cho game này với độ khó tăng dần dựa trên số lượng những nước đi mà người chơi phải thực hiện.
Tuy vậy, cách thiết kế puzzle ngược này tồn đọng hai yếu điểm trầm trọng.
Thứ nhất, lối thiết kế này rất dễ khiến cho người chơi cảm thấy khó chịu vì sự phi logic hay thiếu phương hướng của chúng. Điều này là bởi trong quá trình giải quyết puzzle, người chơi không có cách nào nhìn ra được hướng giải quyết—hay chí ít là họ cần phải bắt đầu suy nghĩ từ đâu cả. Vì thế, người chơi sẽ bắt đầu cảm thấy mình cần phải đi dò từng chi tiết rất nhỏ một với hy vọng rằng mình sẽ tìm được một manh mối nào đó. Quá trình này là vô cùng vất vả và mất rất nhiều thời gian quý giá của người chơi, chỉ để theo đuổi những manh mối mà chưa chắc đã là manh mối liên quan đến lời giải cho puzzle. Hơn nữa, nếu sau khi người chơi đã giải được puzzle của bạn rồi và họ vẫn không hiểu làm thế nào họ đã giải được nó, thì có nghĩa là thiết kế của bạn đã thất bại. Những puzzle như thế này có thể được tìm thấy trong rất nhiều những tựa game phiêu lưu lớn như Tomb Raider hay Uncharted.
Một puzzle trong Uncharted 3: Drake’s Deception (2011)
Thứ hai, cũng bởi vì cách thiết kế ngược này là tùy tiện và thiếu phương hướng, nên đôi khi chúng sẽ dẫn đến những sai sót logic rất ngớ ngẩn. Giả sử chúng ta có một game phiêu lưu rất đơn giản như sau:
Chúng ta muốn người chơi đi qua một cách cửa sắt có ổ khóa. Chúng ta cho người chơi biết cửa đang khóa và họ cần chìa khóa để mở nó. Thế nhưng chiếc chìa khóa đó lại đang nằm trong tay một con quỷ hung bạo cầm lưỡi liềm. Con quỷ này có khả năng đánh tầm gần rất giỏi, nên nếu muốn hạ gục nó người chơi sẽ không thể sử dụng vũ khí cận chiến được, mà sẽ phải đi tìm một khẩu súng. Sau khi tìm được một khẩu súng, người chơi hạ gục con quỷ, cướp lấy chiếc chìa khóa và mở được cánh cửa.
Thật là một kịch bản thú vị phải không? Chưa chắc. Có một lỗi logic rất cơ bản ở đây là: nếu người chơi đã tìm ra được một khẩu súng rồi, thì tại sao họ lại không thể dùng nó để bắn nát ổ khóa cửa để đi tiếp, mà lại phải mất thêm cả thời gian lẫn các loại tài nguyên khác (máu, vật phẩm, etc) để hạ gục con quỷ nọ để lấy được chìa khóa của nó? Bởi khi thiết kế ngược, game designer rất dễ quên đi một điều rằng, những dữ liệu game designer có được tại mỗi thử thách là khác so với dữ liệu của người chơi ở đó. Một thử thách khi thiết kế ngược có thể sẽ logic đối với game designer, nhưng đối với người chơi, những người không có hoặc chưa có những dữ liệu của game designer, thì chưa chắc họ sẽ cảm thấy chúng logic.
Những dữ liệu game designer có được tại mỗi thử thách là khác so với dữ liệu của người chơi ở đó.
Tái sử dụng dữ liệu nhưng không tự lặp lại chính mình
Trong quá trình thiết kế một game puzzle, bạn không nhất thiết phải liên tục giới thiệu những yếu tố hay những chức năng mới toanh mà người chơi chưa từng nhìn thấy để họ tiếp tục tập trung vào game. Cái gì quá cũng là không tốt, và việc liên tục giới thiệu những yếu tố mới cũng sẽ khiến đầu óc của người chơi nhanh chóng trở nên mệt mỏi. Một cách rất hữu hiệu để thiết kế puzzle, đó là tái sử dụng những kiến thức hay những dữ liệu mà người chơi đã thu về được từ những puzzle hay những yếu tố mà họ đã trải qua trước đó, nhưng đồng thời lại thêm thắt hay điều chỉnh puzzle hiện tại vừa đủ sao cho họ không thể sử dụng đáp án cũ để vượt qua được. Một ví dụ điển hình của phương thức này là các chuỗi puzzle trong The Witness của Jonathan Blow như sau (vốn đã được giải thích trong bài Game & Lời thề Im lặng.)
Ví dụ cho một chuỗi puzzle trong The Witness (2016)
Ta có thể thấy, khi so sánh puzzle 2 với puzzle 1, hay khi so sánh puzzle 3 với puzzle 2, về mặt cấu trúc thì chúng khá tương đồng với nhau, và puzzle sau chỉ có duy nhất một điểm khác biệt khá nhỏ với puzzle trước. Thế nhưng đồng thời, cũng chính vì sự khác biệt tưởng chừng rất nhỏ đó, mà người chơi sẽ không thể giải được puzzle nếu họ vẫn tiếp tục sử dụng cách giải hay phương hướng giải cũ. Cách thiết kế này có những điểm mạnh sau:
- Cho phép người chơi dần dần hiểu ra được những quy tắc mà game yêu cầu một cách tự động. Bởi bản tính của con người khi họ nhìn thấy một vấn đề khá tương đồng với một vấn đề mà họ đã từng giải quyết trước đó, điều đầu tiên họ làm sẽ là thử lấy cách giải quyết của vấn đề trước đó và lắp vào vấn đề trước mắt xem chuyện gì sẽ xảy ra. Và xu hướng tâm lý học này là thứ mà game designer chúng ta cần phải tận dụng.
- Khi có cơ hội được vận dụng những kiến thức mà người chơi đã chắt lọc được từ trước đó, thì những kiến thức đó của họ sẽ được củng cố vững chắc, đồng thời sự tự tin của người chơi cũng gia tăng.
Tuy nhiên vẫn cần phải nhấn mạnh một điều: tuy rằng chúng ta nên tái sử dụng (hay nói cách khác là sử dụng hiệu quả) những dữ liệu/kiến thức mà người chơi đã thu nạp được, thì điều đó cũng không có nghĩa là chúng ta nên tự lặp lại những puzzle trước đó. Khi bạn cảm thấy chuỗi puzzle hiện tại không còn điều gì mới mẻ mà người chơi có thể thu nạp thêm được nữa, hãy dừng lại. Đó là quy tắc thiết kế tối giản.
Một trong những puzzle ấn tượng nhất của Portal 2
Tận dụng tất cả những yếu tố cấu thành puzzle
Trong cuốn Defining Edges: A New Look at Picture Frames của William Bailey, ông đã đi sâu vào phân tích 56 bức tranh nổi tiếng, để chứng tỏ rằng bộ khung của một bức tranh cũng là một phần của tác phẩm nghệ thuật đó. Nguyên lý này cũng rất đúng trong thiết kế puzzle nói riêng và thiết kế game nói chung, và chúng ta cần phải tận dụng một cách triệt để tất cả những yếu tố cấu thành của một đối tượng để giúp nó truyền tải được thông điệp một cách hiệu quả và ý nghĩa nhất. Chúng ta sẽ nhìn vào một số ví dụ sau.
Talos Principle (2014)
Ví dụ 1: Trong Talos Principle, mỗi lần bạn bước chân qua một cánh cửa màu để vào một puzzle, tên của puzzle đó sẽ hiện ra. Ngoài chức năng phân biệt giữa các puzzle ra, cái tên của puzzle đôi khi lại chính là gợi ý đến cách giải cho người chơi. Một puzzle với cái tên The Triangle sẽ gợi cho người chơi biết rằng họ cần phải xây dựng nên một hình tam giác nào đó với các công cụ cho sẵn để giải được puzzle. Và những puzzle khác cũng tương tự như vậy.
Papers, Please (2013)
Ví dụ 2: Trong Papers, Please, người chơi vào vai một nhân viên an ninh tại cửa khẩu biên giới của nước Arstotzka, và nhiệm vụ của người chơi là kiểm tra xem giấy tờ của từng người muốn nhập cư vào Arstotzka có đầy đủ và đúng xác thực hay không. Và người chơi sẽ sớm nhận ra rằng họ sẽ phải tận dụng không chỉ những thông tin hiện hữu trên giấy tờ của đối tượng, mà họ sẽ còn phải xem xét cả về những yếu tố bên ngoài như khuôn mặt, hình thể, hay thậm chí là cả tác phong và lời nói của họ, để có thể đưa ra được quyết định xem có nên cho họ đi qua cửa khẩu hay không. Bởi bất cứ sự bất hợp lý nào cũng có thể dẫn đến quyết định sai lầm, và quyết định sai lầm sẽ dẫn đến dấu chấm hết cho gia đình của nhân vật chính.
Jumpman – Braid (2008)
Ví dụ 3: Hình trên là một puzzle tại World 4 trong Braid (xin nhắc vui luôn rằng puzzle này là một reference đến tựa game classic rất nổi tiếng là Donkey Kong.) Mục tiêu của bạn là leo lên đến đỉnh dốc trên cùng và thu hồi miếng ghép jigsaw kia. Và nếu theo logic của một game platformer thông thường, bạn sẽ di chuyển theo đúng trình tự từng con dốc và từng chiếc thang một.
Trái: ngõ cụt – Phải: cách giải quyết
Và khi đến điểm này, bạn sẽ nhận ra là trên đầu bạn có một con Monstar, và cũng bởi vì cơ chế thời gian của puzzle này đang hoạt động theo một cách nhất định, nên bạn biết chắc rằng bạn đang bị tắc tại đây. Và cách duy nhất để giải được puzzle, đó là bạn phải vận dụng một kiến thức platforming khác—vốn không liên quan đến cơ chế điều khiển thời gian của game—đó là nhảy lên đầu Monstar để bật lên đỉnh đồi trên cùng. Như vậy ở đây ta có thể thấy, chìa khóa để giải được puzzle này trong Braid không nằm ở khả năng điều khiển thời gian của nhân vật chính Tim, mà nằm ở chính khả năng platforming của cậu ta.
Kết luận
Tổng kết lại, có ba tiêu chí quan trọng khi thiết kế puzzle cho game mà chúng ta cần lưu ý:
- Hạn chế tối đa thiết kế ngược (backward design), bởi lối thiết kế này là lối thiết kế khá lười và sẽ gây nhiều ức chế cho người chơi. Thay vào đó, hãy chịu khó vận dụng cách thiết kế xuôi (forward design), đó là tự đặt mình vào vị trí của người chơi tại từng thời điểm, và kiểm tra xem tại mỗi thời điểm đó người chơi có những dữ liệu gì để từ có thể điều hướng thiết kế puzzle sao cho logic.
- Khôn khéo tái sử dụng những dữ kiện hay những kiến thức mà người chơi đã có sẵn, sau đó tinh chỉnh để tạo sự bất ngờ cho người chơi, qua đó truyền tải thêm một điều gì đó—có thể nhỏ nhưng lại tinh tế—cho người chơi. Nhưng hãy nhớ rằng, tái sử dụng dữ kiện có sẵn không có nghĩa là lặp đi lặp lại. Nếu cảm thấy không có gì mới để thêm vào, thì hãy dừng lại, và giữ cho thiết kế ở mức tối giản.
- Tận dụng tất cả những gì cấu thành puzzle, từ những yếu tố lớn nhỏ, cách chúng tương tác với nhau, cấu trúc của các yếu tố đó, hay thậm chí là cả tên của puzzle như trong Talos Principle, để góp phần xây dựng nên puzzle.
Nếu bạn cảm thấy phần phân tích phía trên là dài dòng, bạn có thể đọc phần kết luận rút ngắn dưới đây. Tuy nhiên tôi nghĩ khả năng cao là bạn sẽ không hiểu cho lắm nếu chỉ đọc kết luận đâu. Trên thực tế, tôi cho rằng bài viết này vẫn chưa đi đủ sâu vào từng ý cụ thể như tôi mong muốn. Vì thế, nếu có ai cảm thấy có chỗ nào chưa rõ ràng lắm và cần có thêm bài đi sâu hơn, có ví dụ thực tế và trực quan hơn, thì hãy comment để tôi biết nhé!
