Làm thế nào để bạn có được dữ liệu hữu ích từ playtesters? [đóng cửa]

Có một số loại phản hồi bạn có thể nhận được từ người chơi và tôi tự hỏi làm thế nào để thu thập dữ liệu tốt nhất cho từng người trong số họ ...

1. Báo cáo sự cố. Khi trò chơi C ++ của tôi gặp sự cố trong khi ai đó đang chơi nó, làm thế nào tốt nhất để tôi chắc chắn rằng tôi biết về nó và thậm chí tốt hơn ... điều gì đã gây ra nó? Ngay cả việc nhận được một cái gì đó đơn giản như tập tin và số dòng gây ra sự cố cũng sẽ vô cùng hữu ích.

2. Thiết kế Phản hồi. Khi một người thử chơi đang chơi trò chơi, làm thế nào tôi có thể biết được họ có vui không, tại sao họ lại vui, tại sao họ không vui, và chúng ta nên dành thời gian để điều chỉnh?

Tôi cho rằng bạn đang nói về những người chơi tại chỗ chứ không phải những người thử nghiệm bản beta trên internet.

Quy tắc số 1: Đừng giúp đỡ họ . Thất vọng nên là điều hàng đầu bạn nên kiểm tra. Tình huống lý tưởng sẽ là một tấm gương hai chiều với đội của bạn ở một bên và người chơi ở một bên khác với một máy quay video trên mặt và một cái khác trên màn hình. Rõ ràng điều này không khả thi đối với hầu hết mọi người, vì vậy hãy làm tốt nhất có thể. Chỉ cần có nhà thiết kế của bạn ngồi và xem nơi mọi người bị mắc kẹt là thông tin rất hữu ích. Bạn sẽ không đứng trên vai họ khi họ mang trò chơi về nhà, vì vậy bạn đưa ra lời khuyên về cách vượt qua một số phần nhất định sẽ không cung cấp cho bạn thông tin bạn cần. Chỉnh sửa : một cách khác để đặt nó là thế này: Đừng nghĩ rằng họ "Chơi sai"

Quy tắc số 2: Đừng cho họ những gì họ muốn . Sau một buổi playtest, bạn có một số câu hỏi mà họ điền vào. Các đề xuất cụ thể mà họ có thường không khôn ngoan để thực hiện theo mệnh giá. Thông thường có một số nguyên nhân gốc rễ gây ra hầu hết các phản hồi và họ chỉ không biết cách thể hiện nó. Nếu bạn có thể tìm ra điều đó, bạn sẽ tốt hơn khi làm điều đó. Mặc dù hiện tại tôi đang gặp khó khăn với các ví dụ cụ thể.

Quy tắc số 3: Dữ liệu là vua . Nếu bạn có thể (và đây thực sự là một mục danh sách mong muốn khác, thành thật), hãy theo dõi mọi thứ bạn có thể. Theo dõi nơi người chơi chết. Theo dõi nơi họ hết đạn từ một khẩu súng cụ thể. Theo dõi những gì họ chọn bỏ lỡ. Theo dõi những nâng cấp họ mua. Theo dõi những gì kẻ thù gây thiệt hại cho họ. Rõ ràng đây là những ví dụ dành riêng cho FPS, nhưng tôi chắc chắn có những ví dụ cụ thể về tên miền cho bất kỳ trò chơi nào bạn đang làm. Nếu mọi người đang làm gì đó hoặc không làm gì đó, đó thường là những lĩnh vực mà bạn nên dành thêm một chút thời gian để xem xét.

Về cơ bản, bạn không quan tâm người chơi nghĩ gì . Bạn quan tâm đến việc lấy số nguyên cho những gì người chơi làm . Bạn cần đôi mắt trinh nguyên để xem trò chơi của bạn và cho bạn biết điều gì khiến họ thất vọng và những gì họ đang được dẫn dắt để làm.

Đối với các sự cố, điều tra minidumps . Chúng không hoàn hảo, nhưng là một công cụ rất hữu ích để tìm ra nơi xảy ra sự cố.

Cũng xem xét một công cụ báo cáo lỗi tích hợp. Một cái gì đó mà người dùng có thể chụp ảnh màn hình, thêm mô tả và gửi email cho ai đó tự động từ bên trong trò chơi. Lý tưởng nhất là một ảnh chụp nhanh về thế giới (ví dụ quicksave hoặc một số loại bộ nhớ) nếu trò chơi của bạn hỗ trợ nó.

Để mở rộng dữ liệu là tình cảm của vua một chút (+1 đến Tetrad!):

Điều tra ghi âm và phát lại :

