GUI - yae หรือเปล่า [ปิด]

ฉันทำงานเกี่ยวกับการพัฒนาแอพพลิเคชั่นที่มีระบบ GUI "คงไว้" มากมาย (ด้านล่างเพิ่มเติมเกี่ยวกับสิ่งที่ฉันหมายถึง) เช่น MFC, QT, Forms, SWING และเฟรมเวิร์ก GUI บนเว็บหลายปีที่ผ่านมา ฉันมักจะพบแนวคิดของระบบ GUI ที่ซับซ้อนและเงอะงะมากเกินไป จำนวนกิจกรรมการติดต่อกลับผู้ฟังสำเนาข้อมูลบางสิ่งบางอย่างที่ทำให้เป็นสตริง - การแปลง (และอื่น ๆ ) เป็นแหล่งที่มาของข้อผิดพลาดและปวดหัวเสมอเมื่อเทียบกับส่วนอื่น ๆ ในแอปพลิเคชัน (แม้จะใช้การเชื่อมโยงข้อมูล / รุ่น "ถูกต้อง")

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

มันช่างน่ากลัว

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

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

ให้ฉันสรุปสิ่งที่ฉันหมายถึงโดย "คงไว้" และ "ทันที":

Retained GUI: ในขั้นตอนการกำหนดค่าเริ่มต้นแยกต่างหากคุณสร้าง "ตัวควบคุม GUI" เช่นป้ายกำกับ, ปุ่ม, กล่องข้อความ ฯลฯ และใช้วิธีการอธิบาย (หรือโปรแกรมทางด้านเทคนิค) บางอย่างในการวางไว้บนหน้าจอ ส่วนควบคุมถือสถานะส่วนใหญ่ของตนเองในหน่วยความจำเช่น X, Y ตำแหน่ง, ขนาด, เส้นขอบ, การควบคุมเด็ก, ข้อความป้ายกำกับ, รูปภาพและอื่น ๆ คุณสามารถเพิ่มการโทรกลับและผู้ฟังเพื่อรับข้อมูลเหตุการณ์และอัปเดตข้อมูลในการควบคุม GUI

GUI ทันที: ไลบรารี GUI ประกอบด้วยฟังก์ชัน "RenderButton", "RenderLabel", "RenderTextBox" หนึ่งครั้ง (... : แก้ไขอย่าสับสนโดยRenderอุปสรรค ฟังก์ชั่นเหล่านี้ยังใช้ตรรกะที่อยู่เบื้องหลังตัวควบคุมเช่นการป้อนข้อมูลผู้ใช้การสำรวจตัวอักษรการจัดการตัวละครซ้ำความเร็วเมื่อผู้ใช้กดปุ่มค้างไว้และอื่น ๆ ... ) ที่คุณสามารถเรียกใช้ "ทันที" เพื่อทำการควบคุม ไม่จำเป็นต้องเขียนลง GPU ทันทีโดยปกติจะจำได้สำหรับเฟรมปัจจุบันและจัดเรียงเป็นชุดที่เหมาะสมในภายหลัง) ห้องสมุดไม่มี "สถานะ" ใด ๆ สำหรับสิ่งเหล่านี้ หากคุณต้องการซ่อนปุ่ม ... อย่าเรียกใช้ฟังก์ชัน RenderButton ฟังก์ชั่น RenderXXX ทั้งหมดที่มีการโต้ตอบกับผู้ใช้เช่นปุ่มหรือช่องทำเครื่องหมายมีค่าส่งคืนที่ระบุว่าผู้ใช้คลิกปุ่มดังกล่าวหรือไม่ ดังนั้น "RenderGUI" ของคุณ ฟังก์ชั่นดูเหมือนว่าจะเป็นฟังก์ชั่น if / else ที่คุณโทรหาหรือไม่เรียกใช้ฟังก์ชั่น RenderXXX ของคุณขึ้นอยู่กับสถานะเกมของคุณและตรรกะการอัพเดทข้อมูลทั้งหมด การจัดเก็บข้อมูลทั้งหมดคือ "นอก" gui และส่งผ่านไปยังฟังก์ชั่น Render ตามความต้องการ (แน่นอนว่าคุณจะแบ่งฟังก์ชั่นใหญ่ออกเป็นหลาย ๆ ส่วนหรือใช้ abstractions บางคลาสเพื่อจัดกลุ่มส่วนของ gui เราไม่ได้เขียนโค้ดเหมือนในปี 1980 อีกต่อไปใช่ไหม?))

