การวิเคราะห์ความต้องการมีประโยชน์ในการพัฒนาเกมหรือไม่?


9

ฉันเป็นนักศึกษาวิศวกรรมซอฟต์แวร์ที่มุ่งเน้นการพัฒนาเกม การวิเคราะห์ความต้องการมีส่วนใหญ่เพียงใดในการพัฒนาเกม

ฉันถามเพราะฉันกำลังพยายามตัดสินใจว่าจะทำการเรียนการวิเคราะห์ข้อกำหนดหรือไม่ นี่คือคำอธิบาย:

การศึกษาเชิงลึกของการวิจัยในปัจจุบันและการปฏิบัติในการดึงความต้องการข้อกำหนดการวิเคราะห์ข้อกำหนดข้อกำหนดการตรวจสอบความต้องการและการตรวจสอบและการจัดการความต้องการ

ความรู้ประเภทนี้จะมีประโยชน์สำหรับนักพัฒนาเกมอิสระหรือไม่? (ทางเลือกคือปัญญาประดิษฐ์หรือสถาปัตยกรรมซอฟต์แวร์)


เพื่ออธิบายสิ่งที่เป็นทางเลือกของคุณ?
ChrisE

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

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

เครื่องมือ / เทคนิคที่ใช้ใด ๆ ที่จะช่วยให้คุณหลีกเลี่ยงการวิเคราะห์อัมพาตจะเป็นประโยชน์
Patrick Hughes

คำตอบ:


7

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

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

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


+1 ทุกอย่างที่กล่าวไว้ที่นี่ถูกต้องเช่นเดียวกับการจัดการกับความคิดที่ว่าคุณอาจลงเอยด้วยการเขียนโปรแกรมขององค์กรจนกว่าคุณจะสร้างมันขึ้นมาในฉากอินดี้
ChrisE

มันจะไม่มีประโยชน์อย่างไร? คุณต้องวิเคราะห์ทุกสิ่งที่คุณทำในลักษณะที่มีโครงสร้าง เพียงเพราะบางคำศัพท์ไม่ได้หมายความว่าเป็นไปไม่ได้ที่จะหาจำนวน
johnny

2

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

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


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

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

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

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

อะไรคือวิธีอื่น ๆ ?
johnny

2

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

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


0

ข้ามมัน.

คุณสนใจด้านการพัฒนาเกมในด้านใด ฉันถือว่าโปรแกรมเมอร์ แต่ ...

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

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

ศิลปิน: ศิลปินนำอีกครั้งพร้อมกับโปรแกรมเมอร์นำที่มักจะกำหนดข้อกำหนดสำหรับสินทรัพย์ศิลปะ เรียนรู้เกี่ยวกับงาน

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

หากคุณวางแผนที่จะไปอินดีคุณต้องเรียนวิชาธุรกิจ / การบัญชี / การจัดการ คุณจะต้องเอาตัวรอดและไม่ได้เมา โชคดี.


ฉันจะถือว่าโปรแกรมเมอร์เนื่องจากเขาติดแท็กโปรแกรมเมอร์ไว้)
The Communist Duck

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

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

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

1
@PatrickB การวิเคราะห์ความต้องการจะไม่ส่งผลกระทบต่อวิธีการออกแบบซอฟต์แวร์ การวิเคราะห์ความต้องการนั้นเต็มไปด้วยข้อมูลที่ไร้ประโยชน์ซึ่งผู้พัฒนาเกมแทบจะไม่เคยใช้เลย (ใช้ไดอะแกรมกรณีและปัญหาโดยเฉพาะอย่างยิ่งในใจ) มันเป็นหัวข้อที่มุ่งเน้นไปที่ผู้มีส่วนได้เสียและสภาพแวดล้อมขององค์กร ฉันยอมรับว่าผู้พัฒนาควรแสดงข้อกำหนด (ฟีเจอร์) แต่ควรเป็นเรื่องธรรมดา การออกแบบชิ้นส่วนของซอฟต์แวร์เป็นหัวข้อที่แยกจากกันอย่างสมบูรณ์ซึ่งการวิเคราะห์ความต้องการแทบไม่ได้สัมผัสเลย (ที่มหาวิทยาลัย)
Ray Dey
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.