คุณจะรับข้อมูลที่เป็นประโยชน์จาก playtesters ได้อย่างไร [ปิด]

มีข้อเสนอแนะบางประเภทที่คุณสามารถรับได้จาก playtesters และฉันสงสัยว่าจะรวบรวมข้อมูลสำหรับแต่ละรายการได้ดีที่สุดอย่างไร ...

1. รายงานข้อขัดข้อง เมื่อเกม C ++ ของฉันล้มเหลวในขณะที่บางคนกำลังเล่นอยู่ฉันจะทำอย่างไรดีที่สุดเพื่อให้แน่ใจว่าฉันรู้เกี่ยวกับมันและดียิ่งขึ้น ... เกิดอะไรขึ้น แม้การรับบางอย่างง่าย ๆ เช่นไฟล์และหมายเลขบรรทัดที่ทำให้เกิดความผิดพลาดจะเป็นประโยชน์อย่างไม่น่าเชื่อ

2. ผลตอบรับการออกแบบ เมื่อผู้ทดสอบการเล่นกำลังเล่นเกมฉันจะทราบได้อย่างไรว่าพวกเขากำลังสนุกทำไมพวกเขาถึงสนุกทำไมพวกเขาถึงไม่สนุกและสิ่งที่เราควรใช้เวลาปรับตัว

ฉันสมมติว่าคุณกำลังพูดถึงผู้เล่นในสถานที่ไม่ใช่ผู้ทดสอบเบต้าอินเทอร์เน็ต

กฎ # 1: ไม่ได้ช่วยให้พวกเขา แห้วควรเป็นสิ่งที่คุณควรตรวจสอบ สถานการณ์ในอุดมคติจะเป็นกระจกสองทางกับทีมของคุณในด้านหนึ่งและ playtester ที่อีกตัวหนึ่งด้วยกล้องวิดีโอตัวหนึ่งบนใบหน้าของพวกเขาและอีกตัวบนหน้าจอ เห็นได้ชัดว่านี่เป็นไปไม่ได้สำหรับคนส่วนใหญ่ดังนั้นทำดีที่สุดที่คุณสามารถ เพียงแค่ให้นักออกแบบของคุณนั่งดูว่าผู้คนติดอยู่แค่ไหนก็เป็นข้อมูลที่มีประโยชน์มาก คุณจะไม่ยืนอยู่เหนือไหล่ของพวกเขาเมื่อพวกเขานำเกมกลับบ้านดังนั้นคุณจึงให้คำแนะนำเกี่ยวกับวิธีการส่งผ่านบางส่วนจะไม่ให้ข้อมูลที่คุณต้องการ แก้ไข : อีกวิธีในการวางคือ: อย่าคิดว่าพวกเขา "เล่นผิด"

กฎข้อที่ 2: ไม่ให้พวกเขาสิ่งที่พวกเขาต้องการ หลังจากเซสชั่นการทดสอบคุณมีแบบสอบถามชนิดหนึ่งที่พวกเขากรอก คำแนะนำเฉพาะที่พวกเขามักจะไม่ฉลาดที่จะรับค่าใบหน้า มักจะมีสาเหตุบางอย่างที่ก่อให้เกิดการตอบสนองมากที่สุดและพวกเขาก็ไม่รู้วิธีการแสดงออก หากคุณสามารถเข้าใจได้คุณจะทำได้ดีกว่า แม้ว่าในขณะนี้ฉันมีปัญหาในการหาตัวอย่างที่เฉพาะเจาะจง

กฎข้อที่ 3: ข้อมูลเป็นกษัตริย์ หากคุณสามารถ (และนี่เป็นรายการสิ่งที่อยากได้อีกรายการหนึ่งจริงๆแล้ว) ติดตามทุกสิ่งที่คุณทำได้ ติดตามตำแหน่งที่ผู้เล่นตาย ติดตามตำแหน่งที่พวกเขาวิ่งออกมาจากกระสุนจากปืนที่เฉพาะเจาะจง ติดตามสิ่งที่พวกเขาพลาดโชค ติดตามการอัพเกรดที่พวกเขาซื้อ ติดตามสิ่งที่ศัตรูสร้างความเสียหายให้กับพวกเขา เห็นได้ชัดว่านี่เป็นตัวอย่างเฉพาะของ FPS แต่ฉันแน่ใจว่ามีโดเมนเฉพาะสำหรับเกมที่คุณกำลังทำ หากทุกคนทำบางสิ่งบางอย่างหรือไม่ทำอะไรบางอย่างมักจะเป็นพื้นที่ที่คุณควรใช้เวลาดูอีกหน่อย