ตอนนี้ฉันพบว่า Unity3D ใช้วิธีพื้นฐานแบบเดียวกันกับระบบ GUI ในตัว อาจมี GUI สองสามตัวที่ใช้วิธีนี้เช่นกัน?

ยัง .. เมื่อมองไปรอบ ๆ ดูเหมือนว่าจะมีอคติที่แข็งแกร่งต่อระบบ GUI ที่คงอยู่หรือไม่? อย่างน้อยฉันก็ไม่พบวิธีการนี้ยกเว้นใน Unity3D และชุมชน IMGUI ดั้งเดิมดูเหมือนว่าจะค่อนข้างเงียบ ..

ดังนั้นทุกคนทำงานร่วมกับทั้งความคิดและมีความเห็นที่แข็งแกร่ง?

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

เปล่า ฉันทำ gamedev ที่ได้รับค่าจ้างทำงานบน GUI 'โหมดคงไว้' อันยิ่งใหญ่และบน GUI 'โหมดเร่งด่วน' อันยิ่งใหญ่และแม้ว่าทั้งคู่ทำให้ฉันต้องการที่จะทำให้ตาของฉันหายไป

ข้อเสียของโหมดทันทีมีมากมาย:

• พวกเขาไม่ได้ทำให้มันง่ายสำหรับศิลปินและนักออกแบบในการกำหนดโครงร่าง;
• มันทำให้คุณผสมผสานตรรกะกับการนำเสนอ
• พวกเขาทำให้มันยากขึ้นที่จะมีรูปแบบการป้อนข้อมูลที่สอดคล้องกันเพียงครั้งเดียว
• พวกเขาไม่สนับสนุนการควบคุมที่ซับซ้อนของข้อมูลแบบไดนามิก (เช่นมุมมองรายการ)
• การฝังตัวกลายเป็นเรื่องที่น่าอึดอัดใจมาก (เช่นถ้าฉันเรียก RenderComboBox กล่องแบบเลื่อนลงอาจยังไม่สามารถแสดงผลได้เนื่องจากมันต้องอยู่เหนือส่วนที่เหลือของหน้าต่าง - เช่นเดียวกับคำแนะนำเครื่องมือ)
• การกำหนดค่ารูปแบบการเรนเดอร์ถูกกระทำด้วย globals (ick) หรืออาร์กิวเมนต์ของฟังก์ชันพิเศษ (ick);
• ประสิทธิภาพอาจไม่ดีนักเนื่องจากการเรียกใช้ฟังก์ชันเหล่านี้ทั้งหมดเพื่อค้นหาค่าที่อาจหรือไม่อาจเปลี่ยนไปมีแนวโน้มที่จะสร้างวัตถุขนาดเล็กจำนวนมากโดยเน้นที่ตัวจัดการหน่วยความจำ
• ... และฉันไม่สามารถจินตนาการได้เลยว่ามันจะเจ็บปวดแค่ไหนที่จะอนุญาตให้บางคนลาก GUI บิตไปรอบ ๆ และสั่งซื้อใหม่อีกครั้ง คุณต้องบำรุงรักษาโครงสร้างข้อมูลที่บอกให้คุณทำทุกอย่าง - ซึ่งก็เหมือนกับการเขียนระบบโหมดคงไว้ด้วยตัวคุณเอง

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

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

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

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

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

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

ไม่ว่าในกรณีใดขอให้โชคดี!

ไลบรารี GUI ประกอบด้วยฟังก์ชั่นหนึ่งเดียว "RenderButton", "RenderLabel", "RenderTextBox" ... ฟังก์ชั่นที่คุณสามารถเรียกไปที่ "ทันที" ทำให้การควบคุม (ไม่ต้องเขียนลง GPU ทันทีโดยปกติจะจำได้ สำหรับเฟรมปัจจุบันและเรียงลำดับเป็นแบทช์ที่เหมาะสมในภายหลัง)

ฉันจะบอกว่านี่ไม่ใช่ห้องสมุด GUI มันเป็นเพียงฟังก์ชั่นการแสดงผลมากมาย

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

RenderTextBoxเพิ่งจะวาดกล่องข้อความ มันจะทำการวัดข้อความง่ายๆและวาดร่ายมนตร์บนหน้าจอ มันจะไม่

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

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

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

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

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

โดยทั่วไปคุณจะต้องTextBoxWindowเรียน

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

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

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

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

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

อินเทอร์เฟซผู้ใช้โดยทั่วไปไม่จำเป็นต้องมีการจัดวางอัตโนมัติหรือมีหน้าต่างที่ปรับขนาดได้แบบทันที