• Nếu trò chơi của bạn mang tính quyết định và dựa trên khung, bạn có thể chỉ cần lưu trữ một hạt giống ngẫu nhiên ban đầu và một tuple (key/button state, joystick/mouse coords, frame #)bất cứ khi nào trạng thái đầu vào thay đổi. Phát lại đơn giản như chuyển hướng đầu vào của bạn đến luồng này. (Chúng tôi đã làm điều này cho nhiều trò chơi nhảy nền tảng trong quá khứ.)
• Nếu trò chơi của bạn có các API hoặc hệ thống thông báo được xác định rõ để thực hiện các hành động (trò chơi chiến lược theo lượt, trò chơi bài, trò chơi trên bàn hoặc tương tự), bạn có thể chỉ cần thu thập các cuộc gọi hoặc tin nhắn API tại một điểm nhất định . (Chúng tôi đã làm điều này cho một trò chơi bài cho một nền tảng cầm tay.)
• Nó khó hơn trên một số hệ thống (hệ thống dấu thời gian ít xác định, có luồng hoặc tùy ý có thể là một nỗi đau) nhưng dù sao nó cũng có thể đáng ghi lại dữ liệu; bạn có thể nhận được kết quả "đủ gần" cho một số mục đích sử dụng.

Một hệ thống "phát lại" dựa trên các phương pháp này có rất nhiều ưu điểm:

• sử dụng nó để tái tạo các sự cố trong gỡ lỗi hoặc xây dựng hoặc môi trường cụ thể;
• tải phát lại dưới một bản dựng hồ sơ và nhận dữ liệu hiệu suất hoặc sử dụng tài nguyên;
• kết nối nó vào trò chơi để cung cấp chức năng "phát lại tức thì", có thể bằng một máy ảnh hoặc bước thời gian khác;
• thiết lập một trò chơi demo "chế độ thu hút" nếu người dùng không muốn làm gì trên menu;
• đưa nó vào hệ thống xây dựng của bạn dưới dạng thử nghiệm khói: nếu tôi có thể chơi qua bản phát lại này mà không gặp sự cố, nhiều khả năng đó là bản dựng tốt;
• xem các ví dụ về những người chơi để xem những gì họ đã làm và không làm.

Nối dây trong đầu vào ngẫu nhiên thay vì luồng được ghi lại và bạn đã có một bài kiểm tra khỉ tuyệt vời rằng bạn có thể để ngâm qua đêm hoặc bất cứ khi nào máy phát triển của bạn không hoạt động.

Tiếp theo, làm một số ghi sự kiện . Đối với một FPS giả định, hãy bắt đầu với một cái gì đó như "thời gian T: X giết Y tại điểm Z bằng vũ khí W": đưa nó vào nhật ký.

Khi bạn có một số dữ liệu được thu thập, hãy tìm cách tự động hóa bộ sưu tập . Nó không cần phải thanh lịch trong quá trình phát triển:

• kết nối với máy chủ SQL và chèn các hàng,
• cháy và quên các gói UDP tại một số máy chủ syslog-ish đơn giản,
• e-mail nhật ký lần sau khi trò chơi khởi động,
• chỉ cần bọc tệp thực thi trong tập lệnh shell hoặc tệp bó để đổi tên và sao chép tệp .log vào ổ đĩa chung,
• (sau này, đối với các bản dựng sản xuất) sử dụng Báo cáo Lỗi Windows hoặc một dịch vụ tương tự để thu thập dữ liệu sự cố ...

Không thực sự quan trọng, miễn là bạn có thể thu thập dữ liệu.

Bây giờ mở rộng nó: thu thập các bãi đổ vỡ, dấu vết ngăn xếp và ghi lại đầu vào hoặc sự kiện. Thêm nhiều sự kiện và nhiều nguồn dữ liệu hơn:

• lấy mẫu vị trí hoặc tay người chơi cứ sau 10 giây, vẽ nó trên bản đồ - "này, không ai sử dụng góc này mà tôi đã dành một tuần để tạo mô hình, thời gian để đặt một sức mạnh ở đó"
• getFreeMemoryBytes() cứ sau nửa phút
• getFPS() định kỳ
• chụp ảnh hoặc quay video về những gì người dùng đang thực hiện thông qua webcam (tuyệt vời để kiểm tra khả năng sử dụng tự động - tất nhiên chỉ với sự cho phép và hiểu biết của người dùng)
• lấy thông tin hệ thống (một lần nữa, với sự cho phép của người dùng)

Điều "vẽ nó trên bản đồ" có thể trở nên thực sự tuyệt vời sau một thời gian: hình dung ra một cái nhìn từ trên không của bản đồ RTS hoặc FPS. Đặt một thanh trượt trên đó, thể hiện thời gian kể từ khi bắt đầu trò chơi. Chọn một loại sự kiện ("có vàng", "giết ai đó", bất cứ điều gì). Chọn một bộ dữ liệu: có thể một trò chơi, có thể 500 trò chơi trong vài tháng qua. Bắt đầu kéo thanh trượt sang phải và xem hoạt động bật lên trên bản đồ.

Và nếu bạn không thể tìm thấy những lib tốt để giúp bạn với những thứ này (tuy nhiên có khá nhiều ở đây và đó!), Hãy cân nhắc việc tự lăn lộn: đó là một trải nghiệm học tập tốt, và nó không cần phải đặc biệt thanh lịch trở nên hữu ích

Nhận dữ liệu, bạn sẽ biết phải làm gì với nó. =)