โดยพื้นฐานแล้วคุณไม่สนใจว่าผู้เล่นคิดอย่างไร คุณดูแลเกี่ยวกับการรับตัวเลขดิบสำหรับสิ่งที่ผู้เล่นทำ คุณต้องมีดวงตาที่บริสุทธิ์เพื่อดูเกมของคุณและบอกคุณในสิ่งที่ทำให้พวกเขาผิดหวังและสิ่งที่พวกเขากำลังถูกนำไปทำ

สำหรับการเกิดปัญหาในการตรวจสอบminidumps มันไม่ได้สมบูรณ์แบบ แต่เป็นเครื่องมือที่มีประโยชน์มากในการหาจุดที่เกิดปัญหา

พิจารณาเครื่องมือการรายงานบั๊กในตัวด้วย บางสิ่งที่ผู้ใช้สามารถจับภาพหน้าจอเพิ่มคำอธิบายและส่งอีเมลถึงใครบางคนโดยอัตโนมัติจากภายในเกม เป็นการดีที่มีสแนปช็อตของโลก (เช่นบันทึกอย่างรวดเร็วหรือการถ่ายโอนข้อมูลหน่วยความจำบางชนิด) หากเกมของคุณรองรับ

หากต้องการขยายข้อมูลเป็นความเชื่อมั่นของกษัตริย์เล็กน้อย (+1 ถึง Tetrad!):

ตรวจสอบการบันทึกและการเล่น :