นั่นเป็นความคิดที่ จำกัด และ จำกัด

ฉันจะให้เกมเกี่ยวกับเกมที่แตกต่างกันมีความต้องการที่แตกต่างกัน UI ที่บางเกมทำจำเป็นหน้าต่าง resizeable และอื่น ๆ แต่มีปัญหาที่ใหญ่กว่ามาก

ความคิดของคุณนำไปสู่ปัญหาการต่อสู้ในอวกาศ Gratuitous

หากคุณไม่เคยเล่นเกมนั้นมันเป็นเกมราคาถูกอินดี้และ GUI ที่หนักหน่วง การเล่นเกมที่เกิดขึ้นจริงนั้นทำใน GUI (เป็น "การติดตั้งหน่วยและดูการต่อสู้" ของเกม) ปัญหา?

GUI ไม่สามารถแก้ไขได้!

โอ้นี่เป็นเรื่องปกติถ้าคุณใช้จอภาพปกติหรือมีสายตาปกติ ตัวอย่างเช่นถ้าคุณเป็นคนที่ใช้จอภาพขนาดใหญ่ที่น่าขัน (ขนาดใหญ่มากจนคุณมี Windows ที่ขยายขนาดของข้อความทั้งหมดเพื่อให้คุณสามารถอ่านได้จริง) นี่มันแย่มาก ข้อความเป็นกล้องจุลทรรศน์ ไม่มีวิธีการเปลี่ยนขนาดตัวอักษร

ได้รับ GSB เป็นเกมที่ใช้ GUI ดังนั้นจึงไม่สามารถใช้กับพวกเขาได้อย่างแน่นอน เกม GUI-lite น่าจะหนีไปได้

อย่าคิดเลยว่าผู้ใช้ของคุณกำลังดูเกมของพวกเขาอย่างที่คุณเป็น การทำเช่นนั้นเป็นความเขลา

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

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

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

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

ขณะที่ผ่านมา IMGUIs ยังจับความสนใจของฉันเป็นแบบทดสอบที่ผมเขียนคู่ของบทเรียนที่จะทำความรู้จักตัวเองด้วยเทคนิค (เริ่มต้นที่นี่หากคุณสนใจ แต่ก็ไม่มากไปกว่า C # / XNA + เดิม 'กวดวิชา' ที่นี่ ) .

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

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

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

ฉันทำงานมากด้วย Unity3D GUI ซึ่งทำงานได้ตามที่คุณอธิบาย และฉันต้องบอกว่าฉันเกลียดมันด้วยความหลงใหล

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

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

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

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

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

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

• กำลังโหลด GUI จากสคีมา

บางทีในตอนแรกดูเหมือนว่าศิลปินจะไม่มีความยืดหยุ่นกับ IMGUI จำนวนมากนี่คือการแก้ไขหรือปรับปรุงด้วยการโหลดเค้าโครง GUI จาก xml หรือ JSON schema

• การเรียกเลเยอร์เมนู

ปัญหานี้แก้ไขได้ด้วยการเรียงลำดับคุณควรสร้างคลาส UI Manager ที่เรียงลำดับของการวาดฉันแก้ไขปัญหานี้ใน C # XNA ด้วยแผงควบคุมแบบเคลื่อนย้ายได้และคลิกได้ซึ่งวาดอยู่ด้านบนของกันและกัน ฉันสามารถโพสต์รหัสหลอกหากถูกถาม

• กล่องรายการ

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

• แยกข้อมูลจาก GUI

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

• GUI จาก SDK

นี่คือขีด จำกัด และการทำงานของรหัสของ SDK ไม่ใช่ของคุณ ฉันพบว่า SDK UI (Hammer, Unity, UDK) เกือบจะเป็นภาษาใหม่ที่จะเรียนรู้อยู่แล้ว ในความเป็นจริงพวกเขาคล้ายกับฉันเป็น Windows รูปแบบทั้งสองมีการตั้งค่าสำหรับความเป็นไปได้ที่กว้างที่สุดและมีความซับซ้อนมากขึ้น

และดูล่าสุด> http://mollyrocket.com/861

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

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

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

แต่จากมุมมองของการออกแบบฉันมีปัญหาในการจินตนาการโลกโดยปราศจากเหตุการณ์ GUI ของฉัน GUI แบบทันทีไม่สามารถทำงานร่วมกับ OOP บังคับให้คุณหันไปใช้การเขียนโปรแกรมแบบโพรซีเดอร์

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