Tất nhiên, điều này phụ thuộc rất nhiều vào ... a) loại thử nghiệm nào bạn muốn thực hiện và b) loại trò chơi nào bạn đang thử nghiệm và c) loại thử nghiệm và cơ sở hạ tầng nào bạn có sẵn ...

Nó cũng khác rất nhiều nếu bạn đang thử nghiệm a) chức năng, b) cân bằng c) thiết kế trò chơi

Nhưng nói chung, bạn có thể muốn xem xét các khía cạnh này ...

* a) Chọn đúng người cho công việc Nghe có vẻ quá đơn giản, nhưng tôi đã nhìn thấy nó nhiều lần và chỉ cần nhìn thấy nó sống lại. Như mọi khi, có sự khác biệt đáng kể giữa mọi người về việc họ làm việc tốt như thế nào. Một số người sẵn sàng hoặc có thể háo hức làm thử nghiệm có thể không chơi đủ kỹ lưỡng để tìm ra các lỗi bất thường (hoặc thậm chí đơn giản). Một số không giỏi trong việc mô tả các lỗi. Một số tốt hơn trong việc kiểm tra các vấn đề cân bằng, một số chú ý đến các điểm yếu về thị giác, một số sáng tạo hơn khi chơi trò chơi theo những cách khác thường và tìm ra các lỗi ẩn / hiếm, một số chú ý hơn đến chất lượng kỹ thuật hoặc hình ảnh, một số hiểu rõ hơn về các khía cạnh của cơ chế trò chơi và thậm chí có thể đề xuất các thay đổi có ý nghĩa (nếu bạn muốn người thử nghiệm của mình làm điều đó;).

* b) Sử dụng Phần mềm theo dõi sự cố / Trình theo dõi lỗi Các công cụ này không chỉ giúp tổ chức các vấn đề của bạn mà còn tăng chất lượng đầu ra của người kiểm tra bằng cách cung cấp cho họ một khung để làm việc trong và bằng cách học hỏi từ phản hồi họ nhận được từ các nhà phát triển về các vấn đề của họ. Nó giúp cải thiện chất lượng đầu ra của người kiểm tra của bạn nhanh hơn rất nhiều so với khi bạn làm việc mà không có nó. (Nó cũng giúp ích rất nhiều cho những người thử nghiệm từ xa) Phần mềm điển hình được sử dụng bởi các studio trò chơi là Mantis, JIRA, (và nhiều người khác ..) Xem Wikipedia để biết danh sách chung và cả bài đăng này trên SO.

c) Thêm các công cụ kiểm tra ingame Điển hình là Phím tắt để kiểm tra các cấp hoặc phần cụ thể của trò chơi. Hiển thị thêm thông tin trong trò chơi cho người kiểm tra để họ có thể thêm thông tin này vào bugreports. Đây có thể là vị trí trong một cấp độ, số lượng đối tượng hoạt động trong một cảnh, số lượng kết cấu ram hoặc bảng màu hiện đang sử dụng, bất cứ điều gì hữu ích cho các nhà phát triển.

d) Kết hợp những người thử nghiệm có kinh nghiệm với máu tươi Luôn là một điều tốt để có những người thử nghiệm rất có kinh nghiệm với trò chơi của bạn và đã tìm hiểu những vấn đề điển hình là gì và làm thế nào để kiểm tra lại chúng. Đồng thời bạn muốn người chơi "trinh tiết" mới thỉnh thoảng, đặc biệt là để cân bằng.

e) Có Trình quản lý kiểm tra Một người nào đó điều phối quy trình và điều chỉnh nó cho trò chơi trong tay, các ưu tiên hiện tại và các trình kiểm tra có sẵn và môi trường thử nghiệm.

f) Có một Tài liệu Testplan Điều này sẽ có giá trị thêm một bài.

Như Tetrad đã đề cập, hãy lấy càng nhiều dữ liệu khách quan càng tốt. Đặt các hook để lưu trữ các sự kiện nhất định và kết xuất tất cả các sự kiện đó vào .csv không quá khó. Và một khi bạn đã có nó trong Excel, bạn có thể nghiên cứu, vẽ biểu đồ và vẽ đồ thị cho đến khi những con bò về nhà.