• หากเกมของคุณถูกกำหนดไว้ล่วงหน้าและอิงกับเฟรมคุณอาจต้องเก็บเมล็ดเริ่มต้นแบบสุ่มเท่านั้นและจะมีการอัปโหลดเมื่อ(key/button state, joystick/mouse coords, frame #)ใดก็ได้ที่สถานะอินพุตเปลี่ยนแปลง การเล่นนั้นง่ายเหมือนการเปลี่ยนเส้นทางอินพุตของคุณไปยังสตรีมนี้ (เราเคยทำสิ่งนี้กับเกมกระโดดแพลตฟอร์มหลายครั้งในอดีต)
• หากเกมของคุณมี API หรือระบบข้อความที่กำหนดไว้อย่างดีสำหรับการดำเนินการ (เกมวางแผนแบบเลี้ยว, เกมไพ่, เกมกระดานหรือสิ่งที่คล้ายกัน) คุณอาจจะสามารถเก็บเกี่ยวการโทรหรือข้อความ API ที่จุดใดจุดหนึ่ง . (เราทำสิ่งนี้เพื่อเกมไพ่สำหรับแพลตฟอร์มมือถือ)
• มันยากขึ้นในบางระบบ (ระบบที่กำหนดน้อยลง, เป็นเกลียวหรือระบบกำหนดเวลาโดยพลการอาจเป็นความเจ็บปวด) แต่มันก็คุ้มค่าที่จะบันทึกข้อมูลต่อไป คุณสามารถรับผลลัพธ์ "ใกล้พอ" สำหรับการใช้งานบางอย่าง

ระบบ "เล่นซ้ำ" ตามวิธีการเหล่านี้มีข้อดีมากมาย:

• ใช้มันเพื่อทำซ้ำการล่มในการดีบักหรือสร้างหรือสภาพแวดล้อมที่ใช้เครื่องมือ
• โหลดรีเลย์ภายใต้บิลด์โปรไฟล์และรับข้อมูลประสิทธิภาพหรือการใช้ทรัพยากร
• โยงเข้าสู่เกมเพื่อให้ฟังก์ชั่น "เล่นซ้ำทันที" อาจมีกล้องหรือขั้นตอนเวลาอื่น
• ตั้งค่าการสาธิตการเล่นเกม "โหมดดึงดูด" หากผู้ใช้ทำงานโดยไม่ทำอะไรเลยบนเมนู
• วางไว้ในระบบการสร้างของคุณเป็นการทดสอบควัน: ถ้าฉันสามารถเล่นรีเพลย์นี้ได้โดยไม่ต้องหยุดทำงานมันน่าจะเป็นงานสร้างที่ดีกว่า
• ดูตัวอย่างของคนที่เล่นเพื่อดูสิ่งที่พวกเขาทำและไม่ได้ทำ

ต่อสายเข้าแบบสุ่มแทนที่จะสตรีมที่บันทึกไว้และคุณจะได้รับการทดสอบลิงที่ยอดเยี่ยมซึ่งคุณสามารถปล่อยให้แช่ค้างคืนหรือเมื่อใดก็ตามที่เครื่องจักรของคุณไม่ได้ทำงาน

ถัดไปทำบางบันทึกเหตุการณ์ สำหรับ FPS สมมุติเริ่มต้นด้วยบางสิ่งเช่น "เวลา T: X ฆ่า Y ที่จุด Z ด้วยอาวุธ W": ใส่มันลงในบันทึก

เมื่อคุณมีข้อมูลบางส่วนถูกเก็บรวบรวมตัวเลขวิธีการทำงานโดยอัตโนมัติคอลเลกชัน มันไม่จำเป็นต้องสวยงามในระหว่างการพัฒนา:

• เชื่อมต่อกับเซิร์ฟเวอร์ SQL และแทรกแถว
• เริ่มต้นและลืมแพ็กเก็ต UDP ที่เซิร์ฟเวอร์ syslog-ish ง่ายๆ
• ส่งอีเมลบันทึกในครั้งต่อไปที่เกมบู๊ต
• เพียงห่อไฟล์ปฏิบัติการในเชลล์สคริปต์หรือไฟล์แบตช์ที่เปลี่ยนชื่อและคัดลอกไฟล์. log ไปยังไดรฟ์ที่ใช้ร่วมกันทั่วไป
• (ภายหลังสำหรับบิลด์การผลิต) ใช้การรายงานข้อผิดพลาดของ Windows หรือบริการที่คล้ายกันเพื่อรวบรวมข้อมูลความขัดข้อง ...

ไม่สำคัญหรอกตราบใดที่คุณสามารถรวบรวมข้อมูลได้

ตอนนี้ขยาย: รวบรวมการทิ้งความผิดพลาด, การติดตามสแต็กและอินพุตหรือการบันทึกเหตุการณ์ เพิ่มกิจกรรมเพิ่มเติมและแหล่งข้อมูลเพิ่มเติม:

• ตัวอย่างตำแหน่งผู้เล่นหรือมือทุก ๆ 10 วินาทีวางลงบนแผนที่ - "เฮ้ไม่มีใครใช้มุมนี้ที่ฉันใช้เวลาหนึ่งสัปดาห์ในการสร้างแบบจำลองเวลาที่จะทำให้มีพลัง"
• getFreeMemoryBytes() ทุกครึ่งนาที
• getFPS() เป็นระยะ ๆ
• ถ่ายภาพหรือวิดีโอสิ่งที่ผู้ใช้ทำผ่านเว็บแคม (เหมาะสำหรับการทดสอบการใช้งานอัตโนมัติ - เฉพาะเมื่อได้รับอนุญาตจากผู้ใช้และเข้าใจแน่นอน)
• คว้าข้อมูลระบบ (อีกครั้งด้วยการอนุญาตจากผู้ใช้)

สิ่งที่ "พล็อตมันลงบนแผนที่" นั้นยอดเยี่ยมมาก ๆ หลังจากผ่านไประยะหนึ่ง: มองเห็นภาพมุมมองทางอากาศของแผนที่ RTS หรือ FPS วางแถบเลื่อนเพื่อแสดงเวลาตั้งแต่เริ่มเกม เลือกประเภทเหตุการณ์ ("ได้ทอง", "ฆ่าใครซักคน", อะไรก็ได้) เลือกชุดข้อมูล: อาจเป็นหนึ่งเกมอาจจะ 500 เกมในช่วงไม่กี่เดือนที่ผ่านมา เริ่มดึงตัวเลื่อนไปทางขวาและดูกิจกรรมที่ปรากฏบนแผนที่

และถ้าคุณไม่สามารถหา libs ที่ดีที่จะช่วยคุณได้ (มีอยู่ไม่กี่ที่นี่และที่นั่น!) ให้พิจารณาการหมุนของคุณเอง: มันเป็นประสบการณ์การเรียนรู้ที่ดีและไม่จำเป็นต้องสวยงามเป็นพิเศษ ที่จะเป็นประโยชน์

รับข้อมูลคุณจะทราบว่าจะทำอย่างไรกับมัน =)

