จะจัดการเธรดเรื่องราวหลายเกมในเกม RPG ได้อย่างไร?

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

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

ฉันเห็นเกมมากมายที่มีเอ็นจิ้นการตัดสินใจที่ซับซ้อนและฉันสงสัยว่าพวกเขาทำอย่างไร มีการออกแบบพิเศษที่ทำให้สิ่งต่าง ๆ เป็นเรื่องง่ายหรือไม่? มีใครทำสิ่งที่คล้ายกันและสามารถให้คำแนะนำเกี่ยวกับวิธีการแก้ไขปัญหานี้ได้หรือไม่

อัปเดต 1:

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

นอกจากนี้ฉันสนใจในโซลูชันการออกแบบเป็นวิธีที่ดีที่จะทำวิธีที่คนอื่นทำหรือทำ

architecture rpg

— Valentin Radu
แหล่งที่มา

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

— Randolf Richardson

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

— Valentin Radu

ดังนั้นจะเจาะจงมากขึ้นฉันไม่สามารถตรวจสอบif (isTree)หรือรักษาisTreevar ส่วนกลางได้เนื่องจากเรื่องราวอาจมีหรือไม่มีตัวเลือกนั้น รู้ว่าฉันหมายความว่าอย่างไร? มันเป็นเหมือนเครื่องมือตัวเลือกที่ให้บริการเรื่องราวมากมาย

— Valentin Radu

นอกจากนี้ยังมีปัญหาอื่นสมมติว่าหากผู้ใช้ตัดสินใจที่จะปลูกต้นไม้ที่เราตั้งไว้isTree=trueอย่างไรก็ตามในภายหลังเขาทำอย่างอื่นเช่นต่อสู้กับเพื่อนร่วมโรงเรียนซึ่งเป็นการตอบแทนและสับต้นไม้ของเขาในขณะที่ต้นไม้ยังเด็ก เพราะเขาโดนเตะ ตอนนี้เรามี 2 ตัวแปรที่มีอิทธิพลต่อการดำรงอยู่ของต้นไม้isTree==true' and didFightBrat == false` รู้ว่าฉันหมายความว่าอย่างไร? และโซ่สามารถดำเนินต่อไปตลอดกาลการดำรงอยู่ของต้นไม้สามารถได้รับอิทธิพลจากปัจจัยที่ไม่ทราบจำนวน รู้ว่าฉันหมายความว่าอย่างไร?

— Valentin Radu

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

— Randolf Richardson

คำตอบ:

นอกจากนี้คุณยังสามารถสรุปคิวลงในกราฟ acyclic โดยตรง (DAG) คุณสามารถอ่านเกี่ยวกับสิ่งเหล่านี้ได้ใน Wikipedia โดยทั่วไปแต่ละโหนดสามารถมีโหนดพาเรนต์ตั้งแต่หนึ่งโหนดขึ้นไปที่ "ขึ้นอยู่กับ" ไม่อนุญาตให้ใช้รอบเช่นถ้า A ขึ้นอยู่กับ B, B ไม่สามารถพึ่งพา A (โดยตรงหรือผ่านทางสายโซ่ทางอ้อมของโหนดอื่น ๆ )

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

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

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

— นาธานรีด
แหล่งที่มา

คำตอบที่ดีมากขอบคุณ ที่จริงมันแก้ปัญหาอื่น ๆ ที่ฉันมีเช่นบันทึกความคืบหน้าของผู้ใช้ นี่คือสิ่งที่ฉันต้องการ

— Valentin Radu

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

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

— Nathan Reed

@NathanReed อ่าขอโทษฉันพลาดส่วนที่เรียกซ้ำ

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

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

บางเพิ่มเติมเกี่ยวกับวิกิพีเดีย

จากเมื่อถึงการใช้กฎของเครื่องมือหัวข้อย่อย (การเน้นคือของฉัน):

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

สิ่งหนึ่งที่ควรทราบก็คือในบางครั้งเครื่องมือสร้างกฎจะใช้งานได้ดีที่สุดโดยใช้ "ภาษา" เฉพาะโดเมนแบบง่ายหรืออย่าง YAML ฉันจะไม่แนะนำ XML

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

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

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

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

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

โครงสร้างพื้นฐานทั้งหมดนี้มีวัตถุประสงค์เพื่อเลียนแบบพฤติกรรมของอาจารย์คุกใต้ดินของมนุษย์: โดยทั่วไปเขาใช้บันทึกจิตของสถานการณ์ปัจจุบัน (HMS ["ภายนอก"]) เนื่องจากการตัดสินใจของผู้เล่นและสภาพแวดล้อม เมื่อมีบางสิ่งต่อท้ายมันสามารถทำการตัดสินใจโดยใช้บันทึกทางจิตใจและบันทึกสถานะกลยุทธ์ภายในบางอย่างด้วยเช่นกัน (HSM ["ภายใน"])) เพื่อหลีกเลี่ยงการตอบสนองในทำนองเดียวกัน

— FxIII
แหล่งที่มา