Ngoài ra, có câu hỏi cụ thể mà bạn đang tìm cách trả lời. Các nhà khoa học không chỉ ngồi xuống, khởi động một số thí nghiệm và "làm khoa học". Họ có những câu hỏi cụ thể, có thể đo lường được mà họ muốn có dữ liệu. Bạn sẽ thường tận dụng tối đa lối chơi nếu bạn thực hiện cùng một cách tiếp cận. Cố gắng để tìm hiểu xem trò chơi của bạn là "tốt" là rất khó để định lượng. Nhưng tìm hiểu xem nhiệm vụ hướng dẫn đơn giản chỉ mất 5 phút bạn mong đợi, hoặc nếu những người thử nghiệm đang vật lộn để giải một câu đố nào đó, thực sự có thể được đánh giá.

Đôi khi, cách hiệu quả nhất để kiểm tra là lặp đi lặp lại trong các đợt ngắn. Có một vài người thử nghiệm đi trong một giờ hoặc lâu hơn vào buổi sáng, thực hiện một số thay đổi đối với các vấn đề họ xác định và đi lại với người thử nghiệm mới vào sáng hôm sau. Rõ ràng bạn phải xem xét một tính năng đủ nhỏ để cải thiện vào một buổi chiều. Nhưng đối với một vấn đề đặc biệt cứng đầu, phương pháp này có thể rất thành công.

Chắc chắn đồng ý với Quy tắc số 1 của Tetrad. Đừng giúp họ. Tôi muốn nói một lời cảnh báo là giải thích cho họ rằng bạn sẽ không giúp đỡ họ, và nếu họ cần giúp đỡ xin vui lòng hỏi. Bằng cách này, người chơi sẽ không bị thất vọng.

Bảng câu hỏi nên hỏi những câu hỏi kết thúc mở, thay vì những câu hỏi đơn giản có / không, tùy thuộc vào độ tuổi và số lượng người kiểm tra, đây có thể là những mẫu họ điền hoặc bạn có thể đặt câu hỏi. Nó cũng quan trọng để đặt câu hỏi về lịch sử của họ và sự quen thuộc của họ với thể loại trò chơi mà bạn đang kiểm tra chúng; điều này sẽ thêm bối cảnh vào câu trả lời cụ thể của họ về trò chơi của bạn.

May mắn là khi trò chơi của tôi gặp sự cố, nó cung cấp cho tôi rất nhiều thông tin liên quan đến lỗi, vì vậy tôi có thể chụp ảnh đó và ghi lại những gì người chơi đang làm. Thông thường tôi kiểm tra các nhóm tuổi trẻ hơn nên khi chúng tôi gặp sự cố, tôi phải nhớ giải thích cho họ rằng họ đang làm một công việc tuyệt vời - họ có thể buồn bã sau khi phá game. Playtesters đã thực sự được chứng minh là rất giỏi trong việc tìm ra các lỗi tối nghĩa mà nhóm nhà phát triển sẽ không bao giờ bắt gặp khi chơi trò chơi theo cách "đúng".

Có thể viết mã bắt các sự cố và ghi lại ngăn xếp cuộc gọi. Điều đó có thể giúp rất nhiều với các báo cáo lỗi. Có một tệp nhật ký hữu ích được tạo ra cũng giúp. Bạn có thể nhắc người dùng gửi các tệp này vào lần chơi tiếp theo hoặc có một công cụ độc lập chạy sau khi trò chơi bị đóng hoặc gặp sự cố nếu bạn muốn.

Đối với các báo cáo sự cố, bạn nên dựa vào nhân viên QA được trả lương, chứ không phải người chơi. QA là người mà bạn thuê đặc biệt vì khả năng tìm lỗi và báo cáo chúng một cách có ý nghĩa, và một người kiểm tra giỏi đáng giá vàng của họ (và chỉ bằng một phần mười trọng lượng của chúng so với vàng lập trình viên!).

Nếu bạn lo lắng về "ồ, nếu họ vô tình phát hiện ra sự cố, chúng tôi sẽ không muốn bỏ lỡ chỉ vì họ không kiểm tra điều đó" ... đây là việc đăng nhập để làm gì. Một hệ thống ghi nhật ký đủ tốt phải được ghi lại đủ các yếu tố chơi để có thể tái tạo chính xác sự cố.

Đối với phản hồi thiết kế, không có sự thay thế nào cho việc các nhà thiết kế trò chơi của bạn thực sự xem họ chơi (hoặc sử dụng máy quay video nếu bạn phải, v.v.). Đừng dựa vào trí nhớ hoặc ý kiến ​​của người chơi, cả hai đều nghèo nàn. Nhưng nếu bạn đang xem họ chơi trong thời gian thực, thì rõ ràng chỉ bằng cách nhìn vào khuôn mặt và tư thế cơ thể của họ cho dù họ đã đính hôn, buồn chán hay thất vọng.