แน่นอนว่าเรื่องนี้ขึ้นอยู่กับ ... ก) คุณต้องการทดสอบแบบไหนและข) เกมประเภทใดที่คุณกำลังทดสอบและค) ผู้ทดสอบและโครงสร้างพื้นฐานประเภทใดที่คุณมี ...

นอกจากนี้ยังแตกต่างกันมากถ้าคุณทดสอบ a) ฟังก์ชัน b) ปรับสมดุล c) ออกแบบเกม

แต่โดยทั่วไปคุณอาจต้องการพิจารณาประเด็นเหล่านี้ ...

* a) เลือกบุคคลที่เหมาะสมสำหรับงาน ฟังดูง่ายเกินไปที่จะพูดถึง แต่ฉันเคยเห็นมาหลายครั้งแล้วและเพิ่งเห็นมันกลับมามีชีวิตอีกครั้ง และเช่นเคยมีความแตกต่างอย่างมีนัยสำคัญระหว่างผู้คนในเรื่องที่ว่าพวกเขามีงานที่ดีต่างกันอย่างไร บางคนที่เต็มใจหรือกระตือรือร้นที่จะทำการทดสอบอาจไม่ได้เล่นอย่างละเอียดพอที่จะหาข้อผิดพลาด (หรือแม้แต่ง่าย) บางคนไม่สามารถอธิบายข้อบกพร่องได้ดี บางคนทดสอบการทรงตัวได้ดีขึ้นบางคนสนใจจุดอ่อนทางสายตามากขึ้นบางคนมีความคิดสร้างสรรค์มากขึ้นในการเล่นเกมด้วยวิธีที่ผิดปกติและค้นหาข้อผิดพลาดที่ซ่อน / หายากบางคนมีความใส่ใจในด้านเทคนิค ของเกมช่างและอาจแนะนำการเปลี่ยนแปลงที่มีความหมาย (ถ้าคุณต้องการให้ผู้ทดสอบทำอย่างนั้น)

* b) ใช้ซอฟต์แวร์ Issue-Tracker / Bug-Tracker เครื่องมือเหล่านี้ไม่เพียง แต่ช่วยในการจัดการปัญหาของคุณ แต่ยังช่วยในการเพิ่มคุณภาพของผลลัพธ์ของผู้ทดสอบของคุณด้วยการให้เฟรมทำงานภายในและโดยการเรียนรู้จากผลตอบรับ จากนักพัฒนาเกี่ยวกับปัญหาของพวกเขา ช่วยในการปรับปรุงคุณภาพของผลลัพธ์ของผู้ทดสอบของคุณเร็วกว่ามากถ้าคุณไม่ทำงาน (มันยังช่วยได้มากกับผู้ทดสอบระยะไกล) ซอฟต์แวร์ทั่วไปที่ใช้โดยสตูดิโอเกมคือ Mantis, JIRA, (และอื่น ๆ อีกมากมาย .. ) ดูWikipediaสำหรับรายการทั่วไปและโพสต์นี้ใน SO

