Bạn nghĩ là bạn thiết kế puzzle giỏi? (Pt. 1)
- Hùng Vũ
- Dec 12, 2018
- 9 min read
Năm ngoái tôi mới chơi thử một game dạng Escape the Room của một dịch vụ có tên là We Escape tại Hà Nội (nhờ Facebook nhắc nhở). Và điều duy nhất tôi rút ra được từ một lượt game chỉ kéo dài trong một tiếng đồng hồ ngắn ngủi và khá khó chịu như thế là: mấy người này không biết cách thiết kế puzzle một tí nào.
Vì thế nên nhân dịp này xin viết một vài hướng đi, để game designer nói riêng hay những ai muốn bắt đầu thiết kế puzzle cho bất cứ loại chương trình tương tác nào nói chung có thể chí ít là xác định được chất lượng puzzle của mình. Bức ảnh header của bài viết này là của Braid—tựa game của studio Number None mà hôm mùng 6 tháng 8 vừa rồi đã được đón mừng 9 năm kể từ ngày ra mắt lần đầu tiên ở Bắc Mỹ năm 2008.
Vấn đề hiện hữu trong thiết kế game phiêu lưu cổ điển
Thể loại adventure phải nói là thể loại fiction có tương tác đầu tiên được ra đời, và trong một khoảng thời gian khá dài (trước 1995) đã làm mưa làm gió trong thị trường game. Các tựa game nổi tiếng của thể loại này có thể kể đến King's Quest (1980) của Sierra, Loom (1990) của LucasArts, Full Throttle (1995) của Tim Schafer tại Double Fine. Tuy vậy, từ năm 2000 trở đi, thể loại game adventure đã lùi dần vào bóng tối để nhường sân khấu cho các thể loại game khác, với chỉ một vài tựa game trung bình như Broken Sword của Revolution Software, và mãi cho đến gần đây mới đang từng bước tái sinh trở lại.
Lý do giải thích cho việc thể loại game adventure thất bại dần thì có nhiều, nhưng đa phần đến từ những điểm yếu rất lớn trong design của chúng.
Ví dụ như một puzzle trong Gabriel Knight (1993), bạn phải sử dụng masking tape (băng dính hóa trang) và maple syrup (xirô mật phong) để biến lông mèo thành một bộ râu giả, để bạn có thể hóa trang thành một gã thậm chí còn không có cả râu, để rồi sau đó bạn phải đánh cắp hộ chiếu của hắn rồi đi kiếm marker pen (bút dạ) để vẽ râu lên ảnh hắn.
Hay như trong Broken Sword (1996), sau khi nhân vật chính là một nữ phóng viên của bạn đã chứng kiến một vụ ám sát tại nhà một chính trị gia nọ, bạn phải lần mò click vào từng pixel một trên tất cả những gì bạn có thể tương tác được trong căn nhà, chỉ để tìm được một thứ (trong phiên bản 1996 bạn chỉ nhìn thấy biểu tượng của item chứ không biết tên của nó trong túi đồ) mà phải mãi đến cuối game bạn mới phải cần đến nó. Và như thế rõ ràng với tư cách là người chơi, ta đặt ra câu hỏi rằng: làm sao mà nhân vật kia lại lường trước được một thứ vật phẩm kỳ quặc và tí hon như thế này sẽ hữu dụng về sau? Và làm sao để người chơi biết được rằng khi họ đang bị tắc ở một vấn đề nào đó, thì liệu họ có thể đi tìm được đáp án ở gần đó, hay là họ đã bị vuột mất cơ hội tìm được nó từ lâu, và giờ họ hoặc sẽ phải quay đầu lại một quãng đường rất xa, hay là phải chăng họ đã hết hy vọng và bắt buộc phải chơi lại từ đầu mới mong qua được?
Các tiêu chí thiết kế puzzle cơ bản
Những câu hỏi vừa được nêu cũng là một vấn đề trong thiết kế game adventure mà đã được game designer của LucasArts lúc bấy giờ là Brian Moriarty giải quyết trong Loom (1990). Trong bài post-mortem để nhìn lại quá trình phát triển Loom, ông đã nói rằng: triết lý thiết kế của Loom lúc bấy giờ là đảm bảo rằng mỗi khi người chơi gặp phải một thử thách nào đó, thì câu trả lời luôn luôn nằm trong tầm với của họ, và việc của họ là chỉ cần phải đi tìm. Điều đó cũng đồng nghĩa là bạn sẽ không bao giờ gặp phải tình huống bế tắc nữa.
Thế nhưng, liệu đây đã phải là cách giải quyết tối ưu hay chưa, thì cá nhân tôi cho rằng chưa. Và cụ thể hơn, chúng ta sẽ đi sâu vào các tiêu chí thiết kế puzzle chất lượng như sau.
Khối lượng dữ liệu
Có lẽ hầu hết mọi người đều đã từng chơi qua Final Fantasy VIII của Square Enix (lúc bấy giờ vẫn là Squaresoft) và biết đến hệ thống GF Junction khá phức tạp của nó. Và đây là phần tutorial hướng dẫn sử dụng hệ thống này trong game.
Sau khoảng hơn 3 phút tutorial liên tục không-thể-bỏ-qua-được này, chúng ta trên thực tế mới chỉ đi qua được một nửa những chức năng mà game yêu cầu bạn phải hiểu. Ai đã từng chơi qua Final Fantasy VIII cũng hiểu rằng hệ thống GF Junction này khó hiểu đến thế nào với người mới bắt đầu. Và ta có thể thấy rõ những vấn đề hiện hữu của hệ thống GF Junction này là:
Khối lượng dữ liệu đầu vào trong cùng một bài toán như thế này là quá nhiều, rất khó để người chơi có thể hiểu được hoàn toàn. Lỗi này thường được gọi là infodumping.
Chữ không phải là cách tốt nhất để người chơi có thể nhớ được thông tin một cách hiệu quả.
Hiệu quả gameplay đem lại bởi hệ thống này là quá ít so với lượng kiến thức người chơi cần thu nạp để hiểu được nó. Với hệ thống này, người chơi sẽ tốn rất nhiều thời gian để micromanage (hay còn gọi là min-maxing) việc junction các loại spell khác nhau vào các chỉ số khác nhau, để cuối cùng các chỉ số của đối thủ cũng được scale theo chỉ số của nhân vật để đảm bảo cân bằng. Và dù sao đi chăng nữa, thì chiến thuật hiệu quả nhất trong chiến đấu của game này vẫn là Limit Break—thứ có thể được kích hoạt liên tục, miễn là HP của nhân vật ở mức 10%, và không một chút nào liên quan đến hệ thống Junction hay thậm chí là chỉ số nhân vật.
Hãy nhớ rằng khi thiết kế một bài toán, khối lượng của bài toán đó là rất quan trọng. Nếu khối lượng quá lớn, hãy tính đến chuyện chia nhỏ bài toán đó.
Chất lượng dữ liệu
Ngoài khối lượng, một điều quan trọng không kém nữa chúng ta phải nhắc đến đó là chất lượng của dữ liệu hay luồng dữ liệu được gửi đến cho người chơi để họ có cơ sở giải quyết được bài toán. Ta sẽ thử nghĩ đến một bài toán hết sức đơn giản như sau.
Giả sử bạn có 4 quả táo, 4 quả quýt và 4 quả chanh. Hỏi nếu tôi lấy 2 quả táo, bạn còn mấy quả táo?
Lẽ dĩ nhiên đáp án là bạn còn 2 quả táo. Tuy vậy, ta có thể thấy rằng trong bài toán này, dữ liệu về quýt và chanh là không cần thiết. Đối với những bài toán phức tạp hơn, với nhiều dữ liệu khác loại nhau hơn, thì việc tối ưu hóa dữ liệu đầu vào cho người chơi là vô cùng quan trọng.
Lấy một ví dụ khác, từ trải nghiệm của tôi tại We Escape Hà Nội năm ngoái. Mới bước vào game, mỗi thành viên trong nhóm của tôi được trao cho một vai trò riêng, kèm thêm một tấm vải in hình các loài linh thú dùng làm gợi ý. Chúng tôi mới chỉ vượt qua được 2 trong số 5 thử thách nên tôi cũng chưa rõ các vai trò của các thành viên trong nhóm có ý nghĩa gì. Tuy vậy, sự tồn tại của tấm vải luôn là một câu hỏi lởn vởn mãi trong đầu chúng tôi: liệu câu trả lời chúng tôi cần tìm có nằm trên tấm vải đó không? Nếu không, thì liệu nó có nằm ở đâu đó trong căn phòng đó không? Sau đó chúng tôi đã rà soát cả căn phòng, để cuối cùng nhận được câu trả lời của hướng dẫn viên là đáp án nằm ngay trên puzzle in trên tường. Khỏi phải nói, chúng tôi đều đồng loạt hô “Ôi giời ơi!”
Qua những ví dụ vừa rồi, chúng ta rút ra được một bài học rất quan trọng về chất lượng dữ liệu truyền tải tới cho người chơi:
Giới hạn logic của bài toán phải được truyền đạt rõ ràng. Nói cách khác, lượng dữ liệu người chơi được nhận phải vừa đủ, không thừa cũng không thiếu, để họ có thể hiểu được phương hướng để suy luận, và để dù người chơi có thua thì họ cũng không cảm thấy mình thật kém cỏi.
Cách truyền tải dữ liệu
Sau khi đã trả lời được hai câu hỏi “bao nhiêu dữ liệu?” và “dữ liệu nào?”, thì còn một vấn đề cơ bản cuối cùng nữa mà chúng ta cần phải quan tâm: “truyền tải dữ liệu như thế nào?”
Ta lấy một ví dụ đơn giản và khá gần gũi ngoài đời thực.
Quản lý thị trường phải dùng miệng thử phân bón? Sau khi đọc một tiêu đề bài báo như này, ta sẽ phải đặt ngay ra câu hỏi rằng liệu có lẽ nào một ai đó lại có thể đưa ra một quyết định đáng sợ như thế? Nhưng đến khi đọc nội dung bài thì chúng ta thấy sự thật không phải thế.
Lấy một ví dụ khác từ game. Đây là một puzzle ở World 2 trong game Braid. Đáng lẽ ra đây là một spoiler khá lớn cho game này, nhưng cá nhân tôi cảm thấy đây không phải là một puzzle chất lượng tốt (bản thân Jonathan Blow cũng đã từng thừa nhận rằng ông cũng không thích một vài puzzle trong Braid), nên tôi sẽ không ngại spoil để giải thích.
Trong Braid, nhân vật chính Tim có khả năng điều khiển và tua ngược thời gian, và đó cũng là công cụ duy nhất mà bạn có để giải các puzzle trong game. Mỗi một world trong game sẽ có một số các mảnh ghép jigsaw nằm rải rác ở khắp nơi và bạn sẽ cần phải giải puzzle để lấy được chúng. Sau khi đã thu hồi đủ số mảnh ghép, bạn sẽ làm một puzzle jigsaw khá đơn giản như puzzle trên hình để lấy được ngôi sao.
Tuy vậy, như bạn có thể thấy như trong hình, đó là ở bên cạnh bảng puzzle jigsaw này có một platform nữa để dẫn đến mảnh ghép cuối cùng, và bạn không thể đứng ở platform bên trái mà nhảy sang được. Cách duy nhất để bạn có thể giải được puzzle này là sắp xếp các mảnh jigsaw giống như sau.
Sự thực là khi chẳng may tìm ra được đáp án cho puzzle này, tôi không thấy thoải mái một chút nào, mặc dù tất cả những dữ liệu hay những công cụ để giải puzzle đều nằm ở đó và tôi không phải đi đâu khác cả. Nhưng tôi khó chịu là bởi logic (hay là sự phản logic vật lý thông thường) của nó nằm ngoài hoàn toàn so với ngôn ngữ puzzle của Braid mà tôi vẫn biết từ đầu game đến giờ, do đó tôi không thể nào quan sát puzzle này với đúng góc nhìn và sử dụng những dữ liệu đó đúng cách được. Vì thế ở đây ta hiểu rằng:
Khối lượng dữ liệu có thể đã đủ, chất lượng dữ liệu có thể đã tốt, nhưng ngữ cảnh hay cách truyền tải dữ liệu cũng là rất quan trọng để game designer giao tiếp với người chơi.
Tổng kết lại, chúng ta có ba tiêu chí hay là ba câu hỏi cơ bản cần phải đặt ra khi thiết kế một puzzle:
Liệu lượng dữ liệu này có nhiều quá hay không? Bởi nếu nhiều, có thể ta sẽ cần phải chia nhỏ puzzle ra thành các bước nhỏ hơn. Tuy nhiên cũng cần lưu ý ở đây rằng, khối lượng dữ liệu không đồng nghĩa với độ khó. Chỉ đơn giản bởi vì bạn đang thiết kế một puzzle ở nửa sau của game của bạn, không có nghĩa là bạn được quyền phạm phải lỗi infodumping.
Liệu chất lượng dữ liệu của mình đã tối ưu hay chưa? Đừng ngại thẳng tay cắt giảm toàn bộ những yếu tố bạn cảm thấy có thể trở thành nhiễu (noise) làm cản trở mạch suy nghĩ của người chơi. Hãy nhờ tester hoặc bạn bè thử nghiệm thật nhiều để hiểu rõ.
Liệu cách truyền tải của mình đã hợp lý hay chưa? Liệu mạch logic của puzzle này có đồng nhất hay liệu người chơi có thể tạo ra mối liên hệ logic từ ngôn ngữ puzzle chung của game tới bản thân puzzle này hay không?
Trong phần này, chúng ta mới chỉ nhắc đến những tiêu chí cơ bản khi thiết kế puzzle, và tất cả đều có liên quan đến dữ liệu đầu vào. Trong phần sau, chúng ta sẽ đi sâu hơn vào những tiêu chí nâng cao và trừu tượng hơn để đảm bảo chất lượng của một game puzzle, thay vì chỉ có một puzzle riêng lẻ.
Comentários