คุณใช้ไดอะแกรมกับเกมจำลองหรือไม่? [ปิด]


17

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

* แน่นอนว่าต้องเลือกใช้เครื่องมือคอนกรีตหลายครั้งเพื่อแก้ไขปัญหาที่เป็นรูปธรรม แต่อาจมีรูปแบบบางอย่าง

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


5
นี่เป็นคำถามที่เกี่ยวข้องกับการเขียนโปรแกรมทั่วไปดังนั้นโปรดดูคำถามนี้: programmers.stackexchange.com/questions/152997/…
congusbongus

3
ขอบคุณสำหรับการเชื่อมโยง แต่ฉันจงใจวางคำถามนี้ที่นี่จริง ๆ - ฉันต้องการดูว่า gamedev คล้ายกันในด้านนี้กับสาขาไอทีอื่น ๆ หรือไม่
กรมอุทยานฯ

คำตอบ:


21

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

ดังนั้นไดอะแกรมของฉันจะใช้เวลาส่วนใหญ่อยู่ในระดับที่สูงมากและรู้สึกเหมือนแผนที่ความคิด

ในการโยนตัวอย่างบางส่วนนี่เป็นแผนที่การสืบทอดคลาส (อันที่ถูกตัด) ในเกมของฉันที่ Interactive Object เป็นประเภทพื้นฐาน

Interactive Object เป็นประเภทฐาน

นี่เป็นไดอะแกรมFSM (เครื่องไฟไนต์ - สเตท ) สำหรับกับดักแหลม (กับดักที่ยอดเยี่ยมที่คุณก้าวเข้ามาและหนามแหลมwooshปรากฏขึ้นจากพื้นดิน)

แผนภาพ FSM สำหรับกับดักสไปค์แบบง่าย ๆ

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

ภาพรวมของเกม

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

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

ตัวอย่างสำหรับกับดักขัดขวางที่ฉันวาดตอนนี้จะมีลักษณะเช่นนี้: รายละเอียดเพิ่มเติมผังกับดักขัดขวาง

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

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

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


4
บน sidenote คุณใช้ yEd กับไดอะแกรมหรือไม่? ฉันคิดว่ามันมีประโยชน์มาก
Kromster พูดว่าสนับสนุน Monica

4
แน่นอน! ดีใจที่เห็นผู้ใช้รายอื่น ฉันใช้มันมากในช่วงหลายปีที่ผ่านมามันเป็นสิ่งที่ฉันโปรดปรานในปัจจุบัน

2
+1 สำหรับปี ข้อเสียเพียงอย่างเดียวคือ UML ไม่ง่ายเลย แต่สำหรับแผนภาพอื่น ๆ มันยอดเยี่ยมสำหรับแอพฟรี
Sidar

2
ฉันใช้ yEd เพื่อออกแบบแผนผังพฤติกรรมของฉันสำหรับการแข่งขัน AI ของ AiGameDev
Nick Caplinger

15

แน่นอนฉันทำ - ทั้งโครงสร้างและพฤติกรรม - กฎง่ายๆคือฉันทำไดอะแกรมเมื่อต้นทุนในการทำไดอะแกรมน้อยกว่าการพยายามจดจำสิ่งที่นรกที่ฉันคิดในอีกหนึ่งเดือนต่อมา - หรือเมื่อฉันต้องอธิบายตัวเองให้ชัดเจน นักพัฒนาอื่น ๆ

คลาสไดอะแกรมเมื่อลำดับชั้นการสืบทอดมีความซับซ้อนเพียงพอ

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

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


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

6
อ่า - ขึ้นอยู่กับ - วิธีใดที่ใช้ได้ผลกับปัญหาที่เกิดขึ้น - บางครั้งมันง่ายกว่าที่จะทำโค้ดให้ยุ่งยาก one
Mark Mullin

@ Mark: บิตนั้นควรเป็นส่วนหนึ่งของคำตอบ;)
Kromster พูดว่าสนับสนุน Monica

8

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

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

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

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

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

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

สำหรับตัวฉันเองฉันใช้ไดอะแกรมตลอดเวลา - การวาดแผ่นจดบันทึกที่เรียบง่ายสำหรับโครงการส่วนบุคคลไดอะแกรม UML แบบง่าย ๆ ในที่ทำงาน แผนภาพ UML นี้เป็นสิ่งที่ฉันคิดว่าซับซ้อนเกินไปและสิ่งที่ฉันไม่เคยทำเพราะค่าใช้จ่ายในการผลิตและการบำรุงรักษานั้นเกินดุลประโยชน์ แต่แน่นอน YMMV