c) เพิ่มเครื่องมือทดสอบในเกม โดยทั่วไปคือทางลัดเพื่อทดสอบระดับหรือส่วนเฉพาะของเกม การแสดงข้อมูลพิเศษระหว่างเกมไปยังผู้ทดสอบเพื่อให้พวกเขาสามารถเพิ่มสิ่งนี้ลงในรายงานข้อผิดพลาด นี่อาจเป็นตำแหน่งในระดับจำนวนวัตถุที่ใช้งานในฉากปริมาณของ ram-texture หรือจานสีที่ใช้อยู่ในปัจจุบันสิ่งใดที่เป็นประโยชน์ต่อนักพัฒนา

d) รวมผู้ทดสอบที่มีประสบการณ์กับเลือดสด เป็นสิ่งที่ดีเสมอที่จะมีผู้ทดสอบที่มีประสบการณ์มากกับเกมของคุณและได้เรียนรู้ว่าปัญหาทั่วไปคืออะไรและจะทดสอบพวกเขาอย่างไร ในเวลาเดียวกันคุณต้องการผู้เล่นใหม่ที่ "บริสุทธิ์" นาน ๆ ครั้งโดยเฉพาะอย่างยิ่งสำหรับการทรงตัว

e) มีผู้จัดการทดสอบ คนที่ประสานกระบวนการและปรับให้เข้ากับเกมในมือลำดับความสำคัญปัจจุบันและผู้ทดสอบและสภาพแวดล้อมการทดสอบที่พร้อมใช้งาน

f) มีเอกสาร Testplan ซึ่งจะคุ้มค่ากับการโพสต์เพิ่มเติม

ดังที่ Tetrad กล่าวไว้รับข้อมูลเป้าหมายให้ได้มากที่สุด การใส่ hooks เพื่อจัดเก็บเหตุการณ์บางอย่างและถ่ายโอนข้อมูลทั้งหมดไปยัง. csv นั้นไม่ใช่เรื่องยาก และเมื่อคุณได้รับมันใน Excel คุณสามารถเรียนรู้กราฟและพล็อตจนกว่าวัวจะกลับบ้าน

นอกจากนี้มีคำถามเฉพาะที่คุณต้องการตอบ นักวิทยาศาสตร์ไม่เพียง แต่นั่งลงทำการทดลองและ "ทำวิทยาศาสตร์" พวกเขามีคำถามที่เฉพาะเจาะจงและสามารถวัดได้ที่พวกเขาต้องการข้อมูลเกี่ยวกับ คุณมักจะได้รับประโยชน์สูงสุดจากการทดสอบถ้าคุณใช้วิธีการเดียวกัน พยายามคิดว่าเกมของคุณ "ดี" ยากที่จะหาจำนวน แต่การหาคำตอบว่าภารกิจการสอนที่เรียบง่ายใช้เวลาเพียง 5 นาทีที่คุณคาดหวังหรือหากผู้ทดสอบกำลังดิ้นรนเพื่อไขปริศนาบางอย่างสามารถประเมินได้จริง

บางครั้งวิธีที่มีประสิทธิภาพที่สุดในการทดสอบก็คือเกิดการระเบิดสั้น ๆ ให้ผู้ทดสอบสองสามคนไปหนึ่งชั่วโมงหรือมากกว่านั้นในตอนเช้าทำการเปลี่ยนแปลงบางอย่างเกี่ยวกับปัญหาที่พวกเขาระบุและกลับไปอีกครั้งกับผู้ทดสอบใหม่ในเช้าวันรุ่งขึ้น เห็นได้ชัดว่าคุณต้องดูที่คุณสมบัติเล็กพอที่จะปรับปรุงในช่วงบ่าย แต่สำหรับปัญหาที่หัวแข็งโดยเฉพาะวิธีนี้สามารถประสบความสำเร็จมาก

เห็นด้วยแน่นอนกับกฎของ Tetrad # 1 อย่าช่วยพวกเขา ฉันจะบอกว่าข้อแม้คือการอธิบายให้พวกเขาทราบว่าคุณจะไม่ช่วยพวกเขาและหากพวกเขาต้องการความช่วยเหลือโปรดถาม วิธีนี้ทำให้ผู้เล่นไม่ต้องหงุดหงิด

แบบสอบถามควรถามคำถามปลายเปิดแทนคำถามที่ตอบว่าใช่ / ไม่ใช่ง่ายขึ้นอยู่กับอายุและจำนวนผู้ทดสอบสิ่งเหล่านี้อาจเป็นแบบฟอร์มที่กรอกหรือคุณสามารถถามคำถามได้ สิ่งสำคัญคือต้องถามคำถามเกี่ยวกับประวัติและความคุ้นเคยกับประเภทของเกมที่คุณกำลังทดสอบ สิ่งนี้จะเพิ่มบริบทให้กับคำตอบเฉพาะเกี่ยวกับเกมของคุณ

โชคดีที่เกมของฉันล่มมันทำให้ฉันมีข้อมูลที่เกี่ยวกับข้อผิดพลาดดังนั้นฉันสามารถถ่ายรูปและจดบันทึกสิ่งที่ผู้เล่นทำ โดยปกติฉันจะทดสอบกลุ่มอายุน้อยกว่าดังนั้นเมื่อเราเกิดข้อผิดพลาดฉันต้องจำไว้ว่าให้อธิบายว่าพวกเขากำลังทำผลงานได้ดีมาก - พวกเขาจะอารมณ์เสียหลังจากที่เลิกเล่นเกม นักเล่นเกมได้พิสูจน์แล้วว่าเป็นเกมที่ยอดเยี่ยมในการค้นหาข้อบกพร่องที่ไม่ชัดเจนซึ่งทีมพัฒนาจะไม่เล่นเกมด้วยวิธีที่ "ถูกต้อง"

เป็นไปได้ที่จะเขียนโค้ดที่จับข้อขัดข้องและบันทึกการโทรสแต็ค ที่สามารถช่วยได้มากกับรายงานบั๊ก การสร้างไฟล์บันทึกที่มีประโยชน์ก็ช่วยได้เช่นกัน คุณสามารถแจ้งให้ผู้ใช้ส่งไฟล์เหล่านี้ในครั้งต่อไปที่พวกเขาเล่นหรือมีเครื่องมือแบบสแตนด์อโลนที่ทำงานหลังจากเกมถูกปิดหรือหยุดทำงานหากคุณต้องการ

สำหรับรายงานข้อขัดข้องคุณควรใช้เจ้าหน้าที่ QA ที่ชำระเงินไม่ใช่ playtesters QA คือคนที่คุณจ้างมาโดยเฉพาะสำหรับความสามารถในการค้นหาข้อบกพร่องและรายงานพวกเขาด้วยวิธีการที่มีความหมายและผู้ทดสอบที่ดีมีค่าน้ำหนักของพวกเขาในทองคำ (และค่าใช้จ่ายเพียงหนึ่งในสิบ

หากคุณกังวลว่า "โอ้จะเกิดอะไรขึ้นถ้าพวกเขาค้นพบความผิดพลาดโดยไม่ตั้งใจเราไม่อยากพลาดเพราะพวกเขาไม่ได้ทดสอบสิ่งนั้น" ... นี่คือสิ่งที่บันทึกไว้ ระบบการบันทึกที่ดีอย่างเพียงพอควรบันทึกองค์ประกอบการเล่นที่เพียงพอเพื่อให้สามารถทำซ้ำได้อย่างแม่นยำ

สำหรับข้อเสนอแนะด้านการออกแบบนั้นไม่มีสิ่งใดทดแทนการให้นักออกแบบเกมของคุณดูพวกเขาเล่นจริง ๆ (หรือใช้เครื่องบันทึกวิดีโอหากคุณต้องการ ฯลฯ ) อย่าพึ่งพาความทรงจำหรือความคิดเห็นของ playtester ซึ่งทั้งสองอย่างนี้มีชื่อเสียงไม่ดี แต่ถ้าคุณกำลังดูพวกเขาเล่นแบบเรียลไทม์มันก็ชัดเจนชัดแจ้งเพียงแค่ดูท่าทางใบหน้าและร่างกายของพวกเขาไม่ว่าพวกเขาจะหมั้นเบื่อหรือหงุดหงิด