คุณจะตัดสินใจได้อย่างไรว่ารายการคุณลักษณะของคุณจะยาวพอ?


10

ฉันรู้เล็กน้อยเกี่ยวกับคำถามนี้ แต่ฉันพบว่ามีความคิดเห็นที่หลากหลายในเรื่องนี้หรือไม่

ฉันรู้จากมุมมองของผู้เล่นว่ามีตัวเลือกเพิ่มขึ้นเกือบตลอดเวลา แต่ในทางกลับกันหากมีผู้เล่นหลายคนมากกว่าหมายถึงความซับซ้อนที่สูงขึ้น (เกมเมตา) ทั้งสำหรับนักพัฒนาและผู้เล่น

ในการพัฒนาความซับซ้อนและข้อ จำกัด เวลาเสมอไปจับมือ อีกข้อหนึ่งคือข้อ จำกัด ด้านทรัพยากรและแพลตฟอร์ม ความเป็นไปได้ทางเศรษฐกิจที่เป็นไปได้ในการถือครองภายหลังนั้นบางครั้งก็เป็นเหตุผล

ดังนั้นจากประสบการณ์ของผู้คนที่นี่นอกเหนือจากด้านบนเมื่อมีการตัดฟีเจอร์หรือการเปิดตัวในภายหลัง

คำตอบ:


13

ฉันว่ามันเป็นกระบวนการสองขั้นตอนสำหรับเรา:

  • กำหนดเป้าหมายของเกม
  • พิจารณาว่าคุณลักษณะใดช่วยให้เราบรรลุเป้าหมายเหล่านี้

รายการคุณลักษณะยาวพอเมื่อจุดทั้งสองนั้นตรงกัน ดังนั้น:

1. กำหนดเป้าหมายของเรา - คิดออกทุกสิ่งที่เราต้องการให้เกมทำเพื่อผู้เล่น / ผู้ตรวจสอบ / ผู้ใดก็ตามจากนั้นระบุให้พวกเขาวัดได้ ตัวอย่างเช่นด้วยล่าสุดของเรา ( ดูอัลฟาทดสอบที่นี่ ) เราต้องการทำสิ่งเหล่านี้:

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

2. ตรวจสอบคุณสมบัติที่ช่วยให้เราไปถึงเป้าหมายเหล่านั้น - สิ่งเหล่านี้เกือบจะหลุดออกมาจากข้างต้น ดังนั้นคุณสมบัติที่สอดคล้องกับตัวอย่างด้านบนอาจมีลักษณะเช่นนี้:

  • ภาพ:ในฐานะสตูดิโอขนาดเล็กถ้าเราต้องการภาพเซ็กซี่เราไม่สามารถสู้กับ EA หรือ Sony ในความสมจริง ดังนั้นเมื่อต้องการเข้าถึงเป้าหมายของภาพที่น่าทึ่งหนึ่งในคุณสมบัติของเกมคือความสวยงามที่เหนือจริง (จากนี้เราสามารถกำหนดเครื่องมือที่เราต้องการและอื่น ๆ )
  • การสำรวจ:เกร็ดความรู้กับการกระทำของเกมหลุดออกมาจากสิ่งนี้ ในบ้านเราชื่อล่าสุดเราลดลงการอ้างอิงที่รวดเร็วในการค้นหาที่น่าสงสัยเรียวสำหรับชาวเรือใน Shenmue มันเป็นเรื่องไร้สาระ แต่คนชอบและพูดคุยเกี่ยวกับมัน!
  • ชุมชน:เรากำลังถามตัวเองทุกวิธีในการสร้างเกมที่มีคุณค่าพูดถึงเพื่อน ทำให้สนุกเป็นอันดับ 1 แน่นอน แต่เราสามารถให้รางวัลผู้เล่นด้วยไอเท็มพิเศษหรือเลเวลหากพวกเขาทวีตเกี่ยวกับมัน Pokemon ทำให้มันคุ้มค่าในขณะที่ให้เพื่อนมารับเกม - มีสัตว์เลื้อยคลานบางตัวที่คุณสามารถทำได้โดยการติดต่อกับคนอื่น

เมื่อเราผ่านกระบวนการนี้จะช่วยให้เราพิจารณา:

  • เราต้องดำเนินการเท่าใดสำหรับผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำ ( MVP )
  • สิ่งที่สำคัญที่สุดสิ่งที่สามารถรอและสิ่งที่เราสามารถวางทั้งหมด
  • ในที่สุดเมื่อเรามีคุณสมบัติทั้งหมดที่เราต้องการ

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


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

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

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

14

ความซับซ้อนไม่ได้ทำให้เกมของคุณสนุก

การผสมผสานที่ลงตัวและความสมดุลขององค์ประกอบการเล่นเกมทำได้ ผู้เล่นจะต้องถูกผลักดันให้อยู่ในระดับทักษะและได้รับความรู้สึกเชี่ยวชาญจากการเอาชนะความท้าทาย

รายการคุณลักษณะของคุณควรเปลี่ยนเมื่อใดก็ตามที่คุณรู้สึกว่าการเล่นเกมในปัจจุบันไม่สนุก การเปลี่ยนแปลงเหล่านี้จะต้องทำภายในข้อ จำกัด ด้านงบประมาณ / เวลาของคุณ ตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงใด ๆ ที่คุณทำกับเกมของคุณ

นอกจากนี้ต้นแบบในช่วงต้นอย่าเพิ่งเขียนรายการคุณลักษณะขนาดใหญ่และคิดว่ามันจะสนุกเมื่อรวมกัน