หนึ่งคำถามที่ยอดเยี่ยมสำหรับคุณ - IIUC คุณกำลังพยายามที่จะยึดติดกับไดอะแกรมอย่างง่าย (เสมอ) แต่โดยทั่วไปแล้วไดอะแกรมจำเป็นต้องมีเมื่อแอปพลิเคชันมีความซับซ้อน คุณจะทำให้ไดอะแกรมเล็กและเรียบง่ายได้อย่างไรเมื่อสร้างแบบจำลองระบบที่กว้างใหญ่และซับซ้อน?
NPS

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

8

ฉันจะบอกว่ามีไดอะแกรมสองประเภท ไดอะแกรมอย่างเป็นทางการและลายเส้น

เกี่ยวกับไดอะแกรมอย่างเป็นทางการฉันทำเมื่อฉันทำงานกับโปรแกรมเมอร์อื่น ๆ แต่ฉันไม่ค่อยทำเมื่อฉันเขียนโปรแกรมเพียงอย่างเดียว

อย่างไรก็ตามนั่นไม่ได้หมายความว่าฉันจะนั่งและใส่รหัสอะไรก็ตาม ในความคิดของสิ่งที่สำคัญที่สุดเมื่อการเขียนโปรแกรม (หรือจริงอะไรในชีวิต) คือการคิดว่าเป็นครั้งแรกและทำในภายหลัง

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

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

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

นี่คือบทความที่เกี่ยวข้องที่ฉันบังเอิญเห็นด้วย

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

มีประโยชน์หลักสามประการด้วยไดอะแกรมฟรีสไตล์ / ลายมือเขียนบนเครื่องมือที่ทำแพคเกจล่วงหน้า:

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

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

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


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

0

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

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

Joris Dormans และ Ernest Adams ได้พูดคุยเกี่ยวกับระบบการออกแบบเกม / การสร้างสมดุลของระบบMachinations (นี่คือวิดีโอ GDC Vault แบบ paywall จาก GDC EU 2012; ตัวอย่างจาก GDC 2013 บนวิกิของ Dormans) แทนที่จะพยายามถอดความนี่คือวิธีที่ wiki อธิบายระบบ:

Machinations เป็นเฟรมเวิร์กเชิงทฤษฎีและการแสดงภาพกราฟิกแบบอินเทอร์แอคทีฟแบบไดนามิกที่อธิบายเกมเป็นระบบแบบไดนามิกและมุ่งเน้นไปที่ลูปการตอบกลับแบบปิดภายใน ความตั้งใจคือการหาวิธีในการแสดงและตรวจสอบโครงสร้างของเกม (กำเริบ) ตามระเบียบวิธี Machinations เสนอเลนส์ใหม่ในการฝึกฝนการออกแบบเกมและการทรงตัวที่ใช้งานง่ายและละเอียดอ่อน

โนอาห์ฟอลสไตน์ได้พูดคุยเรื่อง "The Arcane Art of Puzzle Dependency Diagrams" ( วิดีโอ GDC Vault ที่จ่ายเงิน ) ฉันไม่พบลิงค์ที่ไม่ใช่ paywall ใด ๆ ที่นี่ แต่มีหลายคนพูดถึงหรือโพสต์บันทึกย่อของพวกเขาทางออนไลน์

ทั้งสองพูดคุยกันเมื่อพวกเขาสร้างและวิธีที่พวกเขารักษาไดอะแกรมเหล่านี้ในระดับหนึ่งหรืออีก


0

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

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

ฉันยังสามารถชี้ให้คุณเห็นงานของตัวเองในหัวข้อนั้นขึ้นอยู่กับเศรษฐศาสตร์ของวงการเล่นเกมโดยใช้ทรัพยากรที่เป็นนามธรรมเพื่อติดตามสิ่งต่าง ๆ เช่นโอกาสโชคหรือการเตรียมตัว:

http://www.stephanebura.com/diagrams/

หากคุณพบว่าวิธีการนี้มีประโยชน์คุณควรดูที่ Joris Dormans 'Machinations เครื่องมือสำหรับทำไดอะแกรมและการจำลองสถานการณ์:

http://www.jorisdormans.nl/machinations/

กระบวนการทั้งหมดของเขาถูกอธิบายในหนังสือของเขา:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/

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