1
ความซับซ้อนตามที่ตกลง! = ความลึก
lathomas64

และสำหรับความลึกของเรื่องนั้น! = ดีกว่าขึ้นอยู่กับว่าผู้เล่นของคุณคือใคร Candyland ไม่ใช่เกมที่ลึก แต่ลองสอนการเล่นหมากรุกให้กับเด็กสองขวบ

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

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

1
หากต้องการดำเนินการต่อ: บทความนี้มีส่วนที่ดีที่อธิบายถึงความตื่นเต้นของการสุ่ม lsvp.wordpress.com/2008/01/07/what-makes-games-fun
Nailer

6

ความสมบูรณ์แบบนั้นเกิดขึ้นได้ไม่ใช่เมื่อไม่มีอะไรจะเพิ่มเติมอีกต่อไป แต่เมื่อไม่มีอะไรเหลือให้เอาไป

- Antoine de Saint-Exupery


4

เมื่อเวลาและความพยายามที่จำเป็นในการรวมพวกเขามีค่ามากกว่าค่าที่พวกเขาเพิ่มเกม

ตัวอย่างเช่นหากคุณกำลังสร้างเกมกีฬาหรือสิ่งที่ผู้เล่นมีแนวโน้มที่จะต้องการแสดงทักษะของพวกเขาผู้เล่นหลายคนเป็นสิ่งจำเป็น Guitar Hero จะไม่เหมือนเดิมหากไม่มีมัน อย่างไรก็ตามเกมเพียงเกมเดียวที่คุณเริ่มต้นจนจบด้วยตัวคุณเองการติดตามเรื่องราวหรือโครงเรื่องไม่จำเป็นต้องมีผู้เล่นหลายคน ระบบผู้เล่นหลายคนที่แย่ใน Grand Theft Auto San Andreas เป็นเครื่องพิสูจน์ถึงสิ่งนั้น (แม้ว่า บริษัท นั้นอาจจะไม่พบผู้เล่นหลายคนยากเกินไป)

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

สิ่งที่เป็นคุณสมบัติพิเศษไม่ได้เป็นองค์ประกอบที่เป็นแก่นสารของเกม เนื้อเรื่องที่น่าตื่นเต้นผสมผสานกับเกมเพลย์ที่สนุกสนานคือ


3

ในขณะที่มีระดับความหลากหลายในฟีเจอร์ที่ยอดเยี่ยม (ความสามารถในการสุ่มเนื้อหาในเกม GTA-ish มีอาวุธและอุปกรณ์มากมายในเกม RPG หรือเกม Call of Duty-ish เป็นต้น) ฉันคิดว่าการเล่นเกมที่น้อยที่สุดมุ่งเน้นไปที่คุณสมบัติหลักสองสามอย่างที่มีประสิทธิภาพสูง

ดูที่ Portal ใช้กลไกหลักหนึ่งตัวและสร้างตัวต่อได้อย่างมีประสิทธิภาพโดยไม่ต้องใช้ความยุ่งเหยิงเพิ่มเติม

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

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


2

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

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

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

ตามแนวทางทั่วไปฉันพยายามปฏิบัติตามกฎเหล่านี้:

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

  • หากโครงการใกล้เข้ามาแล้วให้ลองสร้างรายการคุณลักษณะเพื่อเพิ่มไปยังเวอร์ชันใหม่

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

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


2

ทำรายการให้สั้นให้คล่องแคล่ว

อย่าสร้างรายการคุณลักษณะเลยหรือถ้าคุณทำให้สร้างรายการเหล่านั้นสั้นมาก ๆ เพียงไม่กี่สัปดาห์ของการพัฒนา

พัฒนาในรูปแบบที่คล่องตัว - เริ่มต้นด้วยคุณสมบัติที่สำคัญที่สุดไม่กี่แบบทดสอบตามสิ่งที่ใช้งานได้และอะไรที่ไม่ได้แล้วลองคิดดูว่ามันคุ้มค่าที่จะเพิ่มคุณสมบัติอื่น ๆ อีกไหม (คุณจะสามารถตัดสินได้ดีกว่าถ้า คุณมีประสบการณ์การเล่นเกมขั้นพื้นฐานแล้ว)

วิธีการตัดสินคุณสมบัติส่วนบุคคล

นอกเหนือจากนั้นฉันจะเห็นด้วยกับเงื่อนไขของ bennybdbc "เมื่อเวลาและความพยายามที่จำเป็นในการรวมพวกเขามีค่ามากกว่าค่าที่เพิ่มลงในเกม"

ที่กล่าวว่าคุณยังต้องพิจารณาโลก "ภายนอก":

  • คุณหมดเงินหรือหมดเวลาตามสัญญาหรือไม่
  • คุณหมดพื้นที่สื่อสิ่งพิมพ์ (เต็ม DVD)
  • คุณหมดพื้นที่ประสิทธิภาพ (ฟีเจอร์ใหม่จะทำให้เกมทำงานช้าเกินไป)?
  • เกมการแข่งขันที่กำลังจะเปิดตัวเร็ว ๆ นี้?

ปัญหาในชีวิตจริงง่ายๆเช่นนี้จำเป็นต้องพิจารณาเช่นกันเว้นแต่ว่าคุณกำลังพัฒนาเกมเพื่อความสนุกสนาน


0

เมื่อคุณกระดาษหมดให้เขียนลงไป

ขีด จำกัด ที่แน่นอนจะเป็นขนาดสื่อ ตัวอย่างเช่นคุณไม่สามารถใส่ฟีเจอร์ 10GB ในดีวีดี 4.7GB ได